Upstream cert-manager is a cloud-native certificate management controller originally created by Jetstack (now part of Venafi / CyberArk) and hosted as a CNCF (Cloud Native Computing Foundation) Graduated Project.

While OpenShift packages and supports it as an Operator, understanding the upstream project gives you a complete picture of its architecture, extension points, and advanced capabilities.

1. Core Mission & Mechanics

In standard Kubernetes, managing TLS secrets manually means creating Secret objects containing tls.crt and tls.key, tracking expiration dates manually, and manually rotating them.

Upstream cert-manager automates this entire lifecycle:

1. Issuance: Rejection of static secrets; automatically generates a private key, constructs a Certificate Signing Request (CSR), and sends it to the target CA.
2. Validation: Solves domain ownership challenges (HTTP-01 or DNS-01) automatically.
3. Storage: Injects the resulting signed certificate chain and private key directly into a standard Kubernetes type: kubernetes.io/tlsSecret.
4. Auto-Renewal: Watches certificate expiration dates and triggers renewal workflows (by default, 30 days before expiration) without human intervention.

2. Deep Dive: CRD Architecture

Upstream cert-manager installs a set of Custom Resource Definitions (CRDs) that form a declarative pipeline:

Plaintext

 ┌────────────────────────────────────────────────────────────────────────┐
 │                              Certificate                               │
 │                (High-level user request for a domain)                  │
 └───────────────────────────────────┬────────────────────────────────────┘
                                     │ Generates
                                     ▼
 ┌────────────────────────────────────────────────────────────────────────┐
 │                           CertificateRequest                           │
 │               (Immutable record of a specific CSR attempt)             │
 └───────────────────────────────────┬────────────────────────────────────┘
                                     │ Triggers Challenge
                                     ▼
 ┌───────────────────────────────────┴────────────────────────────────────┐
 │                     Order  ──────►  Challenge                          │
 │               (ACME-specific HTTP-01 / DNS-01 solving)                  │
 └───────────────────────────────────┬────────────────────────────────────┘
                                     │ Writes output to
                                     ▼
 ┌────────────────────────────────────────────────────────────────────────┐
 │                           Kubernetes Secret                            │
 │                        (tls.crt + tls.key)                             │
 └────────────────────────────────────────────────────────────────────────┘

• Certificate: The primary interface for users. You define the dnsNames, issuerRef, duration, renewBefore, and the target secretName.
• CertificateRequest: Created automatically by cert-manager whenever a Certificate needs issuing or renewing. It holds the x509 PEM-encoded CSR and tracks the approval state.
• Order & Challenge: Internal CRDs created specifically for ACME issuers (like Let’s Encrypt). A Challenge represents an individual domain verification check.

3. Supported Issuer Types & Extension Points

Upstream cert-manager natively supports several core issuers, but also allows external plugins via its External Issuer API:

Built-in Issuers

• ACME (Automated Certificate Management Environment): Supports Let’s Encrypt, ZeroSSL, Buypass, and internal ACME servers (like Smallstep).
  • HTTP-01 Challenge: Spins up a temporary pod and routing rule to answer ACME token checks over HTTP on port 80.
  • DNS-01 Challenge: Modifies DNS TXT records via cloud provider APIs (AWS Route53, Cloudflare, Google Cloud DNS, Azure DNS) to prove domain ownership—enabling wildcard certificates (*.example.com).
• HashiCorp Vault: Requests certificates from Vault’s PKI secrets engine.
• Venafi: Integrates directly with enterprise trust management (Venafi Control Plane / TrustProtectionPlatform).
• CA (Certificate Authority): Signs certificates using an existing x509 signing keypair stored in a Kubernetes secret.
• Self-Signed: Generates simple self-signed root or leaf certificates for internal dev/test use.

External Issuers (Out-of-Tree Plugins)

Using custom controllers, cert-manager can delegate issuance to non-native backends, such as:

• Google CAS (Certificate Authority Service)
• AWS Private CA
• SPIFFE / SPIRE
• Step-CA (Smallstep)

4. Advanced Upstream Ecosystem Projects

The cert-manager ecosystem extends beyond the core controller:

A. csi-driver / csi-driver-spiffe

Instead of storing private keys in standard Kubernetes Secret objects (which are mounted as files and persisted in etcd), cert-manager-csi-driver uses the Kubernetes Container Storage Interface (CSI) to mount ephemeral certificates directly into pod memory.

• Private keys are generated locally on the node and never written to etcd.
• When the pod dies, the certificate and key are automatically destroyed.

B. trust-manager

A companion project designed to solve the trust bundle distribution problem. While cert-manager handles leaf certificates, trust-manager safely distributes public CA root bundles (ca.crt) across all namespaces in a cluster, automatically keeping client trust stores in sync.

C. cmctl (CLI Tool)

The official command-line utility for managing cert-manager:

# Check if cert-manager API is ready
cmctl check api
# Manually trigger an immediate renewal of a certificate
cmctl renew my-app-cert -n my-namespace
# Inspect status of a pending certificate request
cmctl status certificate my-app-cert -n my-namespace

5. Upstream cert-manager vs. OpenShift Operator