SPIFFE & SVIDs — identity for services

Inside one system, dozens of services call each other every second. A request reaches service B and says "I am A". Your goal: learn how B can check that this is true, and not an imposter on the network.

Zero trust, but for machines

In zero trust, you never assume the network is safe. You check every request. The same rule applies to non-human identities, such as services and jobs.

A network that trusts anything inside the firewall is soft inside. One foothold lets an attacker pretend to be any service. So every call needs its own proof.

SPIFFE IDs and SVIDs

SPIFFE is an open standard that gives workloads identities they can prove. Two pieces matter.

First, the SPIFFE ID. It is a name shaped like a web address, for example spiffe://example.org/billing. It says which trust domain the workload belongs to, and which service it is.

Second, the SVID, the SPIFFE Verifiable Identity Document. It is the short-lived credential that proves a workload owns that ID. An SVID is either an X.509 certificate, used for mutual TLS, or a signed JWT. Prefer the certificate. The signed-token form is a bearer token, which anyone can replay. The Go deeper block below says when to use it.

Attestation: earning an SVID with no planted secret

A workload must not start with a secret. That secret would be one more thing to leak. Instead, the workload goes through attestation. At startup, the platform it runs on vouches for what it is. The node, the signed image and the labels all count as evidence.

An identity authority weighs the evidence. In SPIFFE this software is SPIRE. If the evidence checks out, it issues the SVID. No password goes into code or config.

Mutual TLS: both sides prove who they are

Ordinary web TLS works one way. Your browser checks the site's certificate, but the site rarely checks yours. Mutual TLS (mTLS) works both ways. When A calls B, both show their SVID certificates. Each side checks the other before any application data moves.

A checks that B's SVID is signed by the trust domain and names the service A expected. B does the same for A. Only then does the encrypted channel open. It is like DPoP and mTLS sender-constraining.

Short lives, automatic rotation

SVIDs are short-lived on purpose, often minutes to an hour. A stolen certificate soon stops working, so you rarely need a long revocation list. A small local agent fetches a fresh SVID before the old one expires. This is rotation, with no human step.