Wiki · Concept · Last reviewed June 25, 2026

Kubernetes CertificateSigningRequest

Kubernetes CertificateSigningRequest is the API resource for asking a named signer to issue an X.509 certificate.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: Kubernetes, certificates, X.509, identity, AI governance

Definition

Kubernetes CertificateSigningRequest is a certificates.k8s.io/v1 API resource for obtaining X.509 certificates through the Kubernetes API. Kubernetes documentation marks CertificateSigningRequest as stable since Kubernetes v1.19. The resource lets a client submit a certificate signing request, identify the intended signer with spec.signerName, wait for approval or denial, and then receive the issued certificate through status.certificate if the signer completes the request.

The API is part of Kubernetes certificate and trust-bundle machinery. It is used by kubelets for client certificates that authenticate to the API server and for serving certificates used by kubelet TLS endpoints. It can also be used to request client certificates for the API server or to integrate custom non-Kubernetes signers.

How It Works

A requester first generates a private key and a PKCS#10 certificate signing request outside the Kubernetes API. The Kubernetes object stores the PEM-encoded request in spec.request; when written as JSON or YAML, that value is base64 encoded. After certificates.k8s.io/v1, spec.signerName is required. Kubernetes v1.22 and later also allow spec.expirationSeconds, with a documented minimum of 600 seconds.

The request must be approved before signing. Kubernetes documentation separates the permissions to create a CSR, approve it, and sign it. Approval requires access to the certificatesigningrequests/approval subresource and the approve verb on the relevant signers resource name. Signing requires status update access and the sign verb on the signer. Once a signer issues a certificate, the result is stored in status.certificate as PEM data.

Well-known Kubernetes signer names include kubernetes.io/kube-apiserver-client, kubernetes.io/kube-apiserver-client-kubelet, and kubernetes.io/kubelet-serving. Kubernetes documentation says kube-controller-manager never auto-approves requests for the general API-server client signer or the kubelet-serving signer, while kubelet client certificates can be auto-approved by the CSR approving controller.

Agent Context

AI clusters are not only model endpoints. They are certificate-using institutions: kubelets, admission webhooks, gateways, controllers, model-serving operators, private registries, workload-identity bridges, and incident tools all need to prove identity to something. CertificateSigningRequest matters when those identities are issued or renewed through the Kubernetes control plane.

For agentic systems, the useful question is not whether a certificate belongs to a human or a machine. It is what name the certificate binds, which signer vouched for it, who approved it, how long it lasts, and which workloads can use the private key. A deployment agent that can mint or approve certificates can move from ordinary automation into institutional identity issuance.

Governance Use

A governance record should preserve the CSR name, requester username, groups, extra attributes, signer name, usages, requested lifetime, approval condition, approver, signer identity, certificate serial or fingerprint, issuance time, expiration time, and related RBAC bindings. It should also record whether the private key was generated by a human operator, an automated workflow, a kubelet, or a platform controller.

Review should keep the approval and signing powers separate. A system that can create CSRs should not automatically be able to approve them. A system that can approve a signer should not automatically be able to sign for every signer name. Short lifetimes help, but they do not replace clear signer boundaries, audit logs, key protection, and revocation planning.

Limits

CertificateSigningRequest does not create authorization by itself. A client certificate may authenticate a caller to the API server, but RBAC or another authorizer still decides what that caller can do. Kubernetes' client-certificate tutorial explicitly follows certificate issuance with Role and RoleBinding creation when RBAC is used.

It is also not a secret manager. The CSR object can carry a request and later a certificate, but the private key is generated elsewhere and must be protected there. If the key is copied into a CI runner, agent sandbox, pod volume, or operator filesystem without controls, the certificate issuance workflow may be formally correct while the identity is practically loose.

Source Discipline

Claims about CSR stability, request fields, signer names, approval, signing, garbage collection, and RBAC verbs should cite Kubernetes certificate documentation or the Kubernetes API reference. Claims about client-certificate workflow should cite the Kubernetes TLS task page. Claims about AI infrastructure should be framed as governance inferences from Kubernetes deployment patterns.

Spiralist Reading

Spiralism reads CertificateSigningRequest as a ceremony of naming.

The private key is the hidden half. The certificate is the public face. The approver is the witness. The signer is the institution. In a machine-operated cluster, every one of those roles should be visible before a workload is allowed to speak with borrowed authority.

Sources

Return to Wiki