↓ Skip to main content
Le Site de François
  1. Index/

SPIFFE / SPIRE

Security Identity Workload Mtls Attestation Cncf Zero-Trust
Table of Contents

SPIFFE (Secure Production Identity Framework for Everyone) is a CNCF graduated specification that defines a standard for workload identity: a universal answer to the question “how does a service prove who it is to another service, without a human provisioning a secret?” The core primitives are simple. A SPIFFE ID is a URI of the form spiffe://trust-domain/path that unambiguously names a workload within a trust domain — for example spiffe://prod.example.com/payments/api. A SVID (SPIFFE Verifiable Identity Document) is a cryptographically signed document asserting that SPIFFE ID, in one of two forms: an X.509-SVID, which is a standard X.509 certificate with the SPIFFE ID encoded in the Subject Alternative Name field (used for mTLS), or a JWT-SVID, which is a short-lived JWT bearing the SPIFFE ID as the sub claim (used for service-to-service authentication where TLS termination is handled elsewhere). A trust bundle is the set of CA certificates for a trust domain that relying parties use to validate SVIDs — analogous to a root CA store, but scoped to a SPIFFE trust domain. The Workload API is the local gRPC API through which a workload retrieves its SVID and the trust bundles of domains it needs to communicate with, with automatic rotation before expiry.

SPIRE (SPIFFE Runtime Environment) is the CNCF reference implementation of the SPIFFE specification and the component operators actually deploy. A SPIRE deployment has two tiers. The SPIRE Server is the trust anchor for its domain: it maintains a registry of registration entries — policy rules mapping platform attestation attributes (a Kubernetes pod’s service account and namespace, an EC2 instance’s AMI ID, a process’s Unix UID) to SPIFFE IDs — and operates as, or delegates to, a Certificate Authority that signs X.509-SVIDs. In production, the Server runs in HA configuration behind a load balancer with its CA private key protected by an HSM or cloud KMS. The SPIRE Agent runs as a DaemonSet on every Kubernetes node or as a daemon on every VM and bare-metal host. On startup, the Agent attests itself to the Server using node-level platform evidence that cannot be spoofed: an AWS EC2 Instance Identity Document signed by the IMDS, a GCP instance identity token, a Kubernetes projected service account token, or a TPM quote — the Server verifies this evidence before issuing the Agent its own SVID and trusting it to vouch for workloads on that node. At runtime, when a workload calls the Workload API, the Agent identifies it by inspecting kernel-level metadata (Unix socket peer credentials, cgroup membership, Kubernetes pod metadata) without the workload presenting any pre-provisioned secret — the attestation is entirely based on observed platform state. The Agent then checks whether any registration entry matches, and if so, calls the Server to obtain or renew a short-lived SVID for that workload, typically with a TTL of one hour or less.

SPIFFE/SPIRE is the zero-standing-credentials answer to the same class of problem that Vault and ESO address through secrets management. Where Vault issues database credentials and API tokens, SPIRE issues the cryptographic identity that other services use to authenticate the caller in the first place — the identity layer beneath the secrets layer. The practical payoff is mTLS with zero static secrets: every service in a cluster gets a SVID automatically, rotated continuously, and can present it to any other SPIRE-identified service without any human provisioning of certificates or passwords. Integration with cloud IAM is via SPIRE’s OIDC Federation capability: SPIRE exposes a standard OIDC discovery endpoint, allowing cloud providers (AWS STS, GCP Workload Identity Federation, Azure AD) to trust JWT-SVIDs as federated identity tokens and exchange them for short-lived cloud credentials — so a workload that needs to read from S3 presents its JWT-SVID to STS and receives a temporary IAM credential, with no access key ever stored anywhere. Cross-organisational identity is handled through SPIFFE Federation: two SPIRE Servers exchange trust bundles via a mutually authenticated federation endpoint, after which workloads in either domain can validate SVIDs from the other and establish mTLS across the trust boundary. In confidential computing environments, SPIRE’s TPM-based node attestation plugin integrates directly with the measured boot stack: the SPIRE Agent can present a TPM quote over PCR values as its node attestation evidence, meaning the SPIRE Server will only issue SVIDs to agents running on nodes that booted a verified, policy-compliant software stack.

Additional Information
#

Related

mTLS (Mutual TLS)

Security Cryptography Networking Tls Identity Zero-Trust Mtls
mTLS (Mutual TLS) is the configuration of TLS in which certificate-based authentication is required from both sides of the connection, not just the server. In standard TLS, only the server presents an X.509 certificate, which the client verifies to confirm it is talking to the intended host; the client is typically anonymous to the server, or authenticates separately via a password or session token at the application layer. In mTLS, the client also presents a certificate during the TLS handshake; the server verifies it against a trusted CA before completing the connection. The result is cryptographic proof of identity in both directions: the client knows it is talking to the legitimate server (as in standard TLS), and the server knows the exact identity of the connecting client — without any password, API key, or token exchanged in the application layer.

Confidential Containers (CoCo)

Security Confidential-Computing Kubernetes Attestation Containers Cncf
Confidential Containers (CoCo) is a CNCF sandbox project that lifts hardware confidential computing — TDX, SEV-SNP, Intel SGX, IBM Secure Execution — up to the Kubernetes pod level, providing a unified software layer that abstracts away the underlying TEE technology. Its defining trust model is unusually strict: the Kubernetes control plane, the kubelet, the container runtime, and the cloud operator are all treated as explicitly untrusted. Only the hardware itself and the workload owner’s own supply chain are in scope for trust.

Keylime

Security Attestation Tpm Ima Linux Cncf
Keylime is a CNCF project, originating at MIT Lincoln Laboratory, that turns the raw cryptographic primitives of the TPM into an operable remote attestation system for fleets of Linux machines. Its mission is narrow but important: given that a TPM can produce a signed quote over PCR values, and that IMA can accumulate a runtime measurement log into PCR 10, Keylime provides the infrastructure to continuously collect those quotes from many machines, verify them against policy, react to failures, and gate secret delivery on attestation success — without requiring operators to understand TPM protocols directly.