Workload identity & SPIFFE/SPIRE
Kill static tokens — attest workloads and federate cloud IAM.
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.
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.
# 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=$JWTtoken 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.