Certificates API

In this lesson we cover how to manage TLS certificates in Kubernetes and how the Certificates API automates certificate signing and rotation. Traditionally, a cluster administrator generates and protects a cluster signing CA (a private key and root certificate). These CA files are extremely sensitive: anyone who obtains the private key can sign certificates and effectively create identities with cluster privileges. For that reason, the CA key pair must be stored securely — ideally on a dedicated CA server or in a secure key-management solution. In small clusters these CA files are often kept on a control-plane host (for example, kubeadm stores the CA pair there). Initially signing Certificate Signing Requests (CSRs) may be done manually, but as the number of users and workloads grows you should adopt an automated, auditable process. Kubernetes’ Certificates API provides exactly that: it accepts CSRs as API objects, enables administrative review and approval, and — when configured — signs approved CSRs with the cluster signing CA.

A stylized diagram showing two "Admin" user icons on the left and three server/master node illustrations on the right, one labeled "Certificates API." Below the nodes is a numbered list of steps: "Create CertificateSigningRequest Object," "Review Requests," and "Approve Requests."

How the Certificates API workflow looks in practice

A user generates a private key locally and creates a CSR.
The user submits the CSR to the Kubernetes API as a CertificateSigningRequest object.
Administrators list and review pending CSR objects, then approve or deny them (for example, with kubectl).
If approved and if the controller manager is configured to sign, Kubernetes signs the CSR with the cluster signing CA and stores the issued certificate in the CSR object’s status.certificate field.
The user or administrator extracts the issued certificate and combines it with the private key for authentication or TLS.

Best practice: keep the CA signing key tightly controlled and auditable. If the controller manager has the signing key, restrict who can access and modify controller-manager startup files and flags. Quick example: generate a key and CSR locally Generate a private key (creates jane.key):

openssl genrsa -out jane.key 2048
# produces the private key file jane.key

Create a CSR with the private key (creates jane.csr):

openssl req -new -key jane.key -subj "/CN=jane/O=dev-team" -out jane.csr

Preview of a CSR (PEM text):

-----BEGIN CERTIFICATE REQUEST-----
MIICWDCCAUAACAQAwEzERMA8GA1UEAwwIbmV3LXlvZXIwgDQYJKoZIhvcNAQEBBQAD
ggEBAJIBDwAwgggEKAoIBAQDO0WJvN+DXsAJSIrjpNo5vRIBplnzg+6xc9+UvwkKi
... (truncated) ...
-----END CERTIFICATE REQUEST-----

Base64-encode the CSR (to populate the request field in the manifest):

cat jane.csr | base64 -w0
# e.g. LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0KTUlJQ1dEQ0NB...

Create the CertificateSigningRequest manifest

The request field must contain the base64-encoded CSR.
Choose an appropriate signerName and usages for the CSR’s purpose.

Example manifest (v1 Certificates API):

apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: jane-csr
spec:
  signerName: kubernetes.io/kube-apiserver-client
  expirationSeconds: 600 # optional: certificate validity in seconds
  usages:
  - client auth
  request: "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0KTUlJQ1dEQ0NB..."

Choose signerName and usages that match the intended purpose. For client authentication, use kubernetes.io/kube-apiserver-client. For serving certificates (TLS for an API endpoint), use a serving signer such as kubernetes.io/kube-apiserver-serving. Check your cluster’s available signers and your security policy before approving CSRs.

Submit the CSR object to the API:

kubectl apply -f jane-csr.yaml

List pending CSRs:

kubectl get csr
# Example output:
# NAME      AGE   SIGNERNAME                           REQUESTOR            REQUESTEDDURATION   CONDITION
# jane-csr  10m   kubernetes.io/kube-apiserver-client  admin@example.com    10m                 Pending

Approve a CSR (administrator action):

kubectl certificate approve jane-csr
# certificatesigningrequest.certificates.k8s.io/jane-csr approved

View the CSR including its status and the issued certificate (if signed):

apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  creationTimestamp: "2026-02-03T11:45:00Z"
  name: jane-csr
  uid: 9c1a8c5e-3b9a-4f9e-8b4d-1a2f3c4d5e6f
spec:
  signerName: kubernetes.io/kube-apiserver-client
  expirationSeconds: 600
  usages:
  - client auth
  request: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0KTUlJQ1dEQ0NBVUFJQkRSVUpV...
status:
  conditions:
  - type: Approved
    status: "True"
    reason: KubectlApprove
    message: "This CSR was approved by kubectl certificate approve."
    lastUpdateTime: "2026-02-03T11:46:10Z"
  certificate: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRV...

Extract the issued certificate (the status.certificate field is base64-encoded) and save it as jane.crt:

kubectl get csr jane-csr -o jsonpath='{.status.certificate}' | base64 --decode > jane.crt

You can then provide jane.key and jane.crt to the user for client authentication or TLS. Common signerName and usages examples

Purpose	Common `signerName`	`usages`
API client certs	`kubernetes.io/kube-apiserver-client`	`client auth`
API server serving certs	`kubernetes.io/kube-apiserver-serving`	`server auth`
General-purpose (cluster provisioners)	cluster-specific signers	`client auth`, `server auth`, `key encipherment`, `digital signature`

Controller behavior and where signing happens All certificate automation is implemented by controllers in the kube-controller-manager. These controllers:

Expose pending CertificateSigningRequest objects for administrators to review.
Optionally auto-approve CSRs based on configured rules.
Sign CSRs using the cluster signing CA when allowed.

For the controller manager to sign CSRs it needs access to the cluster signing CA key and certificate (for example, via --cluster-signing-cert-file and --cluster-signing-key-file). Because possession of these files grants signing authority, they must be stored and accessed securely — preferably using a secure key-management solution and with strict access controls on the controller manager.

A stylized diagram of a Kubernetes control plane inside a dotted host. It shows four components: kube-apiserver, etcd Server, Controller-Manager, and kube-scheduler.

Commands cheat sheet

Action	Command
Create CSR object	`kubectl apply -f jane-csr.yaml`
List CSRs	`kubectl get csr`
View CSR details	`kubectl describe csr jane-csr`
Approve CSR	`kubectl certificate approve jane-csr`
Deny CSR	`kubectl certificate deny jane-csr`
Extract issued cert	`kubectl get csr jane-csr -o jsonpath='{.status.certificate}' \| base64 --decode > jane.crt`

Summary

The Certificates API allows users to submit CSRs as Kubernetes objects that administrators can review and approve.
Administrators use kubectl (or automated workflows) to approve or deny CSRs.
The kube-controller-manager can sign approved CSRs if it is configured with the cluster signing CA (--cluster-signing-cert-file and --cluster-signing-key-file).
Securely store and limit access to the cluster signing CA key pair — compromise of that key lets an attacker mint cluster certificates.

Store the cluster signing CA key pair securely and restrict access to the controller manager. Compromise of these files allows forging cluster identities.

Introduction

Core Concepts

Scheduling

Logging & Monitoring

Application Lifecycle Management

Cluster Maintenance

Security

Storage

Networking

Design and Install a Kubernetes Cluster

Install "Kubernetes the kubeadm way"

Troubleshooting

Helm Basics (2025 Updates)

Kustomize Basics (2025 Updates)

Other Topics

Mock Exams

Watch Video

Practice Lab