AI
SPIFFE Fundamentals and the WIMSE Working Group
SPIFFE assigns workloads URI-based identities called SPIFFE IDs. The trust domain sits in the host part; the path identifies the specific workload, such as a billing service run by the payments team in the European zone. These IDs drive authorization decisions and audit logging. SPIRE, a CNCF graduate project, is the most common implementation. WIMSE (Workload Identity in Multi-Service Environments) formed at the IETF in March 2024 to standardize patterns like instance metadata at cloud providers and ID tokens in CI/CD systems.
X.509 SVIDs and the TLS Termination Problem
X.509 SVIDs embed the SPIFFE ID in the Subject Alternative Name field and bind it to a key pair. Mutual TLS is the dominant use case: workloads can identify as both client and server in one connection. The technology is decades old and handles millions of connections per second. The main limitation: client certificate authentication requires one uninterrupted TLS connection. When a layer-7 load balancer terminates TLS, the certificate must be forwarded in a header, which creates security concerns. That was a major adoption blocker.
JWT SVIDs and Bearer Token Risk
JWT SVIDs encode the SPIFFE ID in the sub claim and restrict recipients via the aud (audience) claim. They pass through TLS-terminating proxies and work with OIDC. Azure, GCP, and AWS all accept them to replace long-lived service account credential files. The problem is the bearer model: anyone who exfiltrates or intercepts a JWT can use it until expiry. Kubernetes service account tokens have the same flaw. Short TTLs (minutes, not hours) reduce the window but increase signing infrastructure load significantly.
The Workload Identity Token
The Workload Identity Token (WIT) combines JWT’s usability with X.509’s key binding. It is a JOSE-based JWT with a cnf (confirmation) claim that embeds the workload’s public key in the token, similar to an X.509 certificate. Every call requires proof of possession: the workload signs the request with its private key, proving it controls the key the token was issued to. That makes a stolen WIT useless without the key. WIT SVIDs also survive TLS termination at ingress controllers, protecting identity across the full call chain.
WIT SVID Support in SPIRE
SPIRE exposes a Unix domain socket that workloads use to request credentials. The workload API now provides three methods: JWT SVID, X.509 SVID, and WIT SVID. Calling the WIT endpoint returns a JWT alongside the corresponding private key. Decoding that JWT reveals the cnf claim containing the workload’s public key and the SPIFFE subject ID. Any SPIFFE-enabled workload can call this today and receive a WIT. The specification is in preview; the SPIFFE community is working toward RFC status and broader SDK support.
Q&A
Is an extra hop needed to use the WIT SVID? No. The workload holds its private key for the full validity period, and key binding allows longer TTLs (such as a day) since a stolen WIT is useless without the key. ▶ 24:04
Does proof of possession require extra round trips? No. Two approaches exist: HTTP message signatures (sign the request itself, no round trips) or a short client-generated token proving key possession. Neither requires a challenge-response exchange. ▶ 25:07
Does the second approach become a bearer token? Somewhat. If both the WIT and the proof token are intercepted together, replay is possible. Binding request context such as a content digest to the signature limits that attack surface. ▶ 26:19
Notable Quotes
has a really weak security model. Noah Stride · ▶ 15:09
who has their possession can use them. Arndt Schwenkschuster · ▶ 16:25
the attacker would not have the key. Arndt Schwenkschuster · ▶ 24:44
Key Takeaways
- SPIFFE IDs are URI-based workload identifiers that abstract platform-specific identity (Kubernetes, AWS IAM, GCP).
- X.509 SVIDs fail in environments using layer-7 load balancers because client auth requires an unbroken TLS connection.
- JWT SVIDs pass through proxies but are bearer tokens; any intercepted token is usable until expiry.
- The WIT SVID adds a
cnfclaim binding the workload’s public key, requiring proof of possession on every call. - Key binding allows longer TTL credentials and improves signing infrastructure resilience during network outages.
About the Speaker(s)
Noah Stride is the Lead of Machine and Workload Identity at Teleport. A member of the SPIFFE Steering Committee and a maintainer of the SPIFFE specification, he focuses on secure, identity-based access for machines and workloads.
Arndt Schwenkschuster is a Software Engineer at Defakto Security focused on workload identity. He is a SPIFFE maintainer, SPIFFE Steering Committee member, and active contributor to the IETF OAuth and WIMSE working groups, where he has authored multiple adopted documents.