Open Racer159 opened 2 months ago
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.
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).
Given a set of root certs that we want to add to our trust chain, we need the following:
.jks
for our java based packages)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.
(seems related lol)
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
uds-core
and my appuds-core
and my application packageDescribe 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: https://github.com/defenseunicorns/uds-bundle-software-factory-nutanix/pull/122