Hey {{first name | there}}. At this point, I am on a Kubernetes kick, but I promise it will end soon. Last weekend I came back to the 1.37 release, and Pod Certificates seemed like something you might be interested in.
Kubernetes already gives Pods service account tokens, so I wanted to understand what certificates add and which part of the process Kubernetes now handles.
In today's technical notes:
Bearer tokens compared with proof-of-possession credentials
How Pod Certificates work
What graduating to GA does and does not mean
🧠TOGETHER WITH EVERYTHINGDEVOPS
The layoffs are real, and AI is getting more capable, but the labour market data doesn't quite match the headlines.
This video looks at what AI can actually do today, why companies aren't replacing entire workforces overnight, and what happens when AI starts taking the entry-level work people traditionally learned from.
Subscribe: @EverythingDevOpsHQ for deeper dives on agents, Kubernetes, MLOps, and AI infrastructure.
📰Technical notes: Wait, the Pods have certificates?
Pod Certificates first appeared as an alpha feature in Kubernetes 1.34. In 1.37, both Pod Certificates and Cluster Trust Bundles graduated to GA.
Together, they give Kubernetes a standard way to request an X.509 certificate for a Pod, write it into the container filesystem, rotate it, and provide the trust roots needed to verify other certificates.
This is done using two API objects:
PodCertificateRequest, which represents a request from a specific Pod to a specific signer.
ClusterTrustBundle, which contains the certificates a workload can use as trust anchors.
The Pod requests a certificate through a projected volume, and kubelet handles the API request.
Bearer tokens and certificates solve identity differently
Service account tokens are JWT bearer tokens.
If someone obtains a valid copy, they can present the same token and act as the identity inside it until the token expires or another restriction blocks its use.
Kubernetes already reduces this risk with short expiry times, audience binding, and tokens tied to a particular Pod. These are useful protections, but the credential still has to be sent to the system verifying it.
Certificates, however. Work differently.
The workload has a private key and a certificate containing the matching public key. During TLS, the workload proves that it holds the private key without sending that key to its peer.
Anyone who sees the certificate can read it. They still cannot use the identity without the private key.
The request includes the Pod, ServiceAccount, and node identity. With the NodeRestriction admission plugin enabled, a node can only request certificates for real Pods currently running on that node.
Unlike the older CertificateSigningRequest API, Pod Certificate requests do not have a separate approval phase. The signer decides whether to issue, deny, or fail the request.
Kubernetes now provides the interface
Kubernetes does not currently ship a production Pod Certificate signer
The API and kubelet machinery are now stable, but you still need a signer controller that understands your identity model and issues the certificate.
That signer decides what goes into the certificate. One signer might issue a server certificate containing the DNS names of the Services selecting the Pod. Another might issue a SPIFFE identity based on the namespace and ServiceAccount.
For testing, Taahir Ahmed created Tinycert. It provides example service-DNS and SPIFFE signers and includes a kind configuration for trying the feature locally.
Tinycert is an educational implementation, not a production certificate authority.
Distributing the trust roots
Issuing a certificate is only one part of TLS. The workload also needs to know which certificate authorities it trusts.
A ClusterTrustBundle stores those trust anchors as a Kubernetes object.
The projected volume can select a bundle by name or select all bundles associated with a signer. Kubelet collects the matching certificates, removes duplicates, normalizes them, and keeps the projected file updated when the bundle changes.
This gives signer operators a Kubernetes-native way to distribute CA certificates without copying the same ConfigMap or Secret into every namespace.
It does not decide which peer identities the application should accept. The application still needs to verify the hostname, SPIFFE ID, or other identity encoded in the certificate.
What you should look out for
If you already use cert-manager, SPIRE, or a service mesh for workload identity, Pod Certificates do not immediately replace them.
Those projects do more than place a certificate on disk. They operate certificate authorities, define identities, enforce trust policies, and integrate certificates into application traffic.
Pod Certificates provide a standard Kubernetes interface that those systems can build on.
If you maintain an application that reads certificates from files, it is also worth checking whether it can reload them without restarting. Kubernetes can rotate the credential, but it cannot make the process reopen the file.
🌍IN THE ECOSYSTEM
Kubernetes v1.37: Pod Certificates and Cluster Trust Bundles — the official introduction to the architecture, rotation flow, and the signer interface.
KEP-4317: Pod Certificates — the design behind PodCertificateRequest and the kubelet-managed projected volume.
Tinycert — an educational implementation with service-DNS and SPIFFE signers for testing the feature on kind.
⏱️UNTIL NEXT TIME
That’s it for this issue. If you already run workload mTLS, reply and tell me how certificates currently reach your Pods and whether this API would simplify any part of it.
Know an engineer working on Kubernetes identity? Share this link with them
Jubril Oyetunji
CTO, EverythingDevOps