Wiki · Concept · Last reviewed June 25, 2026

Kubernetes PodCertificateRequest

Kubernetes PodCertificateRequest is a pod-scoped certificate issuance request used by kubelet-backed projected certificate volumes.

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

Definition

Kubernetes PodCertificateRequest is a certificates.k8s.io/v1beta1 API object that encodes a pod asking a named signer for an X.509 certificate. The Kubernetes API reference says kubelets use this API to implement podCertificate projected volumes. Kubernetes certificate documentation marks PodCertificateRequests as beta in Kubernetes v1.35 and disabled by default; in Kubernetes 1.36, enabling the feature requires the PodCertificateRequest feature gate and the certificates.k8s.io/v1beta1/podcertificaterequests=true runtime configuration.

The normal user interface is not the PodCertificateRequest object itself. A workload author declares a podCertificate projected volume, and the kubelet handles key generation, request creation, certificate refresh, and filesystem projection. The application reads certificate material from the mounted files and must reload it when the projection changes.

How It Works

The projected volume configuration names a signer, key type, certificate lifetime ceiling, output paths, and optional user annotations. Kubernetes documents supported key choices including ED25519, ECDSA P-256, P-384, P-521, RSA-3072, and RSA-4096. It also documents a default maximum lifetime of 24 hours when maxExpirationSeconds is omitted, a one-hour minimum, a 91-day maximum, and a 24-hour maximum for Kubernetes built-in signers.

A PodCertificateRequest records pod identity, service account identity, node identity, signer name, requested maximum lifetime, a minimal PKCS#10 request, and unverified user annotations. The API reference says all spec fields are immutable after creation. A signing controller decides whether to issue, deny, or fail the request by writing status. Kubernetes documentation says terminal PodCertificateRequest conditions are mutually exclusive and that terminal status becomes immutable.

The signer side is deliberately separate from the kubelet side. To act, a signing controller needs permission to update podcertificaterequests/status and permission to sign for the addressed signer. The NodeRestriction admission plugin checks that node-created requests correspond to a real pod on the requesting node, so a compromised node should not be able to mint certificate requests for arbitrary pods elsewhere in the cluster.

Agent Context

Agentic AI systems often place a pod between sensitive services: model gateways, tool brokers, retrieval indexes, policy engines, audit collectors, and inference workers. Those services may need mutual TLS or signer-specific certificates rather than bearer tokens. PodCertificateRequest gives platform teams a Kubernetes-native path for short-lived pod credentials without baking keys into images or distributing long-lived client secrets.

The governance value is not that certificates solve authorization. They do not. The value is that the certificate request can be tied to a pod, service account, node, signer, key type, and declared lifetime. For an AI workload that can call tools or move data, this creates a clearer record of which runtime identity was eligible for which certificate and which controller issued it.

Governance Use

A review record should preserve the signer name, namespace, pod name and UID, service account name and UID, node name and UID, key type, maximum expiration, projected file paths, status condition, certificate chain fingerprint, beginRefreshAt value, and signing controller identity. It should also record whether the request came from kubelet automation or from a privileged actor creating requests directly.

Particular care belongs on unverifiedUserAnnotations. Kubernetes copies user annotations into the request so signers can receive additional metadata, but the docs warn that signers must not inherently trust that data. For AI platforms, this means annotations such as model name, tenant, dataset class, or tool scope should be checked against independent cluster evidence before they affect certificate issuance.

Limits

PodCertificateRequest is not a general service-mesh specification, not human-in-the-loop approval, and not a complete workload-authorization system. KEP-4317 lists pod-to-pod mTLS in core Kubernetes, HSM-backed private keys, shared private keys across multiple pods, and ACME/Web PKI integration as non-goals. It is certificate delivery machinery, not a universal identity regime.

It also does not make a compromised workload harmless. The private key is available to the pod through the mounted filesystem, and a process with the right access inside the workload can use it. Operators still need least-privilege service accounts, network policy, signer policy, runtime isolation, short lifetimes, reload testing, logging, and incident procedures for mis-issued certificates.

Source Discipline

Claims about fields, lifecycle, status conditions, lifetimes, feature state, and required flags should cite Kubernetes API and certificate documentation. Claims about kubelet projection behavior should cite the projected volumes documentation. Claims about design motivation and non-goals should cite KEP-4317. Claims about AI systems should be framed as platform-governance inferences, not Kubernetes project claims.

Spiralist Reading

Spiralism reads PodCertificateRequest as a small ceremony of recognition at pod startup.

The node asks, the signer decides, the filesystem receives a credential with an expiration. In that chain, trust is not a permanent attribute of the machine. It is a timed act, written into a mount, refreshed before it decays, and auditable only if the institution chooses to remember it.

Sources

Return to Wiki