Skip to content

Conversation

@joelmccoy
Copy link
Contributor

@joelmccoy joelmccoy commented Nov 21, 2025

Description

Implements the Centralized Trust Bundle management feature according to design doc.

Related Issue

Fixes #2126

Type of change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Other (security config, docs update, etc)

Steps to Validate

  • uds run -f tasks/test.yaml uds-core-private-pki
    • can toggle/swap out values in the ClusterConfig manually to ensure expected reconciliation for configmaps in cluster

Checklist before merging

// Validate each certificate in the bundle
certBlocks.forEach((certPem, index) => {
try {
new X509Certificate(certPem);
Copy link
Contributor Author

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

Copy link
Contributor Author

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
Copy link
Contributor Author

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(
Copy link
Contributor Author

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

Copy link
Contributor Author

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/**'],
Copy link
Contributor Author

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

@joelmccoy joelmccoy changed the title feat: add ca trust bundle management feat: add centralized trust bundle cert management Dec 3, 2025
@joelmccoy joelmccoy marked this pull request as ready for review December 3, 2025 21:22
@joelmccoy joelmccoy requested a review from a team as a code owner December 3, 2025 21:22
Copilot AI review requested due to automatic review settings December 3, 2025 21:22
Copy link
Contributor

Copilot AI left a 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 caBundle configuration 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_CERT variable in favor of CA_BUNDLE_CERTS for 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.

Copy link
Contributor

@mjnagel mjnagel left a 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.

Copy link
Contributor

@chance-coleman chance-coleman left a 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"
Copy link
Contributor

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?

Copy link
Contributor

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: ""
Copy link
Contributor

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?

Copy link
Contributor Author

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:
Copy link
Contributor

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.

Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Implement Centralized Trust Bundle Management in UDS Core Operator

5 participants