Nimendra's Notes 🪴

Attestation & Workload Identity

3 min read

kubernetes distributedsystem/microservice kubernetes/security

Core Idea

In microservices, static API keys do not scale: workload identity gives a pod a cryptographically verifiable identity, and attestation checks the evidence behind it.

  • Workload identity: an identity for a running pod, container, or process, not a human user.
  • Attestation at two levels: platform (hardware and infrastructure) and workload (software).
  • Cloud integration (IRSA, Workload Identity) and SPIFFE and SPIRE as the open standard.

In a microservices architecture, you have dozens or hundreds of services talking to each other. The fundamental question is: How does Service a know that the caller claiming to be Service B is acturally ServiceB, and not a compromised pod or a malicious actor ?

Traditional approaches (static API keys, shared secrets) don't scale and are hard to rotate. This is where workload identity and attestation come in.

Workload Identity

A workload identity is a cryptographically verifiable identity assigned to a running workload (a pod, container, or process) — not a human user.

Key properties:

  • Short-lived — credentials expire in minutes/hours, not months
  • Automatic — injected into the workload without developer intervention
  • Bound to the workload’s lifecycle — revoked when the pod dies
  • Not a secret you store — it’s derived from the platform’s trust chain

In Kubernetes, the native primitive for this is the Service Account Token — a signed JWT that the API server issues to each pod, scoped to a specific ServiceAccount resource.

Pod → mounts a projected ServiceAccount token → 
      signed by the K8s API server → 
      audience-bound (only valid for a specific recipient)

Attestation

Attestation is the process by which a workload proves its identity to a third party. It answers: “I am who I say I am, and here’s cryptographic proof.”

There are two layers:

1. Platform Attestation (Hardware/Infrastructure level)

The underlying platform (cloud provider, TPM chip) issues a signed statement about what is running and where. Examples:

  • AWS EC2 Instance Identity Documents
  • GCP Confidential Computing attestation
  • TPM-based remote attestation (measured boot)

2. Workload Attestation (Software level)

A trusted agent (like SPIRE or Istio’s node agent) inspects the local environment — kernel namespaces, cgroup IDs, pod metadata — and issues an identity only if the workload matches a known policy.

Workload → "I am pod X in namespace Y"
Agent    → checks kernel: is this process really in pod X's cgroup?
Agent    → issues SVID (SPIFFE Verifiable Identity Document) if policy matches

Cloud Provider Integration (IRSA, Workload Identity)

Cloud providers extend this further, binding Kubernetes service accounts to cloud IAM roles:

AWS IRSA (IAM Roles for Service Accounts)

Pod's projected ServiceAccount token
→ Pod calls AWS STS: AssumeRoleWithWebIdentity
→ STS validates token signature (OIDC)
→ Returns temporary AWS credentials
→ Pod can now call S3, Secrets Manager, etc.

GKE Workload Identity works the same way — mapping a K8s ServiceAccount to a GCP ServiceAccount, with the GKE metadata server handling token exchange transparently.

SPIFFE & SPIRE — The Open Standard

SPIFFE (Secure Production Identity Framework For Everyone) is the identity specification. It defines:

  • A URI-based identity format: spiffe://trust-domain/path
    • e.g., spiffe://example.com/ns/payments/sa/checkout
  • The SVID — a short-lived X.509 cert or JWT carrying that URI
    SPIRE is the reference implementation of SPIFFE.

SPIFFE

Backlinks

Graph View