cert-manager is an open source Kubernetes add-on that requests TLS certificates from a certificate authority, stores them for your workloads, and renews them before they expire. It replaces manual certificate handling with declared resources, so an expired certificate stops being a calendar problem and becomes a configuration you can review.
What does cert-manager actually do?
Per the project documentation, cert-manager creates TLS certificates for workloads in a Kubernetes or OpenShift cluster and renews them before expiry. It can obtain certificates from several kinds of certificate authority, including Let's Encrypt, HashiCorp Vault and private PKI.
You describe what you want in a Certificate resource: which DNS names, which issuer, how long. cert-manager does the request, writes the private key and signed certificate into a Kubernetes Secret, and an application pod or an Ingress controller reads that Secret.
What is an Issuer, and why does the difference between Issuer and ClusterIssuer matter?
Every certificate must point at an issuer that is in a ready state. An Issuer represents a certificate authority and lives in one namespace. A certificate in a different namespace cannot use it.
A ClusterIssuer is almost identical but not namespaced, so any namespace can ask it for certificates. That is convenient, and it is also a trust decision. If a team can create a Certificate in its own namespace and point it at a shared ClusterIssuer backed by your internal CA, that team can mint certificates your internal clients trust. Treat the right to create Certificate objects as a privilege, not a default.
How does the certificate authority know you own the name?
For public authorities that use ACME, the protocol in RFC 8555, the server offers challenges and the client proves control of an identifier. The RFC's own examples show an http-01 challenge, where you publish a token over HTTP on the domain, and a dns-01 challenge, where you publish it in DNS.
The practical consequence: http-01 needs the cluster to be reachable from the internet on that name, and dns-01 needs credentials that can write DNS records. Those credentials are worth protecting, because anyone holding them can prove ownership of every name in the zone.
Where does the private key end up?
With the standard Certificate resource, the key and certificate sit in a Kubernetes Secret. Anyone with permission to read that Secret can read the key. The documentation also describes a different pattern with the CSI driver, the SPIFFE CSI driver, or istio-csr, where the private key is generated on demand before the application starts, never leaves the node, and is not stored in a Secret. If your threat model includes people with broad Secret read access, that difference is the thing to evaluate.
A constructed example
Say the shop namespace runs a storefront behind an Ingress, with a Certificate for shop.example.com issued by a ClusterIssuer called letsencrypt-prod. Six months later someone copies the manifest into a staging namespace and keeps the production issuer. Staging now holds a valid certificate for a production name. Nothing is broken, and nobody noticed, which is the usual shape of this problem.
How to check or apply this
- List every certificate in the cluster with
kubectl get certificate -Aand note the issuer and the Ready status of each. - Run
kubectl describe certificateon any that are not Ready and read the events, since failed challenges show up there. - List your ClusterIssuers and decide, for each, which namespaces should be allowed to use it. Enforce that with RBAC on the Certificate resource or with an admission policy.
- Review who can read Secrets of type kubernetes.io/tls. Narrow it where you can.
- Store DNS challenge credentials in their own Secret with tight access, and use credentials scoped to the zone you validate.
- Set an alert for certificates close to expiry, so a stalled renewal reaches a person before it reaches a customer.
- Pin and update the cert-manager version like any other cluster component, and track its releases.
Where does supply chain fit in?
cert-manager is itself software you deploy with cluster-wide permissions, delivered as container images and manifests. That makes it part of your dependency inventory. Safeguard's SBOM and dependency scanning can include the images and charts you run, so a vulnerability in the controller shows up beside your own services.
Quick check
Does cert-manager replace a certificate authority?
No. It is a client and automation layer. It asks a certificate authority such as Let's Encrypt, Vault or a private CA to sign requests, then manages the result in the cluster.
Can one namespace use another namespace's Issuer?
No. An Issuer is namespaced. Use a ClusterIssuer if you want one issuer shared across namespaces, and control who may reference it.
Sources
- cert-manager documentation
- cert-manager: Issuer concepts
- RFC 8555: Automatic Certificate Management Environment (ACME)
Last reviewed: 18 October 2026.
