SPIFFE

The SVID is the core identity document issued by the SPIFFE control plane. It is a short-lived, frequently rotated cryptographic token—typically an X.509 certificate or JWT—that a workload uses to prove its identity to other workloads.

• X.509-SVID: Used for mutual TLS (mTLS) authentication between services.
• JWT-SVID: Used for bearer token authentication, often at application gateways or across trust boundaries.
• Short-lived: Default TTL is typically one hour, limiting the blast radius of a compromised credential.
• Automatic rotation: The SPIFFE Agent handles renewal before expiration, ensuring uninterrupted secure communication.

A SPIFFE ID is a URI that uniquely and unambiguously identifies a workload. It follows the format spiffe://trust-domain/path, providing a human-readable yet machine-verifiable identity namespace.

• Trust Domain: The trust-domain component corresponds to the root of trust, typically an organization or environment (e.g., spiffe://prod.example.com).
• Workload Path: The path identifies the specific service, user, or resource (e.g., /database/postgres).
• Decouples identity from location: Unlike IP-based identity, a SPIFFE ID remains constant regardless of where the workload runs—bare metal, VM, or Kubernetes Pod.
• Example: spiffe://acme-prod.internal/ns/frontend/sa/web-server identifies a specific service account in a specific namespace.

The SPIFFE Agent is a local daemon running on every node that performs workload attestation and manages SVID lifecycle. It is the bridge between the workload and the central control plane.

• Workload Attestation: The agent interrogates the local kernel or orchestrator to verify the identity of a calling process using platform-specific selectors (e.g., Linux UID, Kubernetes Service Account, container image hash).
• Key Management: Generates and stores private keys locally; the private key never leaves the node.
• Workload API: Exposes a local Unix domain socket endpoint where workloads request their SVIDs. No network calls required for the workload itself.
• Cache Management: Maintains an in-memory cache of SVIDs and responds to workloads with sub-millisecond latency.

The SPIFFE Server is the centralized control plane component responsible for validating agent identities, issuing SVIDs, and maintaining the trust bundle. It acts as the certificate authority and identity registry.

• Node Attestation: Before an agent can issue SVIDs, the server cryptographically verifies the node's identity using platform-specific evidence (e.g., AWS Instance Identity Document, GCP token, TPM quote).
• Registration API: Administrators define which workloads are entitled to which SPIFFE IDs using a registration entry database.
• Trust Bundle Distribution: Publishes a bundle of root CA certificates that all workloads in the trust domain use to validate each other's SVIDs.
• Federation: Can be configured to exchange trust bundles with other SPIFFE Servers in different trust domains, enabling cross-organization mTLS.

Attestation is the process by which the SPIFFE Agent proves the identity of a workload to the SPIFFE Server before an SVID is issued. This is achieved through selectors—platform-specific properties that uniquely identify a process.

• Kubernetes Selectors: k8s:ns:namespace, k8s:sa:service-account, k8s:pod-label:app:frontend.
• Linux Selectors: unix:uid:1000, unix:gid:2000, unix:path:/opt/myapp.
• Cloud Selectors: aws:ec2:instance-id, gcp:instance-name.
• Multi-factor attestation: Combining selectors (e.g., a specific container image AND a specific namespace) creates a strong, context-aware identity assertion that resists spoofing.

SPIFFE Federation enables workloads in different trust domains to authenticate each other using mTLS. This is essential for multi-cloud, hybrid, and partner integrations where a single SPIFFE Server is not authoritative.

• Trust Bundle Exchange: SPIFFE Servers exchange root CA certificates via a federation endpoint or a shared bundle endpoint URL.
• Federated SPIFFE IDs: A workload in domain A can validate an SVID from domain B if domain A's trust bundle includes domain B's root CA.
• Use Case: A microservice running in AWS (spiffe://aws.prod.example.com) securely calling an API in GCP (spiffe://gcp.prod.example.com) without shared secrets or VPN tunnels.
• Bundle chaining: Supports transitive trust across multiple federated domains.

A cryptographically verifiable document binding a SPIFFE ID to a public key. Two formats exist:

• X.509-SVID: An X.509 certificate where the SPIFFE ID is encoded in the Subject Alternative Name (SAN) URI field, enabling mTLS authentication
• JWT-SVID: A compact JWT token containing the SPIFFE ID in the sub claim, suitable for bearer token authentication in service meshes and API gateways Both formats include expiration timestamps and are rotated automatically by SPIRE.

The gRPC endpoint exposed by the SPIRE agent on each node via a Unix domain socket. Workloads call this API to:

• Fetch their current SVIDs (both X.509 and JWT)
• Receive streaming updates when certificates are rotated
• Retrieve trusted CA bundles for verifying peer identities
• Request JWT-SVIDs with custom audiences for specific services The API enforces workload attestation — only verified processes can obtain identities.

The logical boundary within which a SPIFFE ID is scoped, typically corresponding to an organization, cloud account, or cluster. All SPIFFE IDs within a trust domain share a common root of trust. For example, spiffe://acme.com defines a trust domain where identities like spiffe://acme.com/billing/payments reside. Cross-domain federation enables workloads in different trust domains to mutually authenticate by exchanging and validating each other's trust bundles.

The process by which SPIRE verifies the identity of the physical or virtual machine before allowing it to join the trust domain. Attestors leverage platform-specific evidence:

• AWS/GCP/Azure: Validates instance identity documents against cloud provider APIs
• TPM: Verifies cryptographic quotes from the Trusted Platform Module
• Kubernetes: Validates the node's service account token via the TokenReview API Successful node attestation establishes that the SPIRE agent is running on a legitimate, authorized host.

The process by which SPIRE verifies that a specific process or container is who it claims to be before issuing an SVID. Attestors inspect kernel-level properties:

• Unix: Validates the process's UID, GID, and binary path
• Kubernetes: Checks the pod's namespace, service account, labels, and image digest
• Docker: Verifies container labels and image IDs This ensures that only authorized workloads receive identities, preventing spoofing attacks.