Open docandrew opened 1 month ago
One path here to consider - I think we could move the uds.dev to become a bundle default for the dev/demo bundles. This should generally ensure we keep a similar UX for dev/demo, but also makes sure that core's values don't default to this cert. While this doesn't change the aspect of compromising the certs, it does tie them more directly into the dev/demo workflows and ensure they would have to be explicitly specified if needed outside of those bundles. There would potentially be slight added friction for us to figure out in CI since we do tests against the layer packages and don't exclusively use the dev/demo bundles.
Curious on your thoughts on this approach @docandrew - I think this would meet most of the asks since core as a package would not have the cert anymore?
I think that makes sense - I'm fine including it in the dev bundle as long as it stays out of the core package.
Describe what should be investigated or refactored
A deployment of UDS Core will use default TLS certificates as they are baked into the Core Zarf package. These are publicly available in GitHub and should be considered compromised. This is done for convenience of development and test but leads to bad habits and can end up in production use.
I want to be confident that a production build never uses an insecure (leaked) uds.dev cert.
I would prefer to have to opt-in to a specific domain and keypair and set these values at deploy-time, since this will most closely mimic production use for delivery engineers. Explicit opt-in to a development keypair/domain is OK for local testing.
The "Getting Started" page and any guidance for Delivery engineers should consider emphasis on using a custom domain and keypair rather than the default development guidance.
Consider publishing the UDS Core "slim dev" package completely separate, so that no default certificates are in the
Core
Zarf package at all, but developers can continue to opt in to the current behavior for convenience.This can cause issues with tools like TruffleHog, etc. where these private keys are exposed as well, this can lead to alarm fatigue and encourages bad habits for ignoring certain secrets in Git because "this one's OK". The presence of this key could lead to certificate revocation from the CA as well if they are aware of the key on GitHub.
Links to any relevant code
Our uds.dev key is exposed here:
https://github.com/defenseunicorns/uds-core/blob/main/src/istio/values/config-tenant.yaml https://github.com/defenseunicorns/uds-core/blob/main/src/istio/values/config-admin.yaml