cert-manager: Automatic TLS Certificate Management for Kubernetes

What cert-manager does and who it is for

TLS certificates in Kubernetes clusters expire and must be renewed. Without automation, operators must track expiry dates, generate renewal requests, update Secrets, and restart services, a process that scales poorly across many services and certificates. cert-manager eliminates that toil by adding two custom resource types: Certificate and Issuer (or ClusterIssuer). Once a Certificate resource is created, cert-manager handles the entire lifecycle including initial issuance, storing the certificate and private key in a Kubernetes Secret, and renewing the certificate before it expires.

The tool is aimed at Kubernetes cluster operators and platform engineers who need reliable, policy-driven TLS for Ingress resources, internal services, or mutual TLS between pods. The README states that cert-manager ensures certificates remain valid and up to date, attempting renewal at an appropriate time before expiry to reduce the risk of outages.

Supported issuers: Let's Encrypt, Vault, and CyberArk

cert-manager supports multiple certificate sources. Let's Encrypt uses the ACME protocol, automating domain validation challenges (HTTP-01 and DNS-01) to issue publicly trusted certificates at no cost. For DNS-01 challenges, the go.mod file shows built-in support for Route53, Azure DNS, Google Cloud DNS, DigitalOcean, Akamai, and others.

HashiCorp Vault integration allows cert-manager to request certificates from an internal PKI, which is the standard pattern for issuing short-lived, automatically rotated certificates for service-to-service authentication inside a cluster. CyberArk Certificate Manager is also listed as a supported source in the README.

For local in-cluster issuance without an external service, cert-manager can act as its own CA, signing certificates with a private key stored in a Kubernetes Secret. This is useful for development clusters or internal services that do not need publicly trusted certificates.

Installing cert-manager with Helm

The README states that installation is documented on cert-manager.io/docs/installation/ with a variety of supported methods. Helm is the most common path. The project publishes charts to Artifact Hub under the cert-manager repository, listed in the related searches as cert-manager helm chart and cert-manager chart.

The Makefile in the repository is generated automatically and handles the build and test infrastructure for contributors. For cluster operators who only want to deploy cert-manager, the installation guide on cert-manager.io covers the Helm chart values, ClusterIssuer configuration for Let's Encrypt, and the standard verification step to check that the cert-manager pods are running.

The quick start guide at cert-manager.io/docs/tutorials/acme/nginx-ingress/ covers the common case of automatically issuing TLS certificates for Ingress resources using Let's Encrypt and an nginx-ingress controller, which is the most common entry point for new users.

Architecture: controllers, webhooks, and CRDs

cert-manager runs as a set of controllers inside the cluster. The cmd/ directory in the repository contains the entry points for the main controller manager, the webhook server, and the cainjector. The webhook validates and mutates Certificate and Issuer resources at admission time, preventing misconfigured resources from entering the cluster. The cainjector injects CA data into webhook configurations automatically.

The go.mod file confirms the Kubernetes API dependencies: k8s.io/api, k8s.io/apimachinery, k8s.io/apiserver, and k8s.io/client-go, all at 0.37.1, alongside k8s.io/apiextensions-apiserver for the CRD support.

The README warns explicitly about the Go module stability guarantee. Code under pkg/ can change in a breaking way between minor and patch releases, even though it is publicly exported. The import path changed at version 1.8 from github.com/jetstack/cert-manager to github.com/cert-manager/cert-manager. Applications that import cert-manager as a library must handle this and pin versions carefully.

Limitations and operational considerations

cert-manager requires cluster-admin access to install because it creates CRDs and cluster-scoped resources. In multi-tenant clusters, this is a shared piece of infrastructure, meaning a cert-manager upgrade or misconfiguration can affect all namespaces.

Renewal timing is configured through Certificate resources, but the actual renewal point depends on the certificate's validity period and cert-manager's renewal window. The README does not document the default renewal window explicitly; it is set in the controller configuration. Teams with strict renewal SLAs should verify the default and override it if needed.

For ACME DNS-01 challenges, cert-manager must be able to create DNS records. In environments with locked-down DNS (common in enterprise networks), the HTTP-01 challenge is usually easier to permit, but it requires that the domain being validated is publicly reachable, which rules it out for internal services.

The go.mod file lists golang.org/x/crypto as a dependency, and the .trivyignore file in the repository indicates that the project actively tracks known CVEs in its dependency tree. The README also notes that macOS has extra requirements for the development environment and that contributors should read the Building cert-manager page before starting. The ROADMAP.md file documents planned work, giving teams visibility into direction before committing to the project.

Community, governance, and licence

cert-manager is a CNCF (Cloud Native Computing Foundation) project. The repository contains a GOVERNANCE.md, OWNERS, and OWNERS_ALIASES file, indicating a structured project with defined maintainer roles and an established contribution process. The README links to public meetings open to anyone who joins the cert-manager-dev Google Group.

The most recent releases are v1.21.2 from September 11, 2026 and v1.20.4 from September 16, 2026, with the last push on 2026-09-27. Both the 1.20 and 1.21 release lines receive maintenance updates concurrently. The project follows a release schedule documented in RELEASE.md and publishes release notes on cert-manager.io/docs/release-notes/.

The licence is Apache-2.0, permitting use and modification in commercial products without copyleft obligations. Security reports are handled through the process in SECURITY.md rather than public issue tracking, and a SECURITY_CONTACTS.md file lists the named individuals to notify. The USERS.md file documents organizations that have declared their use of cert-manager in production. The CODE_OF_CONDUCT.md applies to all project communication channels including the Google Group and Slack channels.

Editorial conclusion

cert-manager is the standard choice for automated TLS certificate management in Kubernetes. Teams using Let's Encrypt for public certificates or HashiCorp Vault for internal PKI can automate the entire issuance and renewal lifecycle without writing controller code. The main caveat is that cert-manager's Go module API under pkg/ does not provide compatibility guarantees between minor or patch releases, so teams who import it as a library should review the import path change at version 1.8 (from jetstack to cert-manager) and pin to a specific version. For cluster operators who only use the CRDs and controllers without importing the Go module, the Kubernetes API version guarantees under the standard deprecation policy do apply.

Frequently asked questions

Official sources

1. cert-manager/cert-manager on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases