kubectl certificate: Usage, Options & CI Errors
Approve or deny pending certificate signing requests.
kubectl certificate approve/deny acts on CertificateSigningRequests (CSRs) - the requests nodes and clients make for signed certs. It appears in node-bootstrap automation and custom PKI flows.
What it does
kubectl certificate approve NAME marks a pending CSR approved so the signer issues a certificate; deny rejects it. You typically list candidates with kubectl get csr first, then approve the matching ones. In managed clusters a controller auto-approves node CSRs; manual approval is for custom or kubelet-serving certs.
Common usage
kubectl get csr
kubectl certificate approve csr-abc123
kubectl get csr -o name | xargs kubectl certificate approve # bulk
kubectl certificate deny csr-suspiciousCommon errors in CI
"Error from server (NotFound): certificatesigningrequests.certificates.k8s.io \"X\" not found" usually means the CSR expired and was garbage-collected (CSRs are short-lived) before your automation approved it. Approve promptly or recreate. Approving an already-approved CSR is a no-op but reads as success; denying an approved one will not un-issue the cert. Bulk-approving every pending CSR with xargs is a security risk in untrusted clusters. Only auto-approve CSRs you can attribute to known requesters.
Using this in CI
A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods
# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info
# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes