CoursesAdvanced secrets managementIdentity, policy & multi-tenancy

Workload identity & SPIFFE/SPIRE

Kill static tokens — attest workloads and federate cloud IAM.

Expert35 min · lesson 9 of 15

The endgame of secret-zero is that workloads carry a cryptographically-verifiable identity that no human ever provisions as a secret. SPIFFE (a standard) and SPIRE (its implementation) deliver exactly this: every workload receives a short-lived identity document (an SVID) that attests what it is, issued only after the platform proves the workload’s properties. Once workloads have real identity, secrets managers and cloud IAM can trust them directly — and static credentials disappear from the picture entirely.

SPIFFE IDs and SVIDs

A SPIFFE ID is a URI like spiffe://acme.internal/ns/prod/sa/payments that names a workload. SPIRE issues that identity as an SVID — either an X.509 certificate or a JWT — with a very short lifetime, rotated automatically. The workload does nothing to earn it beyond being what it says it is: the SPIRE agent on the node attests the workload using selectors (its Kubernetes service account, its Unix UID, its container image digest) before handing over an SVID. The result is a portable, platform-neutral identity that means the same thing across Kubernetes, VMs, and clouds.

How a workload gets an identity with SPIRE
1agent attests node
to the SPIRE server
2workload asks agent
over the local API
3agent checks selectors
SA, UID, image digest
4issue SVID
short-lived cert/JWT, auto-rotated
Identity is attested from platform facts — nothing secret is ever provisioned to the workload.

From identity to secrets and cloud IAM

With SVIDs in hand, two things get much simpler. First, mTLS everywhere: services authenticate to each other with their SVIDs, which is precisely what a service mesh does under the hood. Second, federation: a SPIFFE JWT-SVID can be exchanged for cloud credentials via OIDC federation (AWS IAM Roles Anywhere, GCP Workload Identity Federation) or for a Vault token via the JWT auth method — so a workload obtains scoped cloud and secrets access using only its attested identity. The static access key and the shipped Vault token both cease to exist.

terminal — exchange a SPIFFE JWT-SVID for a Vault token
# workload fetches a JWT-SVID for the audience "vault"
$ JWT=$(spire-agent api fetch jwt -audience vault -socketPath /run/spire/agent.sock \
| awk "/token/{print \$2}")
# Vault JWT auth trusts the SPIRE issuer and maps the SPIFFE ID to a role
$ vault write auth/jwt/login role=payments jwt=$JWT
token hvs.CAE... ttl 20m # scoped by the SPIFFE-ID -> role binding
# no static secret anywhere in this flow.

Is SPIFFE/SPIRE worth it?

SPIRE is real operational weight — a server, agents on every node, an attestation policy to maintain — so it earns its place at a specific scale: heterogeneous workloads (Kubernetes plus VMs plus multiple clouds) that need one consistent identity, or a zero-trust mandate where every service-to-service call must be mutually authenticated. For a single Kubernetes cluster talking to one Vault, native Kubernetes auth already gives you attested identity with far less machinery. Reach for SPIFFE/SPIRE when identity has to span platforms, not before.

Attestation selectors are the security boundary
An SVID is only as trustworthy as the selectors that gate it. Attesting on a shared service account or a mutable tag lets a hostile pod on the same node obtain another workload’s identity. Pin selectors to strong, hard-to-forge facts — the container image digest, a specific service account in a specific namespace — and keep the SPIRE server’s trust bundle and registration entries under the same review discipline as any other root of trust.