kubectl certificate approve
Approve a CertificateSigningRequest (CSR). Used when manually managing TLS certificates for nodes, users, or webhooks.
kubectl certificate approve CSR_NAME [flags]Common Flags
| Flag | Short | Description |
|---|---|---|
| --force | — | Update the CSR even if it is already approved |
| --allow-missing-template-keys | — | Allow missing keys in templates (default true) |
Examples
Approve a specific CSR
kubectl certificate approve node-csr-abc123Approve all pending CSRs
kubectl get csr -o name | xargs kubectl certificate approveList pending CSRs then approve
kubectl get csr && kubectl certificate approve csr-nameDeny a CSR
kubectl certificate deny csr-nameWhen to Use kubectl certificate approve
kubectl certificate approve is used to approve CertificateSigningRequests (CSRs) in Kubernetes. CSRs are part of the cluster's PKI (Public Key Infrastructure) and are used when nodes, users, or services need TLS certificates signed by the cluster's certificate authority.
Understanding CSRs in Kubernetes
The CSR workflow follows these steps:
- A client (node, user, or service) generates a private key and CSR.
- The CSR is submitted to the Kubernetes API.
- An administrator or automated controller approves the CSR.
- A signer issues the signed certificate.
- The client retrieves the signed certificate.
# View all CSRs
kubectl get csr
# NAME AGE SIGNERNAME REQUESTOR CONDITION
# node-csr-abc123 5m kubernetes.io/kubelet-serving system:node:worker Pending
# csr-user-jane 2m kubernetes.io/kube-apiserver admin Pending
Approving Node CSRs
When new nodes join a cluster, they need TLS certificates:
# List pending CSRs
kubectl get csr | grep Pending
# Inspect the CSR before approving
kubectl describe csr node-csr-abc123
# Look for: Subject, Usages, Requestor, and Condition
# Approve it
kubectl certificate approve node-csr-abc123
# certificatesigningrequest.certificates.k8s.io/node-csr-abc123 approved
# Verify
kubectl get csr node-csr-abc123
# CONDITION: Approved,Issued
Denying CSRs
If a CSR looks suspicious or is unauthorized:
kubectl certificate deny suspicious-csr
Denied CSRs remain in the system for audit purposes.
Creating User Certificates
To create a certificate for a new cluster user:
# 1. Generate a private key
openssl genrsa -out jane.key 2048
# 2. Create a CSR
openssl req -new -key jane.key -out jane.csr -subj "/CN=jane/O=developers"
# 3. Submit to Kubernetes
cat <<EOF | kubectl apply -f -
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
name: jane-csr
spec:
request: $(cat jane.csr | base64 | tr -d '\n')
signerName: kubernetes.io/kube-apiserver-client
usages:
- client auth
EOF
# 4. Approve the CSR
kubectl certificate approve jane-csr
# 5. Retrieve the signed certificate
kubectl get csr jane-csr -o jsonpath='{.status.certificate}' | base64 -d > jane.crt
# 6. Configure kubeconfig for jane
kubectl config set-credentials jane --client-certificate=jane.crt --client-key=jane.key
Signer Names
Kubernetes defines several built-in signers:
| Signer | Purpose |
|--------|---------|
| kubernetes.io/kube-apiserver-client | Client certificates for API authentication |
| kubernetes.io/kube-apiserver-client-kubelet | Kubelet client certificates |
| kubernetes.io/kubelet-serving | Kubelet serving certificates |
| kubernetes.io/legacy-unknown | Legacy signer for backward compatibility |
The signer determines how the certificate is used and who can approve it.
Automatic CSR Approval
For production clusters, manual CSR approval doesn't scale. Configure auto-approval:
# Check if the auto-approver is running
kubectl get pods -n kube-system | grep controller-manager
# The kube-controller-manager includes an auto-approver for:
# - Node bootstrapping CSRs from the system:bootstrappers group
# - kubelet serving certificate renewals
For custom auto-approval, deploy a controller that watches for CSRs and approves them based on policy.
Security Considerations
CSR approval is a security-critical operation:
# Always inspect before approving
kubectl describe csr node-csr-abc123
# Check the requester
# Requestor: system:node:worker-1
# Check the subject
# Subject: CN=system:node:worker-1, O=system:nodes
# Check the usages
# Usages: digital signature, key encipherment, server auth
Verify that:
- The requestor is expected (not an unknown entity).
- The subject CN matches the expected identity.
- The usages are appropriate for the certificate type.
- For node CSRs, the node name matches an expected node.
Monitoring Certificate Expiry
Certificates issued through CSRs have expiration dates:
# Check certificate details
kubectl get csr jane-csr -o jsonpath='{.status.certificate}' | base64 -d | openssl x509 -text -noout
# Look for:
# Not Before: ...
# Not After: ...
Set up monitoring to alert before certificates expire, and ensure renewal processes (manual or automated) are in place.
CKA/CKAD Exam Relevance
CSR approval is a common CKA exam topic. The typical task involves:
- Creating a CSR for a new user.
- Submitting it to the cluster.
- Approving the CSR.
- Setting up kubeconfig with the issued certificate.
- Creating RBAC bindings for the new user.
Practice this workflow to be comfortable under time pressure.
Interview Questions About This Command
Common Mistakes
- Blindly approving all CSRs without verifying the requester identity, which is a security risk.
- Not setting up automatic CSR approval for node bootstrapping, causing nodes to hang during cluster scaling.
- Forgetting that approved CSRs still need a signer to issue the actual certificate.