Workload Identity

The long-standing problem in service-to-service authentication is bootstrapping: a service needs a credential to prove who it is, and that credential must be delivered somehow, which means it exists somewhere it can be stolen. Every static secret in a configuration file, environment variable or vault is an instance of this.

Workload identity removes the stored secret. The platform — the cloud provider, the orchestrator — knows what it is running and attests to it, issuing a short-lived credential to the workload based on its verified identity. There is nothing durable to steal, and the credential expires in minutes.

The practical implementations converge on the same shape: a short-lived certificate or token delivered through a local endpoint or mounted file, automatically rotated, scoped to a specific service identity, and verifiable by the receiver against a trusted issuer.

Two consequences for architecture. Authorisation policies can now be written against workload identity rather than network location, which is what makes zero trust implementable rather than aspirational — "the payments service may call the ledger" instead of "this subnet may reach that port". And the identity is verifiable across clusters, clouds and on-premises if the trust domains are federated, which matters for hybrid estates far more than for single-cloud ones.