-
Notifications
You must be signed in to change notification settings - Fork 30
feat: add centralized trust bundle cert management #2167
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
| // Validate each certificate in the bundle | ||
| certBlocks.forEach((certPem, index) => { | ||
| try { | ||
| new X509Certificate(certPem); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
note: add in a validation with the crypto library to ensure that provided values for CA_BUNDLE_CERTS are proper certs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
note to self: add a uds docs redirect link for this
| uds zarf tools kubectl label namespace authservice-ambient-test-app zarf.dev/agent=ignore | ||
| uds zarf tools kubectl apply -f src/test/app-ambient-authservice-tenant.yaml | ||
| - task: private-pki:private-pki-tests | ||
| - task: trust-bundle:trust-bundle-tests |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
note: I decided to keep these trust bundle e2e tests in the private-pki nightly workflow. if we feel that we want to run them as standard e2e tests that is fine too, just lmk. We will just have to update our k3d-standard bundle deploy to enable public CA certs so we can test this.
| } | ||
|
|
||
| // Execute commands inside a pod | ||
| async function execInPod( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
note: moved this into a helper function folder so it can be reused
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| environment: 'node', | ||
| globalSetup: ['./vitest.setup.js'], | ||
| include: ['**/*.spec.ts'], | ||
| exclude: ['trust-bundle/**'], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
note: e2e vitest flow was running the trust-bundle ones as well, so had to explicitly exclude this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
This PR implements centralized trust bundle management for UDS Core, enabling automatic distribution of CA certificates (custom, DoD, and public) across the cluster through ConfigMaps. The feature introduces new CRD fields, a dedicated CA bundle controller, and comprehensive test coverage.
Key Changes
- Added
caBundleconfiguration to ClusterConfig and Package CRDs with support for custom, DoD, and public CA certificates - Implemented automatic CA bundle ConfigMap generation and distribution in namespaces with UDS Packages
- Enhanced ClusterConfig with status subresource tracking (Pending/Ready/Failed phases)
- Deprecated
CA_CERTvariable in favor ofCA_BUNDLE_CERTSfor improved clarity
Reviewed changes
Copilot reviewed 42 out of 44 changed files in this pull request and generated 10 comments.
Show a summary per file
| File | Description |
|---|---|
| src/pepr/operator/controllers/ca-bundles/ca-bundle.ts | New controller for creating and updating CA bundle ConfigMaps across the cluster |
| src/pepr/operator/controllers/ca-bundles/ca-bundle.spec.ts | Comprehensive unit tests for CA bundle controller functionality |
| src/pepr/operator/controllers/config/config.ts | Enhanced config reconciliation with CA bundle support, status management, and update logic |
| src/pepr/operator/controllers/config/config.spec.ts | Expanded test coverage for config handling including CA bundle scenarios |
| src/pepr/operator/crd/sources/package/v1alpha1.ts | Added caBundle field to Package CRD schema |
| src/pepr/operator/crd/sources/cluster-config/v1alpha1.ts | Added caBundle field and status subresource to ClusterConfig CRD |
| src/pepr/operator/crd/validators/clusterconfig-validator.ts | Added validation for CA bundle certificates with X.509 verification |
| src/pepr/operator/crd/validators/clusterconfig-validator.spec.ts | Test coverage for CA bundle certificate validation |
| src/pepr/operator/reconcilers/package-reconciler.ts | Integrated CA bundle ConfigMap creation into package reconciliation |
| test/vitest/trust-bundle/ | New E2E test suite validating trust bundle functionality with live containers |
| test/vitest/helpers/k8s.ts | Refactored execInPod helper for reuse across test suites |
| docs/reference/configuration/trust-management/central-trust-bundle-management.md | Comprehensive documentation for the centralized trust bundle feature |
| schemas/package-v1alpha1.schema.json | JSON schema for Package CRD with caBundle field |
| schemas/clusterconfig-v1alpha1.schema.json | JSON schema for ClusterConfig CRD with caBundle and status fields |
| src/pepr/zarf.yaml | Added new Zarf variables and ClusterConfig status validation wait action |
| src/pepr/uds-operator-config/values.yaml | Updated Helm values with CA bundle configuration |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
mjnagel
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Initial review - need to deploy locally and validate the deprecated value at least but this looks pretty great overall.
chance-coleman
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is looking good to me, only really one place that tripped me up a bit.
| variables: | ||
| core: | ||
| # CA certificate for Authservice | ||
| CA_CERT: "PLACEHOLDER_CA_CERT" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shall we call this out as a breaking change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're leaving CA_CERT around, just deprecated so I don't think we need to. This removal is just in a CI only config file so not a downstream breaking change here.
| name: uds-ca-certs | ||
| namespace: pepr-system | ||
| data: | ||
| dodCACerts: "" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ConfigMap has a limitation to 1 MB. I did some quick math and for a Base64 encoded certs that are quite large (2 KB, 2.72 KB after encoding), we can store around 370 of these.
Even though it appears quite large, shall we mention somewhere in the docs that there is certain ceiling there and administrators should be aware of it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea, we did some math in the design doc around this. Realistically, we don't imagine users hitting the upper limit on the configmap. We could put a callout in the docs about the upper limit, but I feel it is adding a caution to something that most likely won't happen? I lean towards leaving it out but could be convinced to put it in
| - name: module | ||
| valuesFiles: | ||
| - values.yaml | ||
| actions: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this necessary? I though Zarf automatically checks the Ready field.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Zarf will check for the Ready condition, but not the phase field by default. Think in the design doc the status stuff popped up towards the end of review/approval but we were leaning towards keeping status simple and not using conditions here. That would be a way to get rid of this action though if we wanted to.
Description
Implements the Centralized Trust Bundle management feature according to design doc.
Related Issue
Fixes #2126
Type of change
Steps to Validate
uds run -f tasks/test.yaml uds-core-private-pkiChecklist before merging