Pull up the environment variables of almost any internal service and you will find the same thing: a token that authenticates it to three other services, created in 2022, rotated never, known to everyone who has ever had production access, and present in at least one CI log. It is not a secret. It is a password that a dozen people and every process on the node share.
Workload identity replaces that with something the platform issues and expires on its own: a cryptographic identity per workload, delivered as a short-lived certificate, verified on every connection. The reason to care is not compliance theatre. It is that lateral movement — the part of a breach that turns one compromised pod into an incident — depends almost entirely on credentials that are long-lived and over-scoped.
Identity the workload cannot lie about
The core idea is attestation. Instead of the workload presenting a secret it was given, the platform observes what the workload actually is — this pod, in this namespace, running this service account, on this node — and issues an identity document derived from that. SPIFFE standardises the name and the document: a URI like spiffe://prod/ns/billing/sa/invoicer, carried in a short-lived X.509 certificate or JWT.
The certificate lifetime is where the property comes from. At an hour or less, a stolen identity is worth almost nothing, rotation is continuous rather than an annual project, and revocation stops being the hard problem it is with long-lived credentials. Nothing is stored in a secret manager for a human to copy, because nothing is long-lived enough to be worth copying.
# Authorization is an identity policy, not a network rule.
# 'Only the invoicer service may call the ledger write API' is now expressible.
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
name: ledger-writes
namespace: ledger
spec:
selector:
matchLabels: { app: ledger }
action: ALLOW
rules:
- from:
- source:
principals: ["cluster.local/ns/billing/sa/invoicer"]
to:
- operation:
methods: ["POST"]
paths: ["/v1/entries"]Compare that with the control it replaces — a network policy allowing a CIDR range, plus a shared bearer token. The CIDR says which pods can reach the port; it says nothing about which service is calling. Identity-based policy says the thing you actually meant.
Extending it past the cluster edge
The same mechanism removes static cloud keys. OIDC federation lets a workload exchange its platform identity for short-lived cloud credentials, so your CI pipeline and your pods stop holding permanent access keys entirely. This is the highest-value change available to most teams, and it is usually a day of work: the long-lived key in your CI settings is, statistically, the credential most likely to leak.
- Start with CI. Replace static cloud keys with OIDC federation before touching service-to-service traffic.
- Keep certificate lifetimes short — an hour or less — so rotation is a property of the system, not a runbook.
- Make policy identity-based; network reachability is a blast-radius control, not an authentication one.
- Log the SPIFFE ID on every request. 'Which workload did this' becomes answerable without correlating IPs to pods that no longer exist.
- Audit for anything that still reads a token from the environment; those are your remaining lateral-movement paths.
A credential that never expires is not a secret. It is a password shared with everyone who has ever touched the system.
The honest cost is operational: a mesh or an identity agent is real infrastructure, and certificate expiry becomes a new class of outage if clock skew or renewal goes unmonitored. But the alternative is a system where one compromised container yields a credential that works everywhere, forever, and cannot be traced back to a caller. I have worked an incident on both sides of that line. The identity side is a much shorter night.