Learn PKI - cert-manager: Kubernetes Certificate Automation

#Introduction

In the previous episode, episode 9, you built step-ca as a modern private CA with ACME support, provisioners, and SSH. One thing may have felt missing: all of it is still managed per machine. In Kubernetes, managing certificates per pod or per service manually is a nightmare — pods change, names change, and the certificate volume keeps growing. Episode 10 answers with cert-manager, the component that has become the de facto standard for certificate automation in the Kubernetes ecosystem.

It talks to many CA sources, from Let's Encrypt to step-ca, then issues, renews, and manages certificates as ordinary Kubernetes resources. Version 1.21, released in July 2026, is our focus: architecture and CRDs, installation via Helm with the kubectl plugin, Certificates for Ingress and mTLS, flagship features such as ACME profiles and ExternalIssuer, and trust-manager.

#What is cert-manager 1.21

cert-manager is a controller that runs inside the cluster and automates the X.509 certificate lifecycle. It treats certificates as declarative: you write a resource stating which certificate you want, and the controller realizes it — including renewing before expiry. Version 1.21 brings refinements to ACME integration, ExternalIssuer, and Gateway API support.

#Basic Architecture

cert-manager consists of a main controller and a webhook that validates resources before they are stored in etcd. The controller continuously observes cluster state and compares it with your intent. Differences between the two trigger actions: issuing, renewing, or repairing certificates.

#CRDs Used

• Issuer and ClusterIssuer: define the CA source — for example Let's Encrypt or step-ca — along with its credentials.
• Certificate: the core resource stating the intent, including the target secret name and duration.
• CertificateRequest: the translation of a Certificate into an issuance request waiting for the Issuer's approval.
• Order and Challenge: internal resources used by the ACME flow.

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: internal-ca
  namespace: default
spec:
  ca:
    secretName: root-ca-secret

The example above is a ca-type Issuer that issues certificates using a root CA stored in a Secret. The difference between Issuer and ClusterIssuer is only scope: an Issuer is limited to one namespace, while a ClusterIssuer applies across the entire cluster.

#Installation via Helm

The most common way to install cert-manager is through the official Helm chart from Jetstack. Since a certain version, CRDs are installed together with the chart, so no separate step is needed.

helm repo add jetstack https://charts.jetstack.io
helm repo update
helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager --create-namespace \
  --set crds.enabled=true

#kubectl cert-manager Plugin

For debugging and day-to-day operations, cert-manager provides a kubectl plugin that shortens many commands. The plugin helps inspect certificate status, force renewals, and check the causes of issuance failures.

kubectl cert-manager status certificate web01-tls
kubectl cert-manager renew web01-tls

#Certificate Resources for Real Scenarios

#Certificates for Ingress

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: web01-tls
  namespace: default
spec:
  secretName: web01-tls
  duration: 2160h
  renewBefore: 720h
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  dnsNames:
    - web01.internal
    - api.internal

Notice the duration and renewBefore: the certificate is requested to be valid for 90 days and renewed 30 days before expiry. When the web01-tls Secret is used by an Ingress, its contents are updated automatically every renewal cycle without human intervention. Prolonged renewal failures will be visible from the Certificate's conditions.

#mTLS Between Services

cert-manager is also reliable for internal mTLS. Each service can get a client certificate with specific usages, for example client auth, so service-to-service communication can be verified both ways — exactly like the mTLS we built manually in episode 7.

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: billing-client
  namespace: billing
spec:
  secretName: billing-client
  usages:
    - client auth
  issuerRef:
    name: internal-ca
    kind: ClusterIssuer
  commonName: billing-client

The usages section restricts the certificate's use to client authentication only, so the certificate cannot be misused for other purposes. With this pattern, you get per-service identity that is automatically rotated — the foundation of zero trust at the network level.

#cert-manager 1.21 Flagship Features

#ACME Cert Profiles

cert-manager follows the ACME Profiles development we discussed in episode 8. When a CA supports named profiles, cert-manager can request a certificate with a specific profile via the Certificate resource configuration, so policies such as validity period are controlled by the CA, not only the client.

#ExternalIssuer: step-ca and Venafi

One of cert-manager's biggest strengths is the ExternalIssuer API, which opens the door to any CA system. Through this contract, projects such as step-ca and Venafi provide their own controllers that communicate with cert-manager. The result: cert-manager is not tied to a single vendor.

For step-ca, this integration is called step-issuer. You define a StepIssuer resource pointing to a step-ca instance and the provisioner used, then any Certificate can use it as the issuance source.

apiVersion: certmanager.step.sm/v1beta1
kind: StepIssuer
metadata:
  name: step-issuer
  namespace: cert-manager
spec:
  caURL: https://ca.internal
  provisionerRef:
    name: admin

With step-issuer, all of cert-manager's automation leverages step-ca's capabilities from episode 9 — including templates, provisioner policy, and renewal with dedicated credentials — without leaving the Kubernetes workflow. In addition, cert-manager keeps expanding support for the Gateway API, the new standard for traffic that replaces the Ingress role with Gateway and HTTPRoute objects; its certificates are still managed via the ordinary Certificate resource.

#Auto-Renewal and Revision History

One of cert-manager's biggest selling points is auto-renewal. The controller monitors every Certificate and renews before expiry according to renewBefore. Each renewal produces a new revision in the target Secret, so a rollback to a previous version is possible if a problem occurs.

kubectl describe certificate web01-tls

kubectl describe certificate shows the condition history, including when the last renewal happened and whether there were any failures. The revision history in the Secret makes inspection easier when unexpected changes occur.

#trust-manager for Trust Store

Issuing certificates alone is not enough — applications also need to trust the CA that issued them. This is where trust-manager comes in. This component from the cert-manager project packages CA bundles from various sources into a single ConfigMap or Secret that can be mounted into applications.

apiVersion: trust.cert-manager.io/v1alpha1
kind: Bundle
metadata:
  name: root-ca-bundle
spec:
  sources:
    - useDefaultCAs: true
    - secret:
        name: root-ca
        key: ca.crt
  target:
    configMap:
      key: ca-bundle.crt

useDefaultCAs includes the system CAs, while the secret source adds your internal root CA. The result: a single, consistent trust store file across all workloads. Combine it with episode 5 about root certificate distribution — trust-manager automates the part that used to be done manually. Remember, cert-manager does not modify an application's trust store directly, so pair it with trust-manager so the CA bundle is always distributed and updated automatically to every workload.

#Closing

Episode 10 closes the automation gap in Kubernetes. You recognized cert-manager's architecture and CRDs, installed it via Helm with the kubectl plugin, created Certificates for Ingress and mTLS, leveraged the ACME profiles and ExternalIssuer features for step-ca integration, and completed the flow with trust-manager.

Key takeaways:

• cert-manager automates certificate issuance and renewal in Kubernetes through declarative CRDs.
• Issuer and ClusterIssuer define the CA source, while Certificate defines the certificate intent.
• Helm is the standard installation method, complemented by the kubectl cert-manager plugin for debugging.
• The Certificate resource can serve both TLS Ingress and mTLS between services with the right usages.
• ExternalIssuer opens integration with step-ca, Venafi, and other CA systems without vendor lock-in.
• trust-manager completes the flow by distributing the CA bundle to every workload.

In episode 11, we look at a different approach. You will learn CFSSL, Cloudflare's PKI toolkit that was popular in its day: gencert, genkey, certinfo, scan, and online CA mode, plus an honest note on its maintenance status compared to step-ca. See you there!