Every service that calls another service has to prove who it is. Inside Kubernetes, the default proof has been a service account token, a signed JWT that the kubelet mounts into the Pod and keeps fresh2. It works well, which is why it underpins workload identity federation with the major cloud providers1. It also has one structural weakness, and Kubernetes 1.37 shipped a GA foundation for addressing it.
The problem with bearer tokens
Service account JWTs are bearer tokens: whoever has the token is the identity it names. To authenticate to a peer you must hand it a copy, which means the peer could replay it. Kubernetes reduces the risk by binding tokens to time, audience and objects, but the Kubernetes blog is candid that none of these are complete defences1.
The alternative is a proof-of-possession credential, where you prove you hold a secret without sending it. The most widely deployed form is the X.509 certificate used in TLS: the private key stays in the workload, and only a signature and the certificate cross the wire1.
How Pod Certificates work
A Pod requests certificates through projected volume sources in its spec13. When the Pod is scheduled, the kubelet generates a private key, creates a PodCertificateRequest addressed to a named signer, and waits for the signer controller to issue a certificate chain. The kubelet writes the key and certificate into the container, alongside trust anchors collected from matching Cluster Trust Bundles, and refreshes everything before it expires1.
Two details matter in practice. Rotation is automatic and frequent: signers eventually shipped in core are expected to issue certificates with a maximum lifetime of 24 hours, and other signers are capped at 91 days, so applications must reload credentials when files change. And security checks sit in the API server, where node restriction stops a compromised node requesting certificates for Pods not scheduled to it1.
Side by side
| Service account tokens | Pod Certificates | |
|---|---|---|
| Credential type | Bearer JWT | X.509 certificate with a private key kept in the Pod |
| Replay if intercepted | Possible within the token's bindings | Not without the private key |
| Best for | Calling cloud APIs and services that accept federated JWTs | Service-to-service mTLS inside and across clusters |
| Ecosystem support | Very broad today | Growing; signers are pluggable |
| Signer | Built into the control plane | Third-party or custom at 1.37; built-in signers expected later |
| Application effort | Read a file, send a header | Configure TLS and handle frequent rotation |
The blog expects at least two built-in signers over time: one for server TLS certificates matching Service DNS names, and one for SPIFFE client certificates that fill the role service account tokens play today1. SPIFFE defines a standard identity format and verifiable identity documents for workloads, which makes these identities portable across platforms4.
Use tokens to talk to clouds and APIs that expect them. Use certificates for service-to-service trust you control. Most platforms will run both for years.
How I'd roll it out
- Map current identity flows: which services call which, with what credential, and where tokens are forwarded rather than validated.
- Pick a signer strategy. Until built-in signers arrive, choose a maintained signer or your existing PKI, and decide who owns the root of trust.
- Start with internal mTLS between a few high-value services, using credential bundles so rotation is a single file reload.
- Test rotation deliberately. With lifetimes as short as a day, an application that only reads its certificate at start-up will fail.
- Enforce with policy: require certificate sources for services that handle sensitive data, using admission policies and the isolation model in Kubernetes multi-tenancy.
- Keep tokens where they fit, especially for cloud federation, and stop forwarding them between services, the same anti-pattern described in securing MCP servers.
How I can help
I design Kubernetes platforms with identity, policy and isolation built in, so security reviews become a walkthrough rather than a negotiation. As a fractional CTO I can own that roadmap. Or analyse your challenge and bring the result to a call.
- 1Kubernetes v1.37: Pod Certificates and Cluster Trust BundlesKubernetes blog · 28 Aug 2026
- 2Service accountsKubernetes documentation
- 3Projected volumesKubernetes documentation
- 4SPIFFE conceptsSPIFFE project