September 17, 2026
KEY TAKEAWAYS
- Kubernetes uses certificates in three layers, the control plane, ingress, and workload mTLS, and each has a different lifetime and a different failure mode.
- A control-plane certificate expiring can take down the whole cluster; an ingress certificate takes down public services; an mTLS certificate breaks internal traffic.
- cert-manager is the CNCF-graduated standard for automating in-cluster certificates, deployed in an estimated 86 percent of new production clusters.
- cert-manager is an issuance controller, not a certificate authority or an enterprise governance layer, and it manages certificates inside the cluster, not across your estate.
- The complete picture pairs cert-manager’s in-cluster automation with a trustworthy CA behind it and governance that spans clusters and the systems around them.
QUICK ANSWER: WHAT IS KUBERNETES CERTIFICATE MANAGEMENT?
Kubernetes certificate management is the practice of issuing, renewing, and governing the TLS certificates that secure a Kubernetes cluster and its workloads. cert-manager is the CNCF-graduated project that automates this inside the cluster by adding certificates and issuers as native resources. The CNCF reports it now sees 500 million downloads a month and is deployed in about 86 percent of new production clusters.
- Certificates appear in three layers: control plane, ingress, and workload mTLS.
- cert-manager automates in-cluster issuance and renewal from public or private CAs.
- It still needs a certificate authority behind it, and it does not govern certificates outside the cluster.
Quick Facts
| Question | Short Answer |
|---|---|
| Where does Kubernetes use certificates? | Control plane (API server, kubelet, etcd), ingress TLS, and workload mTLS |
| What automates them? | cert-manager for in-cluster issuance; kubeadm handles most control-plane certs |
| Is cert-manager a CA? | No; it is an issuance controller that requests certificates from a CA |
| Who created cert-manager? | Jetstack, now part of Venafi, now CyberArk, now Palo Alto Networks; it is CNCF-graduated |
| Biggest failure mode | An expired control-plane certificate can take the whole cluster offline |
| What cert-manager does not do | Act as a CA, or govern certificates outside the cluster |
Where Does Kubernetes Use Certificates?
Certificates are everywhere in Kubernetes, and it helps to see them as three separate systems rather than one, because they fail in three different ways.
The first layer is the control plane. Kubernetes components authenticate to one another with TLS: the API server, the kubelets on each node, and etcd all present certificates so that only trusted components can talk. Most of these are provisioned and rotated by kubeadm, and they are the highest-stakes certificates in the cluster. When a control-plane certificate expires, kubectl stops working, pods cannot be scheduled, and nothing deploys, which is to say the cluster effectively goes down.
The second layer is ingress. When traffic enters the cluster from outside, a certificate terminates TLS at the edge, the same public certificate a browser or API client validates. When one of these expires, your public-facing services start throwing certificate errors, which is the outage users notice first.
The third layer is workload-to-workload traffic. Microservices inside the cluster increasingly authenticate to each other with mutual TLS, each carrying its own identity certificate, often issued and rotated by a service mesh. When one of these expires, internal communication between services breaks, which can be harder to diagnose because the cluster still looks healthy from the outside. Three layers, three lifetimes, three failure modes, and a certificate strategy has to account for all of them. Public certificates in every one of these layers are also getting shorter-lived: the CA/Browser Forum’s phased schedule is cutting maximum TLS validity toward 47 days by 2029, which turns manual or loosely automated certificate handling in any of these three layers from a periodic chore into a near-constant one.
What Is cert-manager, and Why Is It the Standard?
Before cert-manager, certificate handling inside Kubernetes was a patchwork. One team would script a tool like certbot on a jump host and copy the resulting files into a Secret by hand. Another would use a sidecar that rewrote files on disk. A third would bake a year-long certificate into a Helm chart and forget about it until an outage reminded them. The cluster knew nothing about any of it, and certificates arrived from outside as opaque blobs that expired without anyone watching.
cert-manager changed the model by making certificates a native part of the cluster. It adds Issuer, ClusterIssuer, and Certificate as custom resources, so a workload can request a certificate declaratively, the same way it asks for any other Kubernetes object, and cert-manager requests it from a configured source, installs it into a Secret, and renews it automatically before expiry. It began as kube-lego at Jetstack in 2016, was renamed cert-manager in 2018, joined the CNCF in 2020, and reached Graduated status in 2024, the CNCF’s highest maturity level. It now sees around 500 million downloads a month and, by the CNCF’s estimate, runs in roughly 86 percent of new production clusters.
Its reach is broad. It issues from public authorities like Let’s Encrypt and from private and external issuers including HashiCorp Vault, AWS Private CA, and Google CAS, it integrates with Istio and Linkerd for service-mesh mTLS through components like istio-csr, and it supports the Gateway API as ingress evolves. For automating certificates inside a cluster, it is the default, and deservedly so.
Where cert-manager Stops
cert-manager is excellent at what it does, and knowing where its job ends is the difference between a setup that holds and one that surprises you. Three boundaries matter.
First, cert-manager is an issuance controller, not a certificate authority. It requests and manages certificates, but something else has to sign them. Point it at Let’s Encrypt and you inherit rate limits and public-only issuance. Point it at a self-signed issuer and you own a CA whose keys, trust, and security are now your responsibility. The quality and governance of the CA behind cert-manager is a decision cert-manager does not make for you, and getting it wrong means either brittle issuance or an unmanaged signing key at the root of your cluster’s trust.
Second, its world is the cluster. cert-manager manages certificates for the Kubernetes objects it knows about. It does not inventory the certificate on your external load balancer, the one on a legacy database the cluster talks to, or the certificates living in a second cluster or another cloud. In an enterprise with certificates spread across many environments, cert-manager is one island of automation, not a map of the whole estate, and the outages that hurt most tend to come from the certificate nobody was watching.
Third, it is a Kubernetes-native tool with a Kubernetes-native audit story. That is a feature inside the cluster and a gap at the enterprise level, where security teams want one policy model and one audit trail across certificates, secrets, and keys, in and out of Kubernetes. There is also a quiet supply-chain footnote worth knowing: cert-manager was created by Jetstack, which became part of Venafi, which was acquired by CyberArk, which is now part of Palo Alto Networks. The project is healthy and CNCF-governed, so this is context rather than a warning, but the tool at the center of most clusters’ certificate automation now has a long commercial lineage behind it.
How Should You Manage Each Layer?
A workable strategy treats the three layers according to their risk and their tooling:
| Layer | What It Secures | How to Manage It |
|---|---|---|
| Control plane | API server, kubelet, etcd authentication | kubeadm handles issuance and rotation; monitor expiry closely, as failure downs the cluster |
| Ingress | Public-facing TLS at the cluster edge | cert-manager from a public or private CA; automate renewal well before expiry |
| Workload mTLS | Service-to-service traffic inside the cluster | Service mesh plus cert-manager, backed by a CA that can issue short-lived certs at volume |
| The whole estate | Certs across clusters, clouds, and legacy systems | A governance layer that inventories and governs beyond any single cluster |
The first three rows are where most guides stop. The fourth is the one that decides whether certificate management scales past a single cluster, and it is the layer cert-manager was never meant to cover.
How Akeyless Approaches Kubernetes Certificate Management
The Challenge
A platform team can automate in-cluster certificates with cert-manager and still be exposed on two fronts: the certificate authority behind it, which is either a rate-limited public CA or a self-managed signing key nobody wants to own, and the certificates outside the cluster that cert-manager cannot see. On top of that, certificates end up governed separately from the secrets and keys the same workloads consume, so there is no single view of who can access what.
The Approach
Akeyless sits behind and around cert-manager rather than replacing it. As PKI-as-a-service, it can be the certificate authority cert-manager issues from, providing a managed private CA with keys protected by Distributed Fragments Cryptography, so there is no rate-limited public dependency and no self-managed signing key at the root of the cluster’s trust. It issues short-lived certificates at the volume workload mTLS needs, and it governs certificates across clusters, clouds, and the legacy systems around them in one place. Because Akeyless also injects secrets into Kubernetes workloads at runtime and issues dynamic credentials, the certificate a pod presents and the database credential it uses are managed under one policy and one audit trail.
The Outcome
Teams keep cert-manager’s native, declarative workflow and gain a trustworthy CA behind it plus visibility beyond the cluster boundary. The results customers report are fewer certificate outages, a single audit trail spanning certificates, secrets, and keys, and lower total cost of ownership than running a private CA and a separate secrets platform alongside the cluster.
What This Looks Like for Real Teams
Progress runs across AWS, Azure, and GCP, the multi-cluster, multi-cloud reality where per-cluster tooling stops being enough, and moved to a managed control plane rather than staffing one.
| “Akeyless is true SaaS that allows you to scale. It’s purpose-built to live in the cloud. We saved 70% of our maintenance and provisioning time with Akeyless.”Richard Barretto, Chief Information Security Officer, Progress |
Cimpress consolidated certificate and credential management and reduced the upkeep to nearly nothing.
| “We haven’t had to worry about credential rotation or credential leakage. All of our software that’s running, it just works. It’s been a really smooth, really easy process.”Conor Mancone, Principal Application Security Engineer, Cimpress |
Getting Kubernetes Certificate Management Right
Kubernetes certificate management is really three problems wearing one name, and the mistake is treating it as one. Watch the control-plane certificates closely, because their failure is total. Automate ingress and workload certificates with cert-manager, which has earned its place as the in-cluster standard. Then answer the two questions cert-manager leaves open: what certificate authority signs your certificates, and how do you govern the ones that live outside the cluster. Put a trustworthy CA behind cert-manager and a governance layer around it, and a Kubernetes estate stops generating certificate outages, no matter how many clusters it grows into.
FAQs About Kubernetes Certificate Management
What Is cert-manager Used For?
cert-manager automates the issuance and renewal of X.509 certificates inside Kubernetes. It adds certificates and issuers as native cluster resources, so workloads request certificates declaratively, and it obtains them from public or private certificate authorities and renews them before they expire, mainly for ingress TLS and service-mesh mTLS.
Does cert-manager Handle Control-Plane Certificates?
Generally no. The control-plane certificates for the API server, kubelet, and etcd are provisioned and rotated by kubeadm. cert-manager focuses on certificates for workloads and ingress. Both matter, and the control-plane certificates are the ones whose expiry can take the entire cluster offline, so they warrant close monitoring.
Is cert-manager a Certificate Authority?
No. cert-manager is an issuance controller that requests and manages certificates but does not sign them itself. It relies on a configured issuer, which can be a public CA like Let’s Encrypt, an external CA such as HashiCorp Vault or a managed PKI service, or a self-signed issuer you operate. Choosing and securing that CA is a separate decision.
Do I Need cert-manager if I Use a Service Mesh?
Usually yes, because they cover different layers. A service mesh manages the internal mTLS certificates between pods, while cert-manager typically manages ingress certificates and can also feed the mesh’s issuing certificate. Many setups use cert-manager and a mesh together, with cert-manager integrating through components like istio-csr.
How Do You Prevent Certificate Outages in Kubernetes?
Automate renewal so no certificate depends on someone remembering it, monitor expiry across all three layers with enough lead time to act, and maintain an inventory that reaches beyond a single cluster to the load balancers, databases, and other clusters your certificates live on. Outages almost always trace to a certificate that was expiring and unwatched.
