SPIFFE (Secure Production Identity Framework For Everyone)

SPIFFE is an open specification defining a cryptographically verifiable identity document (SVID) and API for issuing that identity to software workloads, independent of network location or credentials the workload itself must manage. It matters because it decouples service identity from IP addresses, shared secrets, or platform-specific tokens, forming the identity substrate for zero-trust authentication across heterogeneous clusters and clouds.

Practical example

A company runs microservices split across an EKS cluster in AWS and a GKE cluster in GCP. Each cluster runs its own SPIRE Server as a distinct trust domain. Trust bundles are exchanged via SPIFFE Federation, allowing an Envoy sidecar in GCP to validate the X.509-SVID presented by a service in AWS during mTLS handshake, without provisioning a shared enterprise root CA or VPN peering for certificate distribution.

SPIFFE defines two artifacts: the SPIFFE ID, a URI of the form spiffe://trust-domain/path, and the SVID (SPIFFE Verifiable Identity Document), which binds that ID to a cryptographic proof. SVIDs come in two encodings: X.509-SVID, a short-lived certificate usable directly for mTLS handshakes, and JWT-SVID, used where TLS termination happens upstream (API gateways, serverless invocations). Critically, SPIFFE specifies only the identity document and delivery mechanism, not the transport security protocol — mTLS consumes SVIDs, it does not define them.

SPIRE is the reference implementation, split into a central Server and a per-node Agent. Workloads never handle long-lived secrets or bootstrap credentials directly; instead they call the local Workload API over a Unix domain socket, and the Agent performs workload attestation — inspecting process metadata (PID, container cgroup, Kubernetes pod labels/service account, Unix UID) against configured selectors — before minting and streaming back a short-TTL SVID. The Agent itself must first pass node attestation against the Server (cloud instance identity documents, TPM quotes, join tokens) to obtain its own SVID before it can attest workloads. This two-tier attestation chain is what allows SPIRE to issue identity without any workload ever touching a private key on disk.

Trust Domain Federation: Separate SPIRE deployments (e.g., per cloud region or per cluster) exchange signed trust bundles (root CA material) out-of-band or via the federation API, allowing a workload in trust domain A to cryptographically validate an SVID issued in trust domain B without a shared root CA — critical for multi-cluster mesh and cross-org B2B authentication.
Rotation and blast radius: X.509-SVID TTLs are typically minutes, not months; the Workload API streams renewed SVIDs before expiry, so compromise of a leaked certificate has a narrow exploitation window compared to static service-account keys.
Selector misconfiguration: If workload attestation selectors are too coarse (e.g., matching on node identity rather than pod-specific labels/service account), multiple workloads on the same host can receive overlapping or incorrect identities — a subtle privilege escalation vector distinct from a protocol flaw.

The architectural consequence is that identity becomes a first-class, platform-agnostic control plane concern rather than an artifact glued together from Kubernetes ServiceAccount tokens, cloud IAM roles, and manually rotated mTLS certs. Service meshes (Istio, Consul, Linkerd) increasingly delegate their own CA and identity plumbing to SPIFFE/SPIRE specifically to get multi-cluster and multi-runtime (VM, container, serverless) federation for free, rather than reimplementing attestation logic per platform.