SPIRE

A CNCF-graduated standard that defines how services identify themselves to each other. SPIFFE provides a universal identity control plane, issuing SPIFFE Verifiable Identity Documents (SVIDs) — short-lived X.509 or JWT certificates bound to a workload's cryptographic properties. Unlike traditional PKI, SPIFFE identities are not tied to IP addresses or network location, making them ideal for dynamic, ephemeral environments like Kubernetes pods and confidential containers. The identity format spiffe://trust-domain/workload encodes both the organizational trust boundary and the specific service, enabling fine-grained, zero-trust authorization policies.

The process by which SPIRE verifies the identity and integrity of a physical or virtual node before issuing it any workload identities. SPIRE agents perform node attestation using pluggable attestors:

• AWS EC2 Instance Identity Document verification
• Azure Managed Service Identity token validation
• TPM 2.0 quote-based attestation
• Hardware root of trust challenges

A node that fails attestation is denied entry to the trust domain, preventing compromised or unauthorized machines from participating in the SPIFFE identity fabric. This is the foundational security gate in a zero-trust infrastructure.

The mechanism by which SPIRE cryptographically verifies that a running process is what it claims to be before issuing an SVID. SPIRE interrogates the local operating system or container runtime to gather evidence:

• Unix Domain Socket peer credential checks
• Kubernetes Service Account token validation
• Docker container label inspection
• TEE evidence (e.g., Intel SGX enclave measurements)

This ensures that only a specific binary, running in a specific container, on a verified node, can obtain the identity spiffe://acme.com/payment-processor. Impersonation is cryptographically prevented.

A per-node daemon that acts as the local identity broker. The agent:

• Performs node attestation to join the trust domain
• Interrogates the local workload API (kubelet, Docker socket) to discover running processes
• Performs workload attestation to verify each process's identity
• Fetches and caches SVIDs from the SPIRE Server
• Exposes the Workload API (a local Unix socket) so applications can retrieve their identity

The agent is designed to be lightweight and crash-resilient, ensuring that even if the SPIRE Server is temporarily unreachable, cached SVIDs remain available to local workloads.

The central control plane of the SPIFFE identity fabric. The server:

• Maintains the trust domain registry of all known nodes and workloads
• Validates node and workload attestation evidence
• Signs and issues SVIDs (X.509 certificates and JWT tokens)
• Maintains the CA hierarchy and performs key rotation
• Exposes a gRPC API for agents and external registrars

In production, the SPIRE Server is typically deployed as a highly available cluster backed by an etcd or SQL datastore. The server's signing key is the root of trust for the entire domain and must be protected with hardware security modules (HSMs) or TEEs.

SPIRE can be extended to consume hardware attestation evidence from Trusted Execution Environments, binding SPIFFE identities to cryptographic measurements of enclaves. This integration enables:

• Intel SGX: Attestation reports quoting MRENCLAVE and MRSIGNER values
• AMD SEV-SNP: Attestation reports verifying the launch digest of a confidential VM
• NVIDIA Confidential Computing: GPU attestation reports confirming the GPU firmware and driver state

A workload running inside a TEE presents its hardware-signed attestation report to the SPIRE Agent. Only if the measurement matches a known-good value does the agent issue the corresponding SVID. This creates a hardware-rooted identity chain from silicon to service.