SPIFFE

A gRPC-based API that runs locally on each node and provides workloads with their identity documents. It eliminates the need for applications to know how to obtain or manage keys.

• Key Retrieval: Workloads call the API to fetch their X.509 certificates and private keys.
• Trust Bundle Retrieval: The API provides the set of trusted root certificates needed to validate other workloads.
• Rotation: The API handles automatic certificate rotation without application restarts.
• Attestation: The node agent verifies the workload's identity before issuing credentials, typically via kernel-level process inspection.

A node-local daemon that implements the SPIFFE Workload API and acts as the bridge between workloads and the central control plane.

• Attestation: Verifies the identity of the node and the workloads running on it using a plugin-based architecture.
• Key Management: Generates private keys and manages their lifecycle entirely in memory; keys are never written to disk.
• SVID Rotation: Proactively fetches new SVIDs before the current ones expire, ensuring uninterrupted service.
• Deployment: Runs as a DaemonSet in Kubernetes or a systemd service on bare-metal nodes.

The central control plane responsible for managing the trust domain, issuing SVIDs, and maintaining the registry of attested workloads.

• Node Attestation: Validates the identity of physical or virtual nodes joining the trust domain using platform-specific attestors (e.g., AWS Instance Identity Document, GCP Token).
• Workload Registration: Maintains a database mapping selectors (e.g., k8s:container-image:my-app) to SPIFFE IDs.
• CA Functionality: Acts as the root certificate authority for the trust domain, signing all X.509-SVIDs.
• Federation: Can be configured to trust other SPIRE servers in different trust domains, enabling cross-organization mTLS.

A Uniform Resource Identifier (URI) that uniquely and unambiguously identifies a workload within a trust domain. The canonical format is spiffe://trust-domain/path.

• Trust Domain: The authority responsible for issuing the identity (e.g., spiffe://example.com)
• Workload Path: A hierarchical identifier for the specific service (e.g., /database/postgres)
• Unlike IP addresses or hostnames, the SPIFFE ID is portable and remains valid even if the workload migrates across infrastructure
• Enables fine-grained policy by allowing authorization rules to be written against logical service names rather than ephemeral network attributes

A cryptographically signed document that a workload presents to prove its SPIFFE ID to other systems. The SVID is the physical manifestation of workload identity.

• X.509 SVIDs: Standard certificates where the SPIFFE ID is encoded in the Subject Alternative Name (SAN) field, enabling direct mTLS authentication
• JWT SVIDs: JSON Web Tokens containing the SPIFFE ID as a claim, suitable for passing identity through API gateways and application layers
• SVIDs are short-lived and automatically rotated, typically with a lifetime of minutes rather than months
• The private key associated with an SVID never leaves the workload's host, eliminating the risk of credential theft in transit

A node-local daemon that runs on every machine participating in a SPIFFE trust domain. It acts as the intermediary between workloads and the central SPIRE Server.

• Workload Attestation: Verifies the identity of a local process by interrogating the kernel (e.g., process ID, Unix user) or orchestrator metadata (e.g., Kubernetes service account)
• Key Management: Generates private keys locally and never transmits them over the network; only the public key is sent to the SPIRE Server for certificate signing
• SVID Rotation: Continuously fetches fresh SVIDs before the current ones expire, ensuring uninterrupted mTLS connections
• The agent exposes a local Workload API via a Unix domain socket, which workloads call to retrieve their identity documents

The centralized trust root and signing authority for a SPIFFE trust domain. It validates agent identities and issues SVIDs.

• Node Attestation: Verifies that a SPIRE Agent is running on a legitimate, authorized node using platform-specific selectors (e.g., AWS Instance Identity Document, GCP token, TPM endorsement key)
• Upstream Authority Plugin: Integrates with existing PKI infrastructure (e.g., Vault, AWS Private CA, custom CA) to chain the SPIFFE trust domain to an enterprise root of trust
• Federation: Enables trust between different SPIFFE trust domains by exchanging and signing bundle endpoints, allowing workloads in spiffe://org-a.com to authenticate to spiffe://org-b.com
• Maintains the trust bundle, a collection of CA certificates that workloads use to validate SVIDs from peers

The local gRPC endpoint exposed by the SPIRE Agent that workloads interact with to obtain and manage their identity. It is the sole interface for identity retrieval.

• No network exposure: Bound to a Unix domain socket, accessible only to processes on the same host with appropriate file permissions
• SVID retrieval: Workloads call FetchX509SVID() or FetchJWTSVID() to get their current identity documents
• Bundle access: Provides the trust bundle so workloads can validate SVIDs presented by peers during mTLS handshakes
• Push-based updates: The agent streams new SVIDs to subscribed workloads before expiration, eliminating polling overhead
• Designed for sidecar and daemonset deployment patterns in Kubernetes, where the socket is shared via a hostPath volume

A collection of root CA certificates that a workload uses to validate the SVIDs presented by other workloads. It establishes the chain of trust within and across domains.

• Intra-domain validation: Contains the CA certificate for the local trust domain, allowing workloads to verify that a peer's SVID was issued by the same SPIRE Server
• Federated bundles: Includes CA certificates from external trust domains that have been federated, enabling cross-organization mTLS
• Bundle propagation: SPIRE Agents push the bundle to workloads through the Workload API; SPIRE Servers synchronize federated bundles via bundle endpoint APIs
• Rotation: CA certificates in the bundle are periodically rotated; SPIRE handles the graceful transition to ensure no disruption to active connections