Ask how your services authenticate to each other and the honest answer at most companies is: an API key in an environment variable, deployed by CI, rotated approximately never. The zero-trust crowd's answer — every workload gets a cryptographic identity, connections are mutually verified, and nothing long-lived exists to steal — sounds like a fantasy until you see how SPIFFE/SPIRE actually assembles it:
A real techdiagrams document — download the JSON and import it into the editor.
The idea: identity as a name, not a secret
SPIFFE defines identities as URIs: spiffe://prod.corp/orders. Not an IP address (those get recycled), not a Kubernetes service account token (those get exfiltrated), not a password. The identity is carried in a short-lived X.509 certificate called an SVID — and the interesting question is how a workload gets one without first presenting… some other secret. That bootstrap problem is what SPIRE solves.
Attestation: proving what you are, not what you know
Follow the diagram top to bottom:
Node attestation. Each machine runs a SPIRE agent. The agent proves to the SPIRE server what node it is using evidence that can't just be copied — the cloud provider's signed instance identity document on AWS/GCP, a TPM quote on metal, the kubelet's identity in Kubernetes. No pre-shared secret: the platform itself vouches for the node.
Workload attestation. When the Orders API asks its local agent for an identity (over a Unix socket — the Workload API), the agent inspects the caller through the kernel and platform: which binary, which cgroup, which Kubernetes pod and service account. It matches those facts against registration entries — "anything running as pod X on node group Y is spiffe://prod.corp/orders" — and only then hands over the SVID.
Notice what never happened: nobody deployed a credential. The workload's identity derives from what it verifiably is, checked at runtime, twice.
Then mTLS becomes almost boring
With both sides holding SVIDs, the green connection in the diagram is ordinary mutual TLS with extraordinary properties:
- Both directions verified. Payments knows the caller is
spiffe://prod.corp/orders— not "something from inside the network" (the perimeter assumption that every breach post-mortem regrets). - Rotation in minutes, not quarters. SVIDs live for an hour or less and renew automatically over the Workload API. A leaked cert is a stale cert before an attacker finishes their coffee.
- Authorization gets a real subject. Policies become "payments accepts calls from
/ordersand/billing" — enforceable at the connection, auditable by name.
Honest costs
- SPIRE is infrastructure — a server (make it highly available), an agent per node, and a registration-entry pipeline that must live in code, not in someone's terminal history. You're running a tiny CA with opinions.
- The Workload API socket is now precious. Anything that can talk to the agent's socket as the workload is the workload. Container and socket hygiene stop being optional.
- Federation is real work. Two trust domains (two companies, two clusters) need bundle exchange and rotation discipline.
- The pragmatic on-ramp most teams take: a service mesh (Istio uses this exact SPIFFE model underneath) — you inherit the architecture without operating raw SPIRE on day one.
Design it before you trust it
Identity flows are exactly the kind of architecture where the picture is the security review: who attests whom, what crosses which boundary, what happens when the SPIRE server is down (existing connections keep working; new SVIDs don't issue — did your design account for that?). Import the diagram into techdiagrams.net, and the pattern badges on that green edge — encrypted, authenticated — stop being aspirations and become annotations on a design you can actually interrogate.