cert-manager is a Kubernetes add-on that automates the lifecycle of X.509 certificates. A Certificate resource states which names a certificate must cover and which issuer should sign it, and cert-manager obtains it, stores the key and certificate in a Secret, and renews it before it expires. It addresses a failure that most operations teams have seen: certificates that were issued by hand, forgotten, and expired in production. By treating certificates as declarative objects with automatic renewal, it turns TLS from a periodic chore into background infrastructure that supports both public HTTPS and internal mutual TLS. cert-manager was created at Jetstack in 2017, which is now part of Venafi and CyberArk. It joined the CNCF Sandbox in November 2020, became an incubating project in 2022 and graduated in November 2024. Release 1.21 was published on July 8, 2026.
CNCF daily · Sprint 1, day 5 · Security & Compliance
At a glance
| Category | Security & Compliance |
| CNCF status | Graduated. Sandbox since November 2020; Incubating 2022; graduated November 2024 |
| Written in | Go |
| License | Apache 2.0 |
| Issuers | ACME (Let’s Encrypt and others), HashiCorp Vault, Venafi, self-signed and built-in CA, plus external issuers such as AWS Private CA and Google CAS |
| Challenge types | ACME HTTP-01 and DNS-01 |
| Integrations | Ingress, Gateway API, Istio, Envoy, Prometheus and SPIFFE |
| Related projects | trust-manager for CA bundles, csi-driver and istio-csr for workload certificates |
| Latest release | 1.21 (July 8, 2026); 1.20 (March 10, 2026) also supported |
Architecture
flowchart TB
USER[Certificate resource<br/>or annotated Gateway and Ingress] --> CTRL
subgraph CM[cert-manager in the cluster]
CTRL[Controller<br/>issuers, certificates, orders] --> ISS[Issuer or ClusterIssuer]
WH[Webhook<br/>validates resources] --- CTRL
CA[cainjector<br/>injects CA bundles] --- CTRL
end
ISS -->|ACME| LE[Let's Encrypt or other ACME CA]
ISS -->|sign request| V[Vault, Venafi or private CA]
LE -->|HTTP-01 or DNS-01 challenge| CTRL
CTRL -->|solve DNS challenge| DNS[DNS provider<br/>Route 53, Cloud DNS]
CTRL -->|writes key and certificate| SEC[Kubernetes Secret<br/>tls.crt and tls.key]
SEC --> GW[Gateway, Ingress or workload<br/>serves TLS]
CTRL --> MON[Prometheus metrics<br/>expiry and readiness]
| Component | Responsibility |
|---|---|
| Certificate | Declares the desired certificate: DNS names, duration, renewal window, key settings and issuer, plus the Secret to write. |
| Issuer and ClusterIssuer | Describe how certificates are signed. An Issuer is namespaced, and a ClusterIssuer is available cluster-wide. |
| CertificateRequest, Order and Challenge | Internal resources that carry a single signing request, an ACME order and each domain validation step. |
| Controller | Watches these resources, creates keys, talks to the issuer and renews certificates ahead of expiry. |
| Webhook | Validates and defaults cert-manager resources at admission time. |
| cainjector | Copies CA certificates into webhook and API service configurations so that components trust each other. |
| Metrics | Exposes certificate expiry times, readiness and controller activity for Prometheus. |
Design principle. cert-manager applies the controller pattern to certificates: the desired state is a resource, and a reconciliation loop keeps the real certificate valid. Issuance is separated from consumption, so a gateway or application only reads a Secret, while the choice of CA, challenge type and renewal policy lives in issuer and certificate objects that are reviewed and versioned like any other configuration.
Production reference design
A common pattern on EKS, GKE, AKS or on-premises Kubernetes: public certificates from Let’s Encrypt for ingress and gateways, and a private CA or Vault for internal mutual TLS.
- Install cert-manager with Helm, including its CRDs, and pin a current supported release:
helm install cert-manager oci://quay.io/jetstack/charts/cert-manager \ --version <version> --namespace cert-manager --create-namespace \ --set crds.enabled=true kubectl -n cert-manager get pods - Create a ClusterIssuer for Let’s Encrypt. DNS-01 validation works for wildcards and does not need the cluster to be reachable from the internet. This example uses Route 53 with a cloud identity attached to the controller:
Test against the Let’s Encrypt staging endpoint first to avoid rate limits.apiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: { name: letsencrypt-prod } spec: acme: server: https://acme-v02.api.letsencrypt.org/directory email: platform@example.com privateKeySecretRef: { name: letsencrypt-prod-account-key } solvers: - dns01: route53: { region: ap-south-1 } - Request a certificate and let a gateway or ingress consume the resulting Secret:
With the Gateway API, annotate the Gateway with the issuer name instead and cert-manager creates the Certificate for each TLS listener. Check the field names and the Gateway API support level for the cert-manager version you install.apiVersion: cert-manager.io/v1 kind: Certificate metadata: { name: example-com-tls, namespace: edge } spec: secretName: example-com-tls issuerRef: { name: letsencrypt-prod, kind: ClusterIssuer } dnsNames: [example.com, "*.example.com"] privateKey: { rotationPolicy: Always } - Add a private issuer for internal traffic. Use a Vault, Venafi or private CA issuer for service-to-service mutual TLS, and use trust-manager to distribute the CA bundle to workloads.
- Monitor expiry and failures. Scrape the controller metrics, alert on certificates close to expiry and on certificates that are not ready, and check
kubectl describe certificateand the Order and Challenge objects when issuance stalls. - Protect the keys and the account. Keep issuer credentials in Secrets with tight RBAC, restrict who can create Certificates and ClusterIssuers, and back up the ACME account key.
Typical production uses include TLS for ingress and gateways, wildcard certificates, mutual TLS between services through a private CA, certificates for webhooks and operators, and short-lived workload identity certificates.
Operational considerations
- Plan DNS-01 access carefully. Granting the controller permission to edit DNS is powerful. Use a dedicated zone or a scoped role, prefer cloud identity over long-lived keys, and consider delegating the challenge domain.
- Mind issuer rate limits. Public CAs limit issuance per domain and per week. Use the staging endpoint while testing and avoid creating many separate certificates for the same names.
- Do not let certificates expire quietly. Alert on expiry and on a failed Ready condition, and keep renewal windows generous, since a webhook or DNS outage can delay renewal.
- Upgrade with the release notes. Minor releases arrive roughly every four months and only the two latest are supported. Read the breaking changes, such as the Helm value and RBAC changes in 1.21, and keep CRDs current.
- Control who can issue. Anyone who can create a Certificate against a ClusterIssuer can obtain certificates for permitted names, so use namespaced Issuers, policy tooling such as approver-policy, and RBAC.
Adoption
- The CNCF graduation announcement reported more than 500 million downloads per month and more than 450 contributors and over 200 releases, and said 86 percent of new production clusters adopt the tool.
- Giant Swarm was named as using cert-manager in its Cluster API based Kubernetes platform.
- cert-manager integrates with other CNCF projects, including Istio, Envoy and Prometheus, and is a standard component of ingress, gateway and service mesh installations.
Alternatives
| Solution | Model | Best suited to |
|---|---|---|
| Cloud certificate services (AWS ACM, Google managed certificates) | Managed certificates tied to load balancers | Teams that terminate TLS only on cloud load balancers |
| Certbot and acme.sh | ACME clients for single hosts | Standalone servers and virtual machines |
| Traefik and Caddy built-in ACME | Automatic certificates inside the proxy | Simple deployments of one proxy |
| HashiCorp Vault PKI | Internal certificate authority with APIs | Short-lived internal certificates, often used together with cert-manager |
| SPIFFE and SPIRE | Workload identity with X.509 identities | Zero-trust service identity rather than public TLS |
Strengths and limitations
| Strengths | Limitations |
|---|---|
| Automatic issuance and renewal as declarative Kubernetes resources | Another controller and CRDs to operate and upgrade |
| Many issuer types, from Let’s Encrypt to Vault and cloud CAs | Challenge setup, especially DNS-01 permissions, needs care |
| Works with ingress controllers, Gateway API and service meshes | Public CA rate limits can block issuance during mistakes |
| Metrics and conditions for expiry and failures | Issuance failures can be hard to trace across several resources |
| Large community and a documented release and support policy | Short support window, with only the latest two minor versions supported |
Recommendation
Adopt cert-manager on any Kubernetes cluster that serves TLS, using a ClusterIssuer for Let’s Encrypt with DNS-01 validation for public names and a Vault or private CA issuer for internal mutual TLS. Alert on expiry, restrict who can issue certificates, and keep it within the two supported release lines. Where TLS is terminated only on a managed cloud load balancer, the provider’s certificate service may be enough.
References: CNCF project page · CNCF graduation coverage, SecurityBrief · cert-manager documentation · Supported releases · cert-manager 1.21 release notes · cert-manager on GitHub