Workload identity 101: replacing long-lived secrets

The problem

Most production incidents start with a leaked API key. The key was issued years ago, lives in an environment variable, was committed to a git history, and authorizes more than it needed to. Workload identity replaces this pattern.

What workload identity is

A cryptographic identity issued to a software workload (container, function, service), short-lived, and attested by the underlying platform. Instead of "here's my secret API key," the workload presents "here's a cryptographic credential proving I am the payments-service running in production cluster east-1."

The standards

• SPIFFE: Identity specification. SPIRE is the reference runtime.
• Cloud-native equivalents: AWS IAM Roles for Service Accounts (IRSA), GCP Workload Identity, Azure Workload Identity, Kubernetes ServiceAccount tokens with OIDC trust.

These coexist. Most multi-cloud deployments end up running SPIFFE for cross-cloud identity and using cloud-native primitives where the trust path is internal.

Implementation pattern

1. Workload starts. Platform attests it (running in this pod, in this namespace, in this cluster).
2. Workload requests a credential from the identity authority.
3. Identity authority issues a short-lived credential (SVID, JWT, x.509 cert) bound to the workload's identity.
4. Workload uses the credential to call other services. Receivers validate.
5. Credential expires in minutes. Workload renews.

What this replaces

• Long-lived API keys in environment variables
• Service account passwords in vaults that workloads then read with another long-lived credential
• Mutual TLS with manually managed certificates
• Shared secrets between services

What it doesn't replace

• Application-level authorization decisions (the workload identity tells you what service is calling, not whether that call is allowed)
• Database row-level security
• End-user identity in requests that originate from humans

Common pitfalls

• Skipping platform attestation and just trusting whatever the workload claims it is
• Issuing workload identities with permissions that match historical API keys (carrying over over-privilege)
• Not federating SPIFFE with cloud-native identity, requiring workloads to handle multiple credential types
• Treating workload identity as a vault problem when it's an identity problem