Skip to main content
This walkthrough demonstrates how to create, approve, deny, and delete Kubernetes CertificateSigningRequest (CSR) objects. We’ll follow a real-world scenario: a new team member (Akshay) needs a client certificate to access the cluster. On the control-plane host we find a CSR and its corresponding private key in /root. The steps below show how to embed the CSR into a Kubernetes CertificateSigningRequest resource, approve it so the cluster issues a certificate, and how to inspect and handle unexpected CSRs.

​
Prerequisites

  • Access to a control-plane node or a machine with kubectl configured to talk to the cluster control plane.
  • The CSR file (PEM) and private key available locally (in this example /root/akshay.csr and /root/akshay.key).

​
Inspect the working directory

Confirm the CSR and private key are present:
View the CSR (truncated for brevity):
When embedding a PEM CSR into the spec.request field of a CertificateSigningRequest manifest, the CSR must be base64-encoded and written as a single continuous line. On Linux, use base64 -w 0 to produce single-line output.

​
Step-by-step: create and approve a CSR

  1. Base64-encode the CSR as a single line and save it to a file:
  1. Create a YAML manifest for the Kubernetes CertificateSigningRequest. Replace the request: value with the single-line base64 string you generated.
Save the following as akshay.yaml:
  1. Apply the CertificateSigningRequest manifest:
  1. Check the CSR list. Newly created CSRs appear in the Pending state until approved:
  1. Approve the CSR so the cluster controller will issue a certificate:
  1. Verify the CSR status is now Approved and Issued:
  1. Extract the issued certificate (base64-decoded) from the CSR object and write it to a PEM file:
This akshay.crt is the PEM certificate issued by the cluster. Pair it with the private key (akshay.key) to use as a client certificate.

​
Inspecting and handling suspicious CSRs

Occasionally you’ll see unexpected CSRs (for example, a CSR requesting cluster-admin groups). Inspect such CSRs closely before approving. Example: a CSR named agent-smith requests privileged groups.
  1. View the CSR YAML to inspect spec.groups, spec.usages, and username:
  1. If you did not expect this request and it requests privileged groups (like system:masters), deny it:
  1. Optionally delete the denied CSR from the cluster:

​
Final verification

Check all remaining CSRs and their conditions:

​
Common CSR commands

​
Notes and best practices

  • Always inspect spec.groups, spec.usages, and username before approving a CSR. Approving a CSR grants the requester the privileges encoded in the certificate.
  • Use the appropriate signerName for the certificate purpose:
    • kubernetes.io/kube-apiserver-client for kube-apiserver clients (client auth).
    • Other built-in signers exist for kubelet serving certificates (e.g., kubernetes.io/kubelet-serving) or custom signers for external issuers.
  • Base64-encode the CSR as a single-line string before embedding it into spec.request.
  • Keep private keys secure at all times. Never commit private keys into source control or store them in cluster manifests.
Do not approve CSRs that request privileged groups (for example system:masters) unless you can verify the identity and intent of the requester. Approving such CSRs can grant cluster-admin access.
This completes the walkthrough for creating, approving, denying, and deleting Kubernetes CertificateSigningRequest objects.

Watch Video