Courses Zero-trust & workload identitySPIFFE & SPIRE

SPIRE & attestation

Node + workload attestation, the Workload API.

Expert35 min · lesson 5 of 15

SPIRE — the SPIFFE Runtime Environment — is the production implementation that actually issues SPIFFE identities. Its clever part is attestation: how it decides which workload deserves which identity, without any workload holding a bootstrap secret.

Server, agents, and two-stage attestation

SPIRE has a Server (the CA and policy store, holding registration entries) and an Agent on each node (which attests workloads and exposes the Workload API). Trust is established in two stages. Node attestation proves the identity of the node the agent runs on — using a cloud instance identity document, a Kubernetes projected token (PSAT), or a join token — so the server trusts the agent. Then workload attestation proves a calling workload’s identity using selectors: properties like its Kubernetes service account, namespace, or unix uid that the agent verifies locally. Only a workload matching a registration entry’s selectors receives the corresponding SVID.

a registration entry maps selectors → identity

# "A workload on this node, running as the prod/payments service account,
#  should receive this SPIFFE ID." No secret is embedded in the workload.
spire-server entry create \
  -spiffeID spiffe://acme.internal/ns/prod/sa/payments \
  -parentID spiffe://acme.internal/spire/agent/k8s_psat/cluster/NODE \
  -selector k8s:ns:prod \
  -selector k8s:sa:payments
# The agent verifies the calling pod matches these selectors, then issues the SVID.

The Workload API and rotation

A workload fetches its SVID and trust bundle from the local SPIRE Agent over the Workload API — a unix socket — with no keys in its code, config, or image, and the agent transparently rotates the short-lived SVID before it expires. This solves the "secret zero" bootstrapping problem: the workload never holds a long-lived credential to prove its identity; instead, its runtime properties are attested. The result is exactly what zero trust needs — every workload gets a strong, short-lived, auto-rotated identity, established from platform-verifiable facts rather than a shared secret. Meshes can run their own SPIFFE-issuing CA or integrate with SPIRE for identity that spans beyond a single cluster.

SPIRE attestation and issuance

Two-stage attestation turns platform facts into identity — no bootstrap secret. The agent delivers and rotates short-lived SVIDs.

Weak selectors issue identity to the wrong workload

If a registration entry’s selectors are too loose (e.g. namespace only), multiple workloads could match and obtain an identity that is not theirs. Use specific, hard-to-forge selectors (service account plus namespace, ideally combined) so each identity is issued to exactly the intended workload.

SPIFFE IDs & SVIDsSVIDs & rotation