defenseunicorns / uds-core

A secure runtime platform for mission-critical capabilities
https://uds.defenseunicorns.com
Apache License 2.0
41 stars 18 forks source link

feat: implement a centralized way to manage CA trust bundles #464

Open Racer159 opened 2 months ago

Racer159 commented 2 months ago

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

Describe alternatives you've considered

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

mjnagel commented 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.

mjnagel commented 1 month ago

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 commented 1 month ago

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

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 commented 1 month ago

(seems related lol)