feat: implement a centralized way to manage CA trust bundles

[Racer159]

Is your feature request related to a problem? Please describe.

As Ezra I want a way to specify a CA root of trust that can be pulled into UDS packages so that I do not need to manually provide bundle overrides for each individual package manually.

Describe the solution you'd like

• Given I have a trust bundle, and a cluster prepared for uds-core and my app
• And my app package is configured to pull the CA from a config map / secret in its namespace
• When I deploy uds-core and my application package
• Then the custom CA I provided during UDS Core install is available in my app.

Describe alternatives you've considered

• Delivery folks could add their own package that contains the CA bundle and packages could detect the presence of a secret in their namespace but this would make this an optional feature which would reduce the security benefits and make each package a bit more complex.

• We could handle this similar to the ###ZARF_VAR_DOMAIN### variable and pass a ###ZARF_VAR_TRUST_BUNDLE### that each package pulls in and wires up to a configmap or secret of it's choosing. This would make providing a CA required but relies on (janky) Zarf templating and doesn't handle cert rotations well (since that would hit UDS Core and packages may not be updated with it.

Additional context

This could be implemented with trustmanager or Pepr things. There is an experimental implementation of this w/trustmanager here: defenseunicorns/uds-bundle-software-factory-nutanix#122

[mjnagel]

I think this makes sense to generate a standardized "root CA"/"CA bundle" secret in each namespace that has a Package CR. As mentioned this will likely need to be a new input since current requirements for Istio certs would only need the intermediates (and technically someone could get by with just the leaf cert if the end user trusted the intermediates). We would want to trust the root ideally, so forcing that as an input/allowing it as an input is probably best the path - then using that with pepr to generate a secret.

[mjnagel]

We're going to need a way to get the CA into our authservice setup so this might be partially-implemented there (at least the aspect of pepr having the CA).

From there we would just need to generate a secret, either always or by opt-in on the package CR. The final aspect would be ensuring we implement rotations effectively - at which point it may be good to evaluate if trust-manager solves some of my problems in a more simple way (with less for us to maintain).

[blancharda]

Given a set of root certs that we want to add to our trust chain, we need the following:

• The ability to automatically create a trust bundle (ideally, this would also include common public or .mil certs)
• The ability to convert the bundle into other formats (particularly .jks for our java based packages)
• Those bundles to be accessible in package namespaces as a secret or configmap
• The ability to easily update the bundles/secrets/configmaps when the certificates are rolled
• The ability to add volumemounts to the app appropriate directory within each container

In the example linked above in the issue, we are using trust-manager for the first 4 items, and then manually adding volume mounts via package overrides. Some charts are easier to customize in this way than others.

It would be very nice if the package CR had an optional field for custom CA mount points, which pepr could use to automatically inject the volumemount to all (or selector matched) containers in a pacakge so that package maintainers could ensure custom CAs were properly added without the need for init containers and running update-ca-trust.

Maybe something like this (half baked warning):

apiVersion: uds.dev/v1alpha1
kind: Package
spec:
  caTrust:
   - source: <config-map-name>
     sourceKey: <config-map-key>
     podSelector:
       some/label: isSet
     mountPoint: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

In this way a package maintainer could specify which pods should mount which trust bundles and where to place them.

[blancharda]

(seems related lol)