SPIFFE

A SPIFFE ID is a Uniform Resource Identifier (URI) that uniquely and unambiguously identifies a workload. The canonical format is spiffe://trust-domain/workload. For example, a model serving pod might receive the identity spiffe://ml-platform.example.com/inference/fraud-model-v3. This identity is not a username or role; it is a cryptographic assertion of what the software is, verified by the platform's attestation process. The trust domain anchors all identities within an organizational boundary, enabling federation across clusters and clouds.

An SVID is the portable, cryptographically verifiable document that a workload uses to prove its identity to other workloads. SPIFFE supports two SVID types:

• X.509-SVID: A short-lived X.509 certificate compliant with RFC 5280, where the SPIFFE ID is encoded in the Subject Alternative Name (SAN) field. Used for standard mTLS authentication.
• JWT-SVID: A compact JWT token containing the SPIFFE ID and optional claims, suitable for application-layer authentication across non-TLS transports or for bearer token flows. The SPIRE agent continuously rotates these documents, typically with a Time-To-Live (TTL) of one hour or less, minimizing the window of compromise.

SPIRE (the SPIFFE Runtime Environment) is the production-ready, CNCF-graduated implementation of the SPIFFE standards. It consists of two core components:

• SPIRE Server: The central authority that signs SVIDs and maintains the registration database mapping workloads to their authorized identities.
• SPIRE Agent: A daemon running on each node (e.g., Kubernetes worker) that performs node attestation and workload attestation. It verifies the node's provenance (e.g., via cloud provider instance identity documents) and then interrogates the kernel to confirm a process's attributes (e.g., its container image hash, namespace, or service account) before issuing an SVID. This chain of attestation ensures that only verified workloads receive cryptographic identities.

Workload attestation is the process by which SPIRE validates that a running process is genuinely what it claims to be before issuing an SVID. In a Kubernetes-based model serving environment, SPIRE agents use kernel-level selectors to interrogate the process:

• k8s:ns: The Kubernetes namespace (e.g., ml-inference-prod)
• k8s:sa: The service account (e.g., fraud-detector)
• k8s:container-image: The SHA256 digest of the container image (e.g., sha256:abc123...)
• unix:uid and unix:gid: The Unix user and group IDs executing the process This prevents a compromised sidecar container in the same pod from impersonating the model server, as its process attributes would not match the registration entry.

SPIFFE federation enables workloads in different trust domains (e.g., ml-platform.example.com and data-lake.example.com) to authenticate each other. This is critical when a model serving pod in one cluster must fetch feature vectors from a feature store in another cluster. Federation is established by:

• Exchanging the public keys of each domain's SPIRE server via a trust bundle
• Configuring a federation relationship that maps foreign trust domains to local identity policies When a workload receives an SVID from a foreign domain, it validates the signature chain against the federated trust bundle. This eliminates the need for shared secrets or manually rotated API keys between organizational boundaries.

Traditional API key authentication for model inference endpoints introduces several operational risks that SPIFFE eliminates:

• Secret Zero Problem: API keys are static secrets that must be provisioned and rotated. A leaked key grants indefinite access. SPIFFE SVIDs are short-lived and automatically rotated by the SPIRE agent.
• No Identity Binding: An API key authenticates a request, not a workload. A stolen key works from anywhere. An SVID is cryptographically bound to the attested workload's process and node.
• Manual Rotation: Key rotation requires orchestration and can cause downtime. SPIRE handles rotation transparently.
• Audit Ambiguity: Logs showing an API key provide no context about the calling software. A SPIFFE ID in an audit log precisely identifies the calling service, version, and namespace.

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

• Trust Domain: The administrative root of identity (e.g., spiffe://acme-corp.com)
• Workload Identifier: A path-based name for a specific service (e.g., /ml-serving/inference-api)
• SPIFFE IDs are embedded in X.509-SVIDs and JWT-SVIDs
• Unlike DNS-based identities, SPIFFE IDs are not tied to network location, making them ideal for dynamic container orchestration

A cryptographically verifiable document that proves a workload possesses a specific SPIFFE ID. The SPIFFE specification defines two SVID types:

• X.509-SVID: A short-lived X.509 certificate where the SPIFFE ID is encoded in the Subject Alternative Name (SAN) field. Used for mutual TLS authentication between model serving components.
• JWT-SVID: A compact JWT token containing the SPIFFE ID and audience-restricted claims. Ideal for inter-service authorization headers in gRPC or REST inference calls.
• Both types are automatically rotated by the SPIFFE Agent before expiration, eliminating credential management overhead.

SPIRE (the SPIFFE Runtime Environment) is the production-grade, CNCF-graduated implementation of the SPIFFE standards. It operates as a two-component system:

• SPIRE Server: The central control plane that manages the trust domain, maintains the registration database of attested workloads, and issues SVIDs.
• SPIRE Agent: A daemon running on each node (Kubernetes node or VM) that performs node attestation and workload attestation to verify the identity of local processes before issuing them SVIDs.
• SPIRE supports multiple attestors including AWS EC2 Instance Identity Documents, Kubernetes Service Account tokens, and Unix domain socket verification.

A mechanism that enables workloads in different SPIFFE trust domains to authenticate and communicate securely. This is essential for cross-cluster model serving or hybrid cloud deployments.

• Trust domains exchange a federation bundle containing the public keys of the foreign domain's SPIRE Server.
• A workload in spiffe://prod.acme.com can verify an SVID issued by spiffe://staging.acme.com using the federated trust bundle.
• Federation is configured via a bundle endpoint URL or manually exchanged JSON Web Key Sets (JWKS).
• This enables zero-trust communication between a model training cluster and a geographically separate inference cluster.

SPIRE integrates natively with Envoy Proxy via the Secret Discovery Service (SDS) API to deliver dynamically rotated X.509-SVIDs directly to the Envoy process.

• Envoy uses the SVID certificate and private key for downstream TLS (authenticating to clients) and upstream TLS (authenticating to backend model servers).
• The SPIRE Agent pushes new certificates to Envoy before expiration without restarting the proxy or dropping connections.
• This architecture enables a fully transparent mTLS mesh where every inference API call between sidecars is automatically authenticated and encrypted using workload identity, not network IP.