Applications using private certificates need to know which certificate authorities they should trust, and that list changes when roots are introduced or retired. trust-manager distributes those trust bundles across Kubernetes workloads. It complements certificate issuance by managing the trust material applications use when checking a connection. Applications must still load and reload the resulting bundles. Plan overlapping old and new roots during rotation so updating the distributed files does not unexpectedly break communication between services.
Chart ownership
The cert-manager project documents the trust-manager chart at oci://quay.io/jetstack/charts/trust-manager. Its production guidance recommends cert-manager for the controller's certificate needs, while a Helm-generated certificate is an alternative configuration.
Before adoption
Choose the trust namespace carefully: it limits where source Secrets can be read. Secret targets require explicit enablement and additional authorization. Prefer narrowly scoped permissions over granting access to every Secret. Plan a rotation period in which old and new roots overlap, then verify application behavior before removing a root. Back up Bundle resources before uninstalling older deployments, because the documented CRD retention behavior differs across releases.
Use the installation guide and bundle documentation for the selected release.
Sources & further reading
Spotted something that needs another look?
Help improve this page →