cert-manager Automates Certificate Lifecycle. The Certificates Carry No Governance Policy.
by Nick Clark | Published March 28, 2026
cert-manager — the CNCF graduated project that has become the de facto Kubernetes-native certificate controller — automates TLS certificate lifecycle management with deep integrations into Let's Encrypt, HashiCorp Vault, Venafi, and internal certificate authorities. It handles issuance, renewal, rotation, and revocation on behalf of every workload in a cluster, and it removes a substantial operational burden that platform teams used to carry by hand. But the certificates cert-manager produces carry identity and encryption capability; they do not carry governance policy. A valid certificate enables encrypted communication and authenticates the endpoints. It does not enforce what that communication is allowed to contain, what capabilities the certified identity is allowed to exercise, or how the governance posture around that identity must evolve. The gap between certificate automation and cryptographic governance is structural, and it is exactly where the cryptographic-governance primitive — signed policy resolution with capability-credential binding — sits.
Architecture in Brief
cert-manager's Kubernetes-native certificate automation, with its multi-CA integration model and its Issuer/ClusterIssuer/Certificate custom resources, is essential infrastructure for any production cluster that terminates TLS or runs a service mesh. It is the right tool for the lifecycle problem: an Issuer declares a CA backend, a Certificate resource declares a desired certificate, and the controller reconciles the cluster's actual cryptographic material toward the desired state, rotating well before expiry and renewing without human intervention. Integrations with Let's Encrypt cover public-facing endpoints, integrations with HashiCorp Vault and other internal CAs cover private trust roots, and the operator pattern keeps the whole system observable and declarative.
The gap described here is not about lifecycle management. cert-manager solves lifecycle management thoroughly. The gap is about what certificates carry. A certificate is a signed assertion that a particular public key belongs to a particular subject, scoped by validity dates and a small set of extensions. It is not, and was never intended to be, a carrier of governance policy. Yet in modern Kubernetes deployments — service meshes, zero-trust networks, multi-tenant platforms — the certificate is the only durable, cryptographically-attested artifact that travels with the workload. Everything else is policy state held elsewhere, evaluated elsewhere, and only loosely coupled to the cryptographic identity the certificate establishes.
Certificates Authenticate, They Do Not Govern
A TLS certificate issued by cert-manager proves the identity of a service and enables encrypted communication between services. But the certificate does not carry policy about what operations the service is allowed to perform, what data it is allowed to access, what audiences it may serve, or what governance constraints apply to its communications. The certificate says who is communicating; it does not govern what the communication is permitted to be. The result is a familiar split-brain pattern: cryptographic identity lives in one substrate (the PKI, managed by cert-manager), and governance policy lives in another (an admission controller, a policy engine, a service-mesh authorisation layer, or — most often — a patchwork of all three). The two substrates are joined only by string-typed subject names and labels, with no cryptographic binding between the certified identity and the policy that is supposed to govern it.
This matters in practice. When a service's certificate is rotated, the new certificate carries the same identity and the same absence of governance policy. Rotation addresses certificate freshness; it does not address governance evolution. The governance requirements for a service may legitimately change over time — a workload may be promoted from staging to production, a tenant's contractual entitlements may shrink, a regulatory regime may impose new constraints — but the certificate carries no governance to evolve. The policy substrate evolves on its own clock; the cryptographic substrate evolves on its own clock; and at no point does a single signed artifact attest to both.
What Cryptographic Governance Adds
Cryptographic governance, as the architectural primitive defines it, attaches signed policy references to certificates or alongside them — capability credentials bound to the certified identity — specifying the governance constraints that apply. The certified identity and its governing policy become a single resolvable, signed bundle: a verifier presented with the certificate can resolve the bound capability credential, evaluate the signed policy reference, and decide not only whether the peer is who it claims to be but whether the operation it is requesting is one its credential authorises. Certificate rotation, in this model, includes governance policy update as a first-class concern: when the controller rotates the certificate, it also resolves the current policy reference and binds it to the new credential, so the cryptographic substrate and the governance substrate move together.
cert-manager is well-positioned to host this composition. Its Issuer abstraction already mediates between desired state and a CA backend; the same abstraction can mediate between desired governance state and a policy authority that signs capability credentials. Each communication validated against the bundle is validated not only for identity (the existing TLS handshake) but for governance compliance (the bound credential's signed policy reference, resolved against the current policy version). cert-manager's automation, in this composition, extends to governance lifecycle alongside certificate lifecycle, and the split-brain problem closes at the substrate where it belongs — the cryptographic one.
Where the Architecture Takes the Domain
A cluster operating with cryptographic governance composed over cert-manager gains a property that is hard to obtain any other way: every authenticated communication can be evaluated against a current, signed, identity-bound policy without a separate policy lookup against an out-of-band store. Service meshes get authorisation primitives that travel with the certificate. Zero-trust deployments get capability binding that does not depend on a central policy decision point being reachable at request time. Multi-tenant platforms get tenant-entitlement enforcement that is cryptographically attested rather than label-based.
cert-manager continues to do what it does well — lifecycle automation across Let's Encrypt, Vault, and internal CA backends — and the cryptographic-governance primitive composes above it, treating cert-manager's certificate stream as the substrate over which signed policy resolution and capability-credential binding operate. The CNCF ecosystem gains the governance layer it has been building piecewise; cert-manager remains the right operator for the lifecycle problem; and the architectural primitive lands at exactly the place the gap has always been.
