Workload Identity
& Service-Mesh AuthZ

The workload-identity problem

• Why service-to-service is fundamentally different from user-to-service
• The crisis of long-lived API keys
• What "identity" means for a process / pod / Lambda

The user-AuthN solution doesn't translate

• OAuth assumes a human in the loop to consent.
• Passwords / passkeys assume a person with a device.
• Services have none of those — they boot, attempt a connection, and need to prove themselves immediately.

SPIFFE ID — the identifier

spiffe://acme.com/billing/payments-svc

      └── trust domain ──┘└── workload path ──┘

• URI format. The trust domain is your organisational boundary; the path identifies the workload.
• Path is yours to design — by team / service / environment / pod.
• Two workloads with the same SPIFFE ID are considered the same identity.

Node attestation plugins

• k8s_psat — Kubernetes projected service account token, validated against the cluster's OIDC issuer.
• aws_iid — AWS instance identity document signed by EC2.
• aws_iam — STS GetCallerIdentity proves the EC2 role.
• gcp_iit / azure_msi — equivalents.
• x509pop / sshpop — proof-of-possession of pre-issued credentials.
• tpm — TPM EK/AK chains for bare metal.

The problem

• You have spiffe://acme.com for production.
• Your acquired company runs spiffe://oldco.com.
• A service in acme needs to call a service in oldco.
• Each trust domain has its own CA. Neither side trusts the other by default.

A typical L7 rule

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata: { name: ledger-allow-payments, namespace: billing }
spec:
  selector:
    matchLabels: { app: ledger-svc }
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/billing/sa/payments-svc"]
      to:
        - operation:
            methods: ["GET","POST"]
            paths:   ["/v1/postings/*"]
      when:
        - key:    request.auth.claims[scope]
          values: ["postings:write"]
        - key:    request.headers[x-tenant-id]
          notValues: [""]

The three CRDs

# 1. Server — selects ports on workloads to protect
apiVersion: policy.linkerd.io/v1beta3
kind: Server
metadata: { name: ledger, namespace: billing }
spec:
  podSelector:
    matchLabels: { app: ledger-svc }
  port: 8080
  proxyProtocol: HTTP/2

---
# 2. AuthorizationPolicy — bind a target to a Required* auth
apiVersion: policy.linkerd.io/v1alpha1
kind: AuthorizationPolicy
metadata: { name: ledger-from-payments, namespace: billing }
spec:
  targetRef:
    group: policy.linkerd.io
    kind: Server
    name: ledger
  requiredAuthenticationRefs:
    - { group: policy.linkerd.io, kind: MeshTLSAuthentication,
        name: payments-svc-id }

---
# 3. MeshTLSAuthentication — who is allowed
apiVersion: policy.linkerd.io/v1alpha1
kind: MeshTLSAuthentication
metadata: { name: payments-svc-id, namespace: billing }
spec:
  identities:
    - "payments-svc.billing.serviceaccount.identity.linkerd.cluster.local"

Cilium in two sentences

An eBPF-based CNI for Kubernetes. Network policy, observability, encryption and L7 inspection are enforced by eBPF programs in the kernel — no per-pod sidecar, often lower overhead.

The bits that hurt

• Issuance — every workload needs a fresh cert when it boots, ideally without ever holding a long-lived CA key.
• Rotation — short-lived certs (5–60 min) re-rolled before expiry, automatically.
• Trust bundle distribution — every verifier needs the latest CA bundle even as you rotate roots.
• CA root rotation itself — rare but required, and many setups never rehearse it.

Pod spec

apiVersion: v1
kind: Pod
spec:
  serviceAccountName: payments-svc
  containers:
    - name: app
      image: acme/payments:1.4
      volumeMounts:
        - mountPath: /var/run/secrets/aws
          name: aws-token
  volumes:
    - name: aws-token
      projected:
        sources:
          - serviceAccountToken:
              audience: sts.amazonaws.com
              expirationSeconds: 3600
              path: token

Istio RequestAuthentication + AuthorizationPolicy

# 1. Validate JWTs from this issuer
apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata: { name: jwt-acme, namespace: billing }
spec:
  selector: { matchLabels: { app: ledger-svc } }
  jwtRules:
    - issuer: "https://login.acme.com/"
      jwksUri: "https://login.acme.com/.well-known/jwks.json"
      audiences: ["https://api.acme.com/ledger"]

---
# 2. Require a valid JWT with the right scope
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata: { name: ledger-write, namespace: billing }
spec:
  selector: { matchLabels: { app: ledger-svc } }
  action: ALLOW
  rules:
    - to: [{ operation: { methods: ["POST"], paths: ["/v1/postings"] } }]
      when:
        - key: request.auth.claims[scope]
          values: ["postings:write"]
        - key: request.auth.claims[iss]
          values: ["https://login.acme.com/"]

Why agents make this harder

• An agent calls many MCP servers, often in different trust domains.
• The agent itself is a workload — it needs an identity.
• The MCP server's authz often wants to distinguish the human user from the agent acting on their behalf.
• Tokens flow through more hops than typical SaaS — agent → gateway → MCP server → upstream API.

Static keys → IRSA / WI

1. Inventory every long-lived AWS / GCP / Azure key in app code, config, secrets.
2. Create a per-workload IAM role / GCP SA / Entra app with the same permissions.
3. Configure the cluster's OIDC issuer in the cloud's STS (one-off per cluster).
4. Annotate the K8s ServiceAccount and add the projected token volume.
5. Cut over one workload at a time; verify CloudTrail / Audit Logs show the new role.
6. Rotate the static key one last time, verify nothing breaks, then delete it.

What we covered

• Workload identity as a problem — why user-AuthN doesn't translate
• SPIFFE specification — IDs, SVIDs (X.509 + JWT), federation
• SPIRE — server / agent, attestation, registration entries
• Service mesh AuthZ — what the sidecar gives you
• Istio AuthorizationPolicy patterns and pitfalls
• Linkerd's three-CRD model
• Cilium L4/L7 + Tetragon for runtime enforcement
• mTLS at scale — issuance, rotation, observability, root rotation
• Cloud-native workload identity (IRSA / WI / Managed Identity / WIF)
• K8s ServiceAccountTokenVolumeProjection — the substrate
• Service mesh + JWT for end-user identity at L7
• Workload identity for AI agents & MCP servers
• Choosing a stack · migration · production gotchas