SPIFFE

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

• Trust Domain: The administrative root (e.g., spiffe://example.com), typically tied to an organization or environment.
• Workload Identifier: A path that uniquely identifies a specific service or node (e.g., /database/web-frontend).
• Unlike IP addresses or hostnames, the SPIFFE ID is a logical identity that remains constant regardless of where the workload runs.

A cryptographically verifiable document that a workload presents to prove its identity. The SPIRE Agent attests the workload's properties and issues a short-lived SVID.

• X.509-SVID: A standard X.509 certificate where the SPIFFE ID is encoded in the Subject Alternative Name (SAN) field. Used for existing TLS/mTLS infrastructure.
• JWT-SVID: A JSON Web Token containing the SPIFFE ID and optional claims. Ideal for application-level authentication and bearer tokens.
• SVIDs are automatically rotated before expiration, eliminating manual certificate management.

A local, node-local gRPC API exposed by the SPIRE Agent. Workloads call this API to retrieve their identity documents without needing to know how attestation or key management works.

• The API is exposed over a Unix Domain Socket, bound to the workload's filesystem namespace.
• Workloads simply request their SVID; the agent handles key generation, certificate signing, and rotation transparently.
• This decouples application logic from security infrastructure, enabling zero-trust service-to-service authentication without embedding secrets in code.

A mechanism that enables workloads in different trust domains to authenticate and establish secure communication with each other.

• Trust domains exchange their root certificates via a bundle endpoint.
• A SPIRE Server can be configured to federate with an external trust domain, allowing it to validate SVIDs issued by that foreign domain.
• This enables secure cross-organization, cross-cloud, or hybrid-environment communication without requiring a single, monolithic certificate authority.

The process by which a SPIRE Server cryptographically verifies the identity and integrity of a physical or virtual node before allowing it to join the trust domain.

• SPIRE uses attestor plugins to verify node properties. For example, an AWS EC2 attestor verifies the node's instance identity document against the AWS API.
• Only nodes that pass this hardware or platform-level verification are permitted to run SPIRE Agents and issue workload identities.
• This establishes a hardware root of trust for the entire identity issuance process, preventing rogue nodes from injecting unauthorized workloads.

The cryptographically verifiable document that proves a workload's identity in the SPIFFE ecosystem. An SVID is typically an X.509 certificate or a JWT token that binds a SPIFFE ID to a public key.

• X.509 SVIDs enable mutual TLS between services
• JWT SVIDs are portable tokens for cross-system federation
• Short-lived by default, typically with a TTL of 1 hour
• Automatically rotated by the SPIRE agent before expiration

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

• Trust domain defines the administrative boundary (e.g., spiffe://prod.example.com)
• Path identifies the specific service (e.g., /database/web-frontend)
• Enables platform-agnostic identity—works across Kubernetes, VMs, and bare metal
• Eliminates reliance on network-level identifiers like IP addresses for authentication

The process by which SPIRE cryptographically verifies the identity and integrity of a physical or virtual node before issuing identities to workloads running on it. This establishes a hardware-anchored chain of trust.

• Verifies platform-specific attributes (AWS instance identity documents, GCP tokens)
• Ensures only authorized infrastructure can participate in the trust domain
• Prevents spoofing attacks where rogue nodes request legitimate SVIDs
• Forms the root of trust for all downstream workload identities

A local gRPC endpoint exposed by the SPIRE agent on each node that applications call to retrieve their SVIDs and trust bundles. This is the primary integration point for workloads.

• Accessed via a Unix domain socket on Linux systems
• No network credentials required—identity is derived from the calling process
• Returns fresh certificates and private keys directly to the workload
• Supported by native libraries in Go, Java, C++, and Python

A collection of root CA certificates that a workload uses to verify the identity of its peers during mutual TLS handshakes. SPIRE automatically distributes and rotates trust bundles across the entire trust domain.

• Propagated to all nodes via the SPIRE agent hierarchy
• Updated automatically when root certificates rotate
• Enables federated identity across multiple trust domains
• Eliminates manual certificate distribution and configuration drift