Kubernetes 1.37 adds built‑in support for X.509 pod certificates and a mechanism to distribute cluster‑wide trust bundles. This replaces the exclusive reliance on service‑account JWTs for workload identity and gives operators a proof‑of‑possession credential option that integrates directly with the control plane.
What Changed in v1.37
The release promotes the Pod Certificates feature to General Availability. Kubelet now creates PodCertificateRequest objects on behalf of pods that declare a certificate request in their spec, and a new signer controller processes those requests, issuing X.509 certificates. In parallel, the cluster can publish ClusterTrustBundle resources that contain the CA certificates needed to validate the issued pod certificates.
Why X.509 Credentials Matter for Practitioners
Service‑account JWTs are bearer tokens: possession equals authentication. While Kubernetes mitigates misuse with node‑restriction admission and audience binding, the model still exposes the token to any component that receives it. X.509 certificates, by contrast, require a private key to prove ownership, enabling true proof‑of‑possession. This aligns with common TLS/mTLS patterns and reduces the risk of token replay or leakage.
Pod Certificates Architecture
The flow involves four primary pieces:
- Application: Declares a certificate request in the pod spec and reads the resulting key, certificate, and trust bundle from the container’s filesystem for (m)TLS.
- Kubelet: Generates a
PodCertificateRequestobject, watches for matchingClusterTrustBundleobjects, and mounts the artifacts into the pod. - Signer controller: Listens for
PodCertificateRequestobjects, signs the CSR using a configured CA, and updates the request status with the signed certificate. - ClusterTrustBundle: Holds the CA chain that workloads use to validate peer certificates; published by the signer controller.
The design mirrors the existing service‑account token pipeline but adds a pluggable interface, allowing multiple certificate providers to coexist. The article anticipates at least two built‑in providers: one for service DNS names (server TLS) and another for SPIFFE‑compatible client certificates, which would replace the current role of service‑account JWTs.
Operational and Security Implications
Adopting pod certificates introduces new operational artifacts: private keys stored inside the pod, certificate rotation schedules, and trust bundle updates. Because the private key is generated by the workload (or Kubelet) and never leaves the pod, operators must ensure that key material is protected by the container runtime and any host‑level security controls. Certificate lifetimes will be governed by the signer controller configuration, so monitoring expiration and renewal becomes part of the standard observability stack.
From a security standpoint, moving to proof‑of‑possession reduces the attack surface associated with token theft. However, it also requires careful handling of the CA that signs pod certificates; compromise of that CA would affect all workloads using the feature. Auditing of PodCertificateRequest creation and signer controller activity should be incorporated into existing audit pipelines.
Related CloudNinjas coverage: Kubernetes.
What This Means For Practitioners
Teams should evaluate whether their workloads already depend on mutual TLS or could benefit from stronger identity guarantees. If so, enable the pod certificate feature in v1.37, update pod specs to request certificates, and deploy the signer controller. Incorporate trust‑bundle mounting into your container images and adjust secret‑management processes to accommodate the new key material. Finally, extend monitoring and audit policies to cover certificate issuance and rotation events.