Table of contents
- Machine Identity Security: The Definitive Guide
- What Is Workload Identity? Securing Non-Human Identities
- What Is a Non-Human Identity (NHI)? Machine Identity Security Explained
- What Is Certificate Management?
-
TLS/SSL Offloading: Definition & Decision Checklist
- TLS/SSL Offloading Explained
- SSL Termination vs. SSL Bridging
- Key Differences in Workflow
- Unit 42 Perspective: Risks of Uninspected Traffic
- Benefits for Security and Infrastructure Teams
- CISO Decision Checklist: SSL Termination vs. SSL Bridging for Compliance
- Detailed CISO Decision Checklist
- Summary Recommendation for CISOs
- TLS/SSL Offloading FAQs
- What Is an X.509 Certificate? Definition, Standards, and Role
-
What Is Certificate Validation? Guide to Best Practices
- Certificate Validation Explained
- The Role of Certificate Authorities and the Chain of Trust
- The Hierarchy of Trust
- The Sequence of the Validation Process
- Types of Certificate Validation Levels
- Unit 42 Insights: The Risk of Identity Exposure
- Threat Behavior Observations
- Troubleshooting Common Validation Failures
- Certificate Validation FAQs
-
What Is Certificate Pinning? Benefits, Risks & Best Practices
- Certificate Pinning Explained
- How Certificate Pinning Works
- Listiche: Key Stages of a Pinning Failure
- Types of Certificate Pinning
- Listiche: Static vs. Dynamic Pinning
- Why Pinning Is Essential for Zero Trust
- Certificate Pinning vs. Standard SSL/TLS
- Benefits of Certificate Pinning
- Risks and Limitations of Certificate Pinning
- When to Use Certificate Pinning
- When to Avoid Certificate Pinning
- Certificate Pinning Best Practices
- Certificate Pinning and Machine Identity Security
- FAQs
- What is Cloud Workload Security? Protection & Best Practices
- What Is ACME Protocol?
-
What is SPIFFE? Universal Workload Identity Framework Guide
- SPIFFE Explained: Solving the Workload Identity Problem
- Core Components of the SPIFFE Standard
- The SPIFFE Workload API
- Why Traditional Secret Management Fails in Cloud-Native Environments
- The Problem of "Secret Zero"
- Vulnerabilities of Static Credentials and Long-Lived Tokens
- IP-Based Security vs. Identity-Based Security
- How SPIFFE Implementation Works: The Attestation Process
- The Role of SPIRE as the Reference Implementation
- Critical Use Cases for Enterprise Security
- SPIFFE FAQs
- What Is an SSL Stripping Attack?
-
What Is a Machine Identity?
- How Do Machine Identities Work?
- Machine Identity Management (MIM) vs. Human IAM
- Architecture Components and Identity Types
- Secrets Management vs. Machine Identity Management
- Lateral Movement and Attacker Workflow
- Cloud Security Implications and CIEM
- Implementation Steps for Machine Identity Security
- Machine Identity FAQs
What Is a cert-manager?
4 min. read
Table of contents
cert-manager is an open-source, cloud-native certificate management controller designed specifically for Kubernetes. It provides a standardized way to automate the issuance, renewal, and management of X.509 machine identities as first-class resource types. By treating certificates as native Kubernetes objects, it ensures that containerized workloads remain secure and encrypted without requiring manual intervention from developers.
-
Kubernetes-native automation: cert-manager automates the issuance, renewal, and use of TLS certificates in Kubernetes and OpenShift environments. -
Reduced outage risk: By renewing certificates before they expire, cert-manager helps prevent service disruptions caused by expired TLS certificates. -
Broad issuer support: cert-manager can integrate with public and private certificate issuers, including Let’s Encrypt, HashiCorp Vault, and internal PKI systems. -
Kubernetes resource model: It manages certificates through native Kubernetes custom resources such as Certificate, Issuer, and ClusterIssuer. -
Cloud-native security operations: cert-manager helps organizations secure ingress, services, and workloads that rely on trusted encrypted connections.
cert-manager Explained
In modern cloud-native environments, the sheer volume of microservices makes manual certificate management impossible. As organizations shift toward cloud security frameworks, every pod and service requires a unique identity to communicate securely.
cert-manager acts as the central brain within a Kubernetes cluster to facilitate this. It monitors the state of certificates and ensures they are valid and up to date, communicating with various "Issuers" to obtain signed certificates when needed.
Without an automated tool, developers would need to manually track expiration dates and update Kubernetes secrets every few months. In a cluster with hundreds of services, this leads to inevitable human error and service downtime. cert-manager abstracts this complexity, allowing teams to define "Certificate" resources once and let the controller handle the background logistics.
Core Components: Issuers and Certificates
To understand the architecture, it is necessary to distinguish between the two primary Custom Resource Definitions (CRDs) that cert-manager introduces.
1. Issuers and ClusterIssuers
Issuers are the resources that define "where" certificates come from. An Issuer is scoped to a single namespace, while a ClusterIssuer is a global resource that can provide certificates to any namespace in the cluster.
2. Certificates
The Certificate resource defines the desired state of a machine identity. It contains metadata such as the Common Name (CN), Subject Alternative Names (SANs), duration, and which Issuer to use:
| Component | Scope | Responsibility |
|---|---|---|
| Issuer | Namespace | Connects to a specific CA for one namespace. |
| ClusterIssuer | Cluster-wide | Provides CA connectivity for the entire cluster. |
| Certificate | Namespace | Defines the requirements for a specific TLS secret. |
| CertificateRequest | Internal | The temporary request sent to the Issuer for signing. |
How cert-manager Automates Machine Identity
The automation process follows a specific controller loop. When a user creates a Certificate resource, cert-manager generates a CertificateRequest. The controller then validates this request against the specified Issuer.
- Request Generation: A developer defines a Certificate resource in YAML.
- Challenge Fulfillment: If using Let's Encrypt, cert-manager handles HTTP-01 or DNS-01 challenges automatically.
- Retrieval: Once the CA signs the request, cert-manager retrieves the signed X.509 certificate.
- Storage: The certificate and private key are stored as a standard Kubernetes Secret.
- Renewal: As the expiration date approaches (usually 30 days prior), cert-manager repeats the process without downtime.
Common Compatible Cloud Platforms
- Amazon EKS: Integrated often with Route53 for DNS challenges.
- Google GKE: Frequently used with Google CAS.
- Azure AKS: Supports integration with Azure Key Vault.
- Red Hat OpenShift: Often utilized for internal ingress security.
Zero Trust and Kubernetes Security Alignment
Implementing zero trust requires that no service is trusted by default, regardless of its location in the network. cert-manager facilitates this by ensuring every workload has a cryptographically verifiable identity.
- Mutual TLS (mTLS): By automating internal CAs, cert-manager allows services to verify each other's identities before exchanging data.
- Least Privilege: Certificates issued with short lifespans reduce the window an attacker can exploit a compromised identity.
- Network Segmentation: Secure machine identities allow for more granular network segmentation policies based on identity rather than just IP addresses.
Unit 42 Insight: Threat actors frequently target misconfigured Kubernetes clusters to move laterally. Unit 42 research indicates that many breaches stem from long-lived, static credentials. Automating short-lived machine identities via cert-manager significantly disrupts the attack lifecycle by making credential theft less effective over time.
Integrating cert-manager into DevSecOps Workflows
A successful DevSecOps strategy shifts security "left," integrating it into the development pipeline. cert-manager enables this by allowing developers to request security resources (certificates) as part of their application deployment code.
Benefits for DevSecOps Teams
- Policy Enforcement: Security teams can define ClusterIssuers that point only to approved CAs and use the CertificateRequest approval API to gate issuance, ensuring certificates meet organizational policy before signing.
- Consistency: Development, staging, and production environments can use the same YAML structure with different Issuers.
- Auditability: Every certificate request is logged within Kubernetes, providing a clear trail for compliance audits.
Comparison: Manual vs. Automated Certificate Management
| Feature | Manual Management | cert-manager Automation |
|---|---|---|
| Speed | Variable (depends on renewal discipline) | Consistent (automated short-lived rotation) |
| Security | Low (Long-lived certs) | High (Short-lived, rotating) |
| Scalability | Non-existent | High (Unlimited services) |
| Visibility | Fragmented | Centralized in the K8s API |
No. While Let's Encrypt is a popular choice for public-facing ingress, cert-manager supports many other issuers, including HashiCorp Vault, Venafi, self-signed, and private CAs via ACME or specific plugins.
Existing certificates stored in Kubernetes Secrets will continue to work until they expire. However, no new certificates will be issued, and existing ones will not renew until the cert-manager pods are restored.
By default, private keys are generated on-cluster and stored directly in Kubernetes Secrets. Since Kubernetes Secrets are base64-encoded and not encrypted at rest by default, teams should enable etcd encryption or use an external secrets store for production key protection.
cert-manager is Kubernetes-native, but related projects (csi-driver, trust-manager) and secret store integrations can project certificates to workloads and systems adjacent to the cluster. For fully external use cases, a broader certificate lifecycle platform is more appropriate.
Yes. By acting as an internal CA or connecting to a private CA, cert-manager can issue certificates to individual pods, enabling mutual TLS for secure service-to-service communication. For east-west workload identity at scale, some organizations use SPIFFE/SPIRE as a purpose-built workload identity framework rather than cert-manager alone. cert-manager and SPIFFE can complement each other: cert-manager handling ingress TLS and SPIFFE handling workload-to-workload identity.
