Workload Identity: SPIFFE and SPIRE

The Problem with IP-Based Identity

Historically, services identified themselves by IP address. The database trusted connections from 10.0.1.5 because that was the app server's IP. In Kubernetes, this breaks completely: pods are ephemeral, IPs are reassigned constantly, and multiple replicas of the same service share the same IP range as unrelated services. IP addresses are terrible identifiers for workloads.

We need a standardized, cryptographic way to give every piece of software a stable identity that travels with it regardless of where it runs.

SPIFFE: The Standard

SPIFFE (Secure Production Identity Framework For Everyone) is an open standard — a specification, not a piece of software. It defines two things:

1. The SPIFFE ID format. Every workload gets a URI-formatted identifier:

spiffe://<trust-domain>/<workload-path>

For example:

spiffe://acme.com/ns/payments/sa/payment-service
spiffe://acme.com/ns/payments/sa/payment-db
spiffe://acme.com/ns/frontend/sa/web-app

The trust domain (acme.com) scopes the identity to your organization. The path encodes meaningful context about the workload.

2. The SVID (SPIFFE Verifiable Identity Document). This is how the SPIFFE ID is encoded into a real cryptographic artifact — specifically, an X.509 certificate (for mTLS) or a JWT (for HTTP-based auth). The SPIFFE ID is embedded in the certificate's Subject Alternative Name (SAN) field.

SPIRE: The Implementation

SPIRE (SPIFFE Runtime Environment) is the reference implementation of the SPIFFE standard. It is an automated Certificate Authority designed for dynamic cloud environments. SPIRE has two components:

• SPIRE Server: The central CA. Holds the root signing key. Defines workload registration policies.
• SPIRE Agent: Runs on every node (as a DaemonSet in Kubernetes). Acts as the local intermediary between workloads and the SPIRE Server.

How SPIRE Works: Attestation

The clever part of SPIRE is how it solves the chicken-and-egg problem of identity bootstrapping. When a workload starts and requests a certificate, SPIRE performs Attestation — it independently verifies the workload's claimed identity using trusted platform signals, without relying on the workload to prove itself.

Here is the step-by-step flow for a Kubernetes workload:

Step 1: Node Attestation. The SPIRE Agent on a node proves its own identity to the SPIRE Server using the Kubernetes node's identity (via the node's API server credentials or a cloud provider attestor like AWS Instance Identity Documents).

Step 2: Workload Attestation. When payment-service starts and calls the local SPIRE Agent socket requesting a certificate, the agent does not trust the request blindly. It queries the Kubernetes API: "What pod is running at this process ID? What namespace? What service account? What node?" It cross-references this against the workload registration entries defined in the SPIRE Server.

Step 3: Certificate Issuance. If the workload matches a registered entry (e.g., "pods in namespace payments with service account payment-service"), the SPIRE Agent requests a signed certificate from the SPIRE Server. The certificate contains the SPIFFE ID spiffe://acme.com/ns/payments/sa/payment-service and is valid for a short duration (e.g., 1 hour).

Step 4: Automatic Rotation. Before the certificate expires, the SPIRE Agent automatically fetches a new one and delivers it to the workload via the Workload API. The workload never touches a private key directly — the agent manages the entire lifecycle.

payment-service pod
      |
      | "I need my certificate"
      v
SPIRE Agent (on same node)
      |
      | Queries: "What pod is at this PID?"
      v
Kubernetes API → "It's payment-service in namespace payments, SA payment-service"
      |
      | Matches registration entry? YES
      v
SPIRE Server
      |
      | Signs certificate with SPIFFE ID:
      | spiffe://acme.com/ns/payments/sa/payment-service
      v
SPIRE Agent → delivers cert + private key to payment-service
      |
      v
payment-service uses cert for mTLS with payment-db

SPIRE in Practice: Service Meshes

In many production environments, you do not interact with SPIRE directly at the application level. Service meshes like Istio and Linkerd use SPIFFE-compatible identity systems under the hood. Istio's Citadel (now part of istiod) acts as a SPIFFE-compatible CA, automatically injecting Envoy sidecar proxies that handle mTLS using SPIFFE SVIDs — all transparently, without any code changes to your application. Understanding SPIFFE/SPIRE gives you the conceptual foundation to understand what these service meshes are doing internally.