cert-manager is a Kubernetes add-on that automates SSL/TLS certificate management inside the cluster. It watches resources, requests certificates from supported issuers, renews them before expiration, and stores them for workloads to use. The result is less manual work and fewer outages caused by missed certificate lifecycle tasks.
Expanded Definition
cert-manager is best understood as a Kubernetes certificate lifecycle controller, not just a certificate generator. It watches Kubernetes resources, requests certificates from an issuer, stores the resulting secrets, and keeps track of renewal so workloads can continue serving encrypted traffic without repeated manual intervention.
The term covers the automation layer inside the cluster, while the actual trust decisions still sit with the issuing authority, private key protection, and Kubernetes secret handling. That boundary matters: cert-manager can streamline certificate operations, but it does not replace a PKI, a secure issuer policy, or cluster access control. In practice, teams use it to reduce expiry-driven outages and to standardise how services obtain certificates across namespaces and environments.
One common misunderstanding is to treat cert-manager as if it “secures TLS” by itself. It automates an operational process, and the security outcome depends on how issuers are configured, where keys are stored, and who can change certificate resources. For broader governance context, NIST Cybersecurity Framework 2.0 provides a useful lens on asset protection, resilience, and recovery responsibilities.
Examples and Use Cases
In cluster environments, cert-manager commonly appears in workflows where certificates need to be created and renewed automatically rather than by hand. It is especially useful where services scale frequently or where many internal endpoints must present valid TLS certificates.
- Issuing certificates for an ingress controller so public web traffic terminates with a trusted certificate.
- Renewing service certificates for internal APIs so east-west traffic continues to use encrypted channels.
- Managing short-lived certificates in environments where manual renewal would be too slow or inconsistent.
- Requesting certificates from different issuers for separate namespaces, teams, or applications.
- Standardising certificate provisioning in GitOps or platform engineering workflows so deployments are repeatable.
The practical tradeoff is convenience versus dependency. Automation reduces expiry risk, but it also makes the cluster and its issuer relationship part of the certificate supply chain. If the issuer is unavailable, misconfigured, or blocked by policy, workloads may fail to obtain or renew certificates on schedule.
Security Implications
When cert-manager is misconfigured, the failure is often not dramatic at first. A certificate may renew too late, renew from the wrong issuer, or fail to land in the secret that the workload expects. The result can be service disruption, browser trust warnings, broken internal mTLS, or a silent fallback to weaker trust assumptions if teams compensate informally.
The security impact also extends to control quality. If too many actors can create or modify certificate resources, they can redirect trust paths, request certificates for unintended names, or weaken namespace separation. In Kubernetes, that becomes a governance issue as much as an operational one because certificate automation is tightly tied to secret handling and workload identity.
A practitioner should pay close attention when renewal is automated but monitoring is weak. The most common warning signs are certificates renewing without alerting, issuer failures hiding behind application retries, and secrets being overwritten without a clear ownership model.
Domain and Governance Relevance
cert-manager matters in cloud-native security because certificate lifecycle is part of trust lifecycle. In Kubernetes, certificates are rarely isolated objects; they support ingress, service-to-service encryption, and in some designs workload authentication. That means certificate automation affects availability, confidentiality, and operational continuity at the same time.
For NHI governance, the relevance is indirect but real. Certificates often act as machine credentials for services, agents, and platform components, so automated issuance and renewal can become part of non-human identity control. The governance question is not only whether a certificate exists, but who owns its issuer policy, who can approve its scope, and how revocation or rotation is handled when a workload is retired.
That makes cert-manager a platform control with downstream identity implications. Teams that treat it as a simple convenience layer often miss the lifecycle, ownership, and revocation decisions that determine whether the resulting trust is reliable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | cert-manager affects who can create or alter certificate trust paths. |
| 3 — Data Protection | It automates TLS certificate use for encrypted traffic and secret handling. | |
| 4 — Secure Configuration of Enterprise Assets and Software | Issuer, renewal, and secret delivery settings define secure cluster behavior. | |
| Recommendation — Restrict certificate resource changes to approved admins and platform roles. Protect private keys and TLS secrets with strong storage and access controls. Standardise cert-manager and issuer configuration to prevent unsafe defaults. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication and Access Control | Certificates in Kubernetes often function as machine authentication material. |
| PR.DS — Data Security | cert-manager protects TLS materials that secure data in transit and at rest. | |
| RC.RP — Recovery Planning | Renewal failure can create outages that require rapid restoration of trust. | |
| Recommendation — Treat certificate issuance and renewal as part of access-control governance. Protect certificate secrets and private keys throughout their lifecycle. Add certificate expiry and renewal failure paths to recovery planning. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Inventory and Ownership | Managed certificates are machine credentials that need clear ownership. |
| Recommendation — Assign each certificate and issuer a named owner and lifecycle responsibility. | ||
Related resources from NHI Mgmt Group
- Should production secrets live in environment variables or a secrets manager?
- How should security teams decide when an enterprise password manager needs an upgrade?
- What breaks when a password manager depends on unsupported integrations?
- What should teams check before they plan a password manager upgrade?
