Workload Identity

Workload identities are short-lived and auto-rotated, eliminating the risk of long-lived API keys or passwords being exfiltrated.

• Credentials are issued just-in-time by a central authority like SPIRE
• Expiry is typically measured in minutes or hours, not years
• Compromise windows are drastically reduced compared to static secrets
• No human intervention required for rotation; the agent handles it autonomously

Identity is not based on an IP address or a physical server, but on verifiable properties of the workload itself.

• Trusted Execution Environments (TEEs) provide hardware-rooted attestation
• SPIFFE IDs encode logical attributes like spiffe://cluster.local/ns/production/sa/payment-processor
• Cloud-agnostic: works across AWS, GCP, Azure, and on-premise bare metal
• Prevents lateral movement by ensuring a stolen credential is useless outside its attested context

Workload identity enables Mutual TLS (mTLS) where both the client and server prove their identity using X.509 certificates issued by the local agent.

• Eliminates reliance on network-level controls like firewalls for authentication
• The Envoy or linkerd sidecar proxy handles the handshake transparently
• Cryptographic proof of identity is required before any application data is exchanged
• Prevents agent impersonation attacks and man-in-the-middle interception

Authorization decisions are made dynamically based on the attributes encoded in the workload's identity document, not just a simple ID string.

• Policies evaluate logical context: namespace, service name, environment, and hardware root of trust
• Open Policy Agent (OPA) can consume SPIFFE IDs to enforce fine-grained Rego policies
• Example: Only a workload with the label env=staging can access the test database
• Enables Zero Trust by continuously verifying context, not just granting access once

Demonstration of Proof-of-Possession (DPoP) cryptographically binds an OAuth 2.0 access token to a specific client's private key.

• Prevents token replay attacks where a stolen bearer token is reused from a different machine
• The client must sign a nonce with its private key to prove ownership of the token
• Essential for high-security machine-to-machine flows where bearer token theft is a critical risk
• Complements SPIFFE by adding an application-layer proof on top of the transport-layer mTLS identity

Workload identity extends into the hardware layer by binding identity to a Trusted Execution Environment (TEE) like Intel SGX or AMD SEV.

• Remote Attestation provides a cryptographic proof of the exact software stack running inside the enclave
• Ensures data is processed only by verified code, not a compromised hypervisor or host OS
• Protects data in use, closing the final gap in the encryption lifecycle
• Critical for multi-party computation and regulated financial data processing

The bootstrapping challenge where a workload must authenticate to a secrets manager to retrieve its first credential, but needs a credential to do so. Workload identity solves this by providing an identity document issued by the platform itself (e.g., a Kubernetes projected service account token or a cloud instance identity document) that the workload can exchange for a short-lived SPIFFE SVID, breaking the circular dependency without storing long-lived secrets in code or configuration.