Kubernetes 1.37 Pod Certificates and SPIFFE: Similar ideas, different layers

Kubernetes 1.37 introduced two features that immediately caught my attention: Pod Certificates and ClusterTrustBundles. ( https://kubernetes.io/blog/2026/08/28/kubernetes-v1-37-pod-certificates-and-cluster-trust-bundles/ )

If you are familiar with SPIFFE and SPIRE, some of this will sound surprisingly familiar. Short-lived certificates for workloads, automatic certificate rotation, istribution of trusted CA certificates…

First thing that came to my mind was whether Kubernetes is starting to build its own version of SPIFFE. There is definitely overlap, but the two systems are solving different layers of the workload identity problem.

The simplest way I have found to think about it is:

Kubernetes 1.37 provides native infrastructure for issuing certificates to pods and distributing trust. SPIFFE defines a portable workload identity system, while SPIRE is an implementation of that system.

That distinction becomes clearer once we look at what each system actually does.

What Kubernetes 1.37 Introduces

Kubernetes has had certificate APIs for a long time, but Pod Certificates provide a much cleaner mechanism specifically designed for workloads.

• Natively Integrated X.509 Issuance: The system builds X.509 certificate issuance for TLS and mutual TLS (mTLS) directly into core Kubernetes.
• Proof-of-Possession Credentials: Rather than relying strictly on service account JWTs, Pod Certificates utilize asymmetric cryptographic signatures (such as RSA or ECDSA).
• Pluggable and Flexible Signer Interface: While service account JWTs only offer a single standardized format, Pod Certificates provide common Kubelet-managed machinery paired with a pluggable interface.
• Automated Key Generation and Delivery: Once a pod is scheduled, Kubelet automatically generates private keys on behalf of the workload and submits a PodCertificateRequest to the assigned signer.
• Built-in Certificate and Trust Rotation: Dynamic rotation is natively handled. Kubelet periodically re-requests certificates before they expire and rewrites them to the pod’s filesystem, requiring workloads to monitor changes using polling or inotify.
• Credential Bundles to Prevent Race Conditions: Kubelet can write the private key and certificate chain into a single file (a credential bundle). This prevents potential race conditions that applications might encounter when reading separate private key and certificate files in the middle of a rotation cycle.
• Unified Trust Distribution: Through Cluster Trust Bundles, Kubelet queries matching cluster trust anchors, dynamically consolidates and stably reorders them, and writes them to the container filesystem.
• Enhanced Node-Level Security: Rather than relying on individual signers or application code, security checks like node isolation are built directly into the kube-apiserver via the node restriction admission plugin, ensuring a compromised node cannot request certificates for pods scheduled elsewhere.

Pretty much, a pod can request a certificate from a configured certificate signer. The kubelet generates the private key, submits a PodCertificateRequest, receives the signed certificate, and makes the certificate and private key available to the pod through a projected volume.

What SPIFFE and SPIRE Provide

SPIFFE—the Secure Production Identity Framework for Everyone—approaches the problem from a slightly different direction. SPIFFE starts by defining what a workload identity looks like.

That identity is represented by a SPIFFE ID:

spiffe://example.org/payments/backend

SPIFFE then defines credentials called SVIDs—SPIFFE Verifiable Identity Documents—that allow a workload to prove that identity.

One common form is an X.509 certificate called an X509-SVID. JWT-SVID is also supported.

SPIRE is an implementation of the SPIFFE specifications. It performs functions such as workload and node attestation, issuing SVIDs, rotating credentials, and distributing trust bundles.

A simplified SPIRE architecture looks like this:

                 SPIRE Server
                      │
                Identity Policy
                      │
                 Trust Bundle
                      │
                      ▼
                 SPIRE Agent
                      │
              Workload Attestation
                      │
                      ▼
                Workload API
                      │
             ┌────────┴────────┐
             │                 │
         X509-SVID        Trust Bundle
             │                 │
             └────────┬────────┘
                      ▼
                   Workload

Looking at these two architectures side by side, the overlap becomes obvious.

Where Kubernetes and SPIFFE Overlap

Both systems recognize the same fundamental problem: workloads need a secure way to establish their identity without relying on long-lived secrets. Both can provide short-lived X.509 certificates, support automatic credential rotation, provide mechanisms for distributing the CA certificates workloads need to establish trust, and both can ultimately support mutual TLS between workloads.

At a high level, they can look remarkably similar:

This is the area where Kubernetes has moved much closer to functionality traditionally associated with workload identity systems, but the similarities start to disappear once we move beyond certificate lifecycle management.

Where They Don’t Overlap

The biggest difference is that SPIFFE defines identity semantics. Kubernetes does not.

Kubernetes provides a mechanism for requesting a certificate, but it deliberately leaves much of the meaning of that certificate to the signer.

A signer could issue:

CN=payments-backend

or:

DNS:backend.payments.svc.cluster.local

or:

URI:spiffe://example.org/payments/backend

All three are possible approaches.

SPIFFE, on the other hand, explicitly defines the workload identity:

URI:spiffe://example.org/payments/backend

That identity can remain meaningful regardless of how or where the workload happens to run.

Kubernetes Pod Certificates are Kubernetes-specific.

SPIFFE is not.

SPIFFE identities can represent workloads running on:

Kubernetes
Virtual machines
Bare metal
Cloud platforms
Edge systems

That makes SPIFFE useful as an identity layer across heterogeneous infrastructure. Kubernetes Pod Certificates naturally stop at the Kubernetes boundary.

Attestation

SPIRE also has an explicit concept of attestation.

Before issuing an identity, SPIRE determines which node or workload it is dealing with and maps characteristics of that workload to identity policy.

For example, a workload might be identified using selectors associated with its Kubernetes namespace, ServiceAccount, pod metadata, operating-system attributes, or other runtime information.

That process answers a deeper question than simply:

Can this pod obtain a certificate?

It attempts to answer:

Which workload is this, and which SPIFFE identity should it receive?

Kubernetes provides strong information about pods and ServiceAccounts that a certificate signer can use to make similar policy decisions, but Kubernetes Pod Certificates themselves don’t define a general-purpose workload attestation framework comparable to SPIFFE/SPIRE.

Federation

SPIFFE also defines a model for establishing trust between different trust domains.

For example:

spiffe://production.example.com

            ↕

spiffe://partner.example.net

Those environments can exchange trust bundles and establish policies for authenticating identities belonging to another trust domain.

Kubernetes ClusterTrustBundles provide the mechanism needed to distribute CA certificates, which is an important building block, but Kubernetes doesn’t define the broader identity or federation semantics around those trust relationships.

Final thoughts

Although the overlap exists, SPIFFE is solving a broader problem.

Kubernetes Pod Certificates answer: How does this pod securely obtain and rotate a certificate?

SPIFFE answers: What is the identity of this workload, and how can that identity be understood consistently across infrastructure?

According to the original article :

In the fullness of time, I expect Kubernetes to offer at least two built-in certificate providers:

    * One that issues server TLS certificates for the DNS names used by Kubernetes services.
    * One that offers SPIFFE client certificates, filling the same role that service account JWTs fill today