## Summary Add opt-in default trust bundles to the cert-manager trust-manager (CMTM) package so Big Bang users can distribute approved DoD PKI roots or public-Web-PKI roots to selected namespaces without having to define the complete `trust-manager` `Bundle` resources themselves. The feature must remain disabled by default. Users should be able to select a DoD PKI bundle, a public PKI bundle, or both, configure where the resulting trust material is distributed, and optionally provide their own CA source through a simple custom-bundle path. ## Problem Many workloads need a common CA trust store for one of two common cases: - connections to services using certificates issued by an approved DoD PKI; or - connections to services using certificates issued by the public Web PKI. CMTM can distribute trust bundles, but each Big Bang deployment currently has to provide the source material and `Bundle` configuration independently. This creates duplicated configuration and increases the risk of inconsistent namespace targeting, stale CA data, or accidentally distributing the wrong trust roots. ## Proposed behavior Add a Big Bang-owned configuration block for an optional aggregate default bundle. The exact value names should follow the package's existing passthrough and schema conventions. Conceptually: ```yaml bundle: enabled: false sources: dod: false public: false custom: {} target: {} ``` The selected sources should be composed into one generated bundle and target by default. The implementation may use a different shape if it better matches the upstream chart, provided the behavior and schema guarantees below are preserved. ### Bundle sources The aggregate bundle should support these independently selectable sources: - approved DoD PKI trust roots; - supported public-Web-PKI trust roots; and - a user-provided custom source. When selected, the sources are combined into one generated trust-manager `Bundle` and target object. This keeps the common configuration and workload mount path simple: users choose the trust sources once, and workloads consume one documented target. Provide a simple opt-in path for users to supply their own trust source. The package must reference user-managed public CA material or a user-managed ConfigMap/Secret; it must not package private keys or silently assume ownership of private PKI. The custom path should support the common case without requiring users to write a complete upstream `Bundle` resource, while retaining an escape hatch for advanced trust-manager configuration. ### Advanced multiple-bundle use cases Separate bundles may be appropriate when trust domains require different namespace selectors, target names, mount formats, or independent update/lifecycle controls. These are legitimate advanced cases, but should not multiply the default configuration surface or test matrix. Users who need them should be able to define additional native trust-manager `Bundle` resources without the package-managed aggregate bundle silently replacing them. ### Selection and distribution A trust-manager `Bundle` creates or updates target ConfigMaps and/or Secrets; it does not make workloads consume those objects automatically. Workloads must explicitly mount or reference the generated object in their own pod/deployment configuration. Users should be able to: - enable or disable each aggregate-bundle source independently; - select or override the generated target ConfigMap type, name, and key within the initial ConfigMap-only scope; - configure the namespace selector or distribution scope for those generated objects; and - preserve existing user-defined trust-manager `Bundle` resources without name collisions or silent replacement. The feature should document stable default target names and keys so workload authors can mount the bundles consistently. Workload-level mounting or reference configuration is outside CMTM unless a separate Big Bang integration is explicitly added. ## Requirements and acceptance criteria - [x] The aggregate default bundle is disabled unless explicitly enabled. - [x] DoD PKI and public PKI sources can be enabled independently. - [x] The custom source can be selected independently of the predefined sources. - [x] Enabling one source does not implicitly enable another. - [x] All selected sources are composed into one package-managed aggregate bundle by default. - [x] Additional user-defined trust-manager `Bundle` resources remain supported for advanced separate-bundle use cases. - [x] The package does not contain private keys or other private PKI material. - [x] Trust data has a documented source, ownership model, update process, and provenance. - [x] The selected CA set is versioned or otherwise change-detectable so updates can be reviewed and propagated safely. - [x] The default resources use stable, documented names and do not collide with user-defined bundles. - [x] Namespace distribution is explicit and does not unintentionally copy trust material into every namespace. - [x] Existing custom `Bundle` configuration remains supported. - [x] The values schema rejects invalid bundle configuration and documents the opt-in behavior. - [x] Helm unit tests cover source selection for the aggregate bundle: all disabled, DoD only, public only, DoD plus public, custom only, custom plus DoD, custom plus public, and all three enabled. - [x] Tests verify that each enabled source contributes to the single aggregate target and that disabled sources do not. - [x] Tests also cover custom source configuration, target name/key/type overrides, namespace selection, collision/override behavior, and invalid combinations. - [x] Package tests verify that the generated aggregate target ConfigMap contains the expected trust-bundle key and that updates reconcile correctly. Secret targets are deferred follow-up scope. - [x] Documentation explains when to use each source combination, the security implications, supported targets, update cadence, and how to supply a custom bundle. - [x] Normal and ambient test configurations continue to pass. - [x] Changelog and generated package documentation are updated with the feature. ## Design questions 1. Should the package ship the CA data directly, retrieve it from a maintained in-repository source, or reference an externally managed ConfigMap/Secret? 2. Which DoD PKI roots and which public PKI roots are in scope for the initial release? 3. The initial implementation should provide one aggregate bundle; separate package-managed bundles are deferred unless a concrete trust-domain or lifecycle requirement justifies them. 4. Should the default target be a ConfigMap, Secret, or a configurable choice? 5. What is the minimum configuration for the custom bundle path: an existing source reference, inline public certificate data, or both? 6. Should users opt in by bundle type only, or also select a predefined distribution profile such as system-wide, selected namespaces, or package-local? 7. How will CA rotations and removals be reviewed, tested, announced, and propagated to deployed bundles? 8. What behavior is required when a user already defines a resource with the proposed default name? ## Supported source permutations The initial implementation and tests should cover these source combinations, all producing one aggregate target: | DoD source | Public source | Custom source | Expected result | |---|---|---|---| | Off | Off | Off | No package-managed default bundle resources | | On | Off | Off | Aggregate target contains DoD roots | | Off | On | Off | Aggregate target contains public PKI roots | | On | On | Off | Aggregate target contains DoD and public PKI roots | | Off | Off | On | Aggregate target contains the user-provided source | | On | Off | On | Aggregate target contains DoD and custom roots | | Off | On | On | Aggregate target contains public and custom roots | | On | On | On | Aggregate target contains all selected sources | Each enabled combination should also be tested with its default target and with target/scope overrides. Separate-bundle behavior is an advanced escape hatch, not an additional default permutation. ## Out of scope - Creating or managing private keys. - Replacing user-defined trust-manager `Bundle` resources without an explicit migration path. - Providing multiple package-managed default bundles in the initial implementation. - Enabling any trust bundle by default for existing installations. - Adding unrelated certificate issuance or approver-policy behavior. ## Scope disposition The initial implementation scope is ConfigMap targets. Secret targets and workload mount/reference configuration are intentionally deferred to a follow-up enhancement. Scheduled Cyber Exchange archive refresh and automated updater-MR creation are separate pipeline-templates work and are not blockers for this package implementation. ## Related package - `cert-manager-trust-manager` (CMTM)