title: "Zero-Trust Cloud Credentials: AWS IRSA vs EKS Pod Identity vs Azure Workload Identity at Multi-Cloud Scale" date: 2026-09-07 tags: [kubernetes, aws, azure, iam, security, devsecops, multi-cloud]

Cover: Workload Identity Federation across AWS and Azure Kubernetes

Zero-Trust Cloud Credentials: AWS IRSA vs EKS Pod Identity vs Azure Workload Identity at Multi-Cloud Scale

1. Topic of the Day

Every fleet that runs Kubernetes on a public cloud eventually hits the same wall: pods need to call cloud APIs — S3, DynamoDB, Key Vault, Secrets Manager, Pub/Sub — and someone has to decide how those pods authenticate. The naive answer, long-lived static credentials baked into a Secret or an environment variable, is also the most common root cause of cloud breaches: leaked access keys, over-broad instance profiles inherited by every pod on a node, and credentials that outlive the workload by years.

Workload identity federation exists to kill that pattern. Instead of a static secret, a workload proves who it is using a short-lived, cryptographically signed token that the cluster itself issues (a Kubernetes ServiceAccount projected token), and the cloud's IAM system exchanges that token for a scoped, minutes-lived cloud credential via OIDC federation. No secret ever sits at rest. This is the same trust model SPIFFE/SPIRE formalizes for service-to-service auth, applied specifically to the pod-to-cloud-API boundary.

In production this shows up as three concrete mechanisms you'll be asked to choose between and migrate across:

  • IRSA (IAM Roles for Service Accounts) — AWS's original EKS OIDC-federation implementation, live since 2019.
  • EKS Pod Identity — AWS's newer, EKS-native replacement for IRSA, GA since late 2023, now the default recommendation on current EKS versions.
  • Azure Workload Identity (Entra Workload ID) — AKS's OIDC-federation equivalent, the successor to the deprecated AAD Pod Identity project.

Enterprises running fleets across AWS and Azure (or migrating between them) need to understand all three, because the failure modes — overly broad trust policies, token audience confusion, cross-account privilege escalation — are structurally identical even though the plumbing differs.

2. Real Business Problem

Scenario: A fintech platform runs 40 EKS clusters across 3 AWS accounts (dev/stage/prod) and 12 AKS clusters in Azure for a data-residency-driven EU workload. A security audit ahead of a SOC 2 Type II renewal flags:

  1. 380 IAM roles trusting the same EKS OIDC provider across multiple clusters, several with Resource: "*" in S3 policies because "it was faster to ship."
  2. A default ServiceAccount in a shared data-processing namespace annotated with an IRSA role that has sts:AssumeRole rights into a production billing account — nobody remembers why.
  3. On the AKS side, three workloads still using the deprecated AAD Pod Identity, which stopped receiving security patches and depends on a cluster-wide NMI DaemonSet running as privileged, intercepting IMDS traffic — a textbook lateral-movement vector once a single pod on that node is popped.
  4. No token audience or subject-claim scoping: several federated identity credentials use a wildcard subject (system:serviceaccount:*:*) instead of pinning namespace:serviceaccount-name, meaning any pod in the cluster that can create a ServiceAccount with a matching name inherits the trust.

The business risk isn't hypothetical — this is the exact shape of the 2023–2025 wave of Kubernetes-to-cloud lateral movement incidents: attacker lands via an exposed app, finds an over-permissioned or wildcard-scoped service account, mints a cloud credential through the legitimate federation path (so it doesn't look like key theft), and walks laterally into IAM, S3, or Secrets Manager. Security tooling that watches for "leaked static keys" doesn't catch this, because no key was ever leaked — the trust boundary itself was too wide.

The mandate: redesign workload identity across both clouds around least privilege, per-workload trust binding, provable non-reusability of tokens across namespaces/clusters, and a path to eliminate every long-lived credential and privileged identity DaemonSet in the fleet — without a big-bang migration that breaks 400+ production workloads.

3. Production Architecture

Architecture: Multi-cloud workload identity federation for EKS and AKS

The target architecture standardizes on OIDC federation with per-workload, per-namespace trust scoping, structured as three trust domains that mirror each other conceptually across clouds:

AWS side (per EKS cluster):

  • Each cluster's OIDC issuer (IRSA path) or the shared EKS Auth API (Pod Identity path) is the identity provider.
  • New workloads default to EKS Pod Identity: an EksPodIdentityAssociation binds (cluster, namespace, service-account) directly to an IAM role — no OIDC trust policy per role, no per-cluster provider registration, and the association itself lives in AWS, auditable via CloudTrail independent of cluster RBAC.
  • Legacy IRSA workloads (Fargate profiles, Windows nodes, EKS Anywhere hybrid nodes — where Pod Identity's node-agent model doesn't apply) keep IRSA, but every trust policy is tightened to StringEquals on the exact namespace:serviceaccount subject and aud=sts.amazonaws.com, never a wildcard.
  • IAM roles are scoped per workload-function (one role per microservice's actual AWS footprint), not per team or per cluster.

Azure side (per AKS cluster):

  • AKS OIDC issuer enabled per cluster; each workload's ServiceAccount is annotated with azure.workload.identity/client-id pointing to a dedicated User-Assigned Managed Identity.
  • A Federated Identity Credential binds (AKS OIDC issuer URL, namespace, service account name) to the managed identity — the Azure equivalent of IRSA's trust policy, with the same "pin the exact subject" discipline.
  • AAD Pod Identity is fully decommissioned; the privileged NMI DaemonSet is removed from every node pool as a hard security gate before the audit closes.

Cross-cutting control plane:

  • A policy-as-code gate (Kyverno ClusterPolicy on AWS side validating EksPodIdentityAssociation naming, OPA/Gatekeeper on the admission path for pod-spec serviceAccountName requirements) blocks any pod from mounting the default ServiceAccount's token in namespaces that touch cloud APIs — automountServiceAccountToken: false at the namespace default, opt-in per workload.
  • Short-lived tokens everywhere: projected ServiceAccount tokens have a default TTL of 15 minutes (expirationSeconds), forcing continuous re-federation rather than a token that's valid for the pod's entire lifetime.
  • Central inventory: a scheduled job queries AWS IAM (list-role-policies + trust policy parsing) and Azure Graph API (federated credential enumeration) nightly, diffing against a declarative manifest of "expected" identity bindings and alerting Security on drift — this is the control that would have caught the wildcard subject and the orphaned billing-account role.

Security boundaries: the blast radius of a compromised pod is now bounded by (a) the specific IAM role/managed identity tied to its exact namespace+SA, (b) a 15-minute credential lifetime, and (c) no privileged host-level identity broker to attack. Cross-account and cross-cloud access still goes through the same federation primitive, never a copied static key.

HA/DR and multi-region: OIDC issuers and federated credential bindings are regional metadata, not workload state — DR runbooks re-point workloads at a standby cluster's Pod Identity associations / Federated Identity Credentials as part of cluster bootstrap (via the same GitOps manifests, since the identity binding is just another Kubernetes/cloud resource), not a manual credential rotation exercise. This is the biggest operational win over static keys: identity failover is declarative, not a break-glass secrets rotation.

Trade-off as this scales: Pod Identity's EKS Auth API model removes per-cluster OIDC provider sprawl but adds a hard dependency on the Pod Identity Agent DaemonSet being healthy on every node — treat its health as a Tier-0 SLI, because if it's down, every pod using Pod Identity loses AWS access simultaneously (unlike IRSA, which has no node-local agent in the credential path).

4. Solution Design

Decision: EKS Pod Identity as default for new AWS workloads, IRSA retained only where structurally required. Pod Identity removes the OIDC-provider-per-cluster coupling (a role's trust policy no longer hardcodes a cluster's issuer URL), which directly solves the "380 roles trust the same provider, nobody can tell which cluster owns which" audit finding, and it exposes associations as first-class, listable AWS API objects instead of trust-policy JSON that has to be parsed to reason about. The cost: Fargate, Windows nodes, and EKS Anywhere don't support the node-agent model yet, so IRSA isn't going away, just shrinking to where it's necessary.

Alternative considered — IAM Roles Anywhere / static keys via Secrets Manager rotation: rejected. Rotation-based static credentials still have a window of validity longer than a single request and require a rotation Lambda/side-process that's itself an attack surface and an operational dependency. OIDC federation has no credential at rest to rotate.

Alternative considered — SPIFFE/SPIRE as the universal identity layer instead of cloud-native federation: genuinely attractive for the multi-cloud consistency it buys (one workload identity model, SVIDs everywhere, cloud IAM federates to SPIRE instead of directly to each cluster's OIDC issuer). Deferred, not rejected — it's the natural next step once per-cloud federation is clean, because SPIRE adds a control plane component (server + agents) that itself needs hardening and HA, and the team correctly prioritized closing the audit findings with native mechanisms first. Revisit at the point where a third cloud or on-prem workloads join the fleet.

Scalability: both IRSA and Pod Identity scale to thousands of roles/associations without a shared bottleneck (STS and the EKS Auth API are AWS-managed and horizontally scaled); Azure Workload Identity's federated credential quota (20 per managed identity) matters at scale — the design uses one managed identity per workload, not one shared per namespace, specifically to avoid hitting that ceiling.

Cost: federation itself is free; the cost delta versus static keys is operational tooling (the drift-detection job, policy gates) rather than cloud spend. Pod Identity's node agent has negligible resource footprint (<10m CPU, <32Mi memory per node).

Security implications: eliminating the AAD Pod Identity NMI DaemonSet removes a privileged, IMDS-intercepting process from every node — this alone closes the highest-severity finding, since privilege escalation via IMDS spoofing was the exact class of AKS vulnerability disclosed in 2024–2025 research. Pinning subject claims to exact namespace+ServiceAccount closes the wildcard-trust finding. Short token TTLs bound the exploitation window of a stolen projected token.

Performance: token exchange adds one extra network round-trip (STS AssumeRoleWithWebIdentity or Entra token endpoint) on cold start, typically 20–80ms, cached by the AWS/Azure SDK credential provider for the token's lifetime — negligible against typical pod startup and request latencies, but worth accounting for in cold-start-sensitive Lambda-adjacent or scale-to-zero KEDA workloads.

5. Deep Technical Walkthrough

IRSA request flow:

  1. Kubelet projects a ServiceAccount token (JWT) into the pod, signed by the cluster's service account signing key, audience sts.amazonaws.com, TTL configurable (default historically 1 hour, hardened here to 15 minutes).
  2. The AWS SDK, seeing AWS_WEB_IDENTITY_TOKEN_FILE and AWS_ROLE_ARN env vars (injected by the EKS Pod Identity webhook), calls sts:AssumeRoleWithWebIdentity with the JWT.
  3. STS validates the JWT signature against the cluster's OIDC issuer's public keys, published at the cluster's OIDC discovery endpoint (an S3-hosted or EKS-managed .well-known/openid-configuration).
  4. STS checks the IAM role's trust policy: does the JWT's sub claim (system:serviceaccount:<ns>:<sa>) and aud match a Condition in the trust policy? If yes, STS mints temporary credentials (default 1 hour, capped by role's max session duration).
  5. Credentials cached by the SDK in-process until near expiry, then re-exchanged transparently.

Pod Identity request flow (the structural difference):

  1. Pod Identity Agent (a DaemonSet, not the SDK directly) intercepts the credential request via a link-local address (169.254.170.23), mimicking the ECS/IMDS credential-provider pattern the AWS SDKs already know how to speak.
  2. The agent presents the pod's projected ServiceAccount token to the EKS Auth API (eks-auth:AssumeRoleForPodIdentity), a control-plane API — not STS directly, and not validated against a customer-managed OIDC provider.
  3. EKS Auth API checks the EksPodIdentityAssociation object (cluster + namespace + service account → role ARN) and internally calls STS on the workload's behalf.
  4. No OIDC provider registration step, no trust-policy JSON to hand-author with the correct Condition block — the association is the trust policy, managed as an EKS API object.

Azure Workload Identity flow:

  1. AKS's OIDC issuer (enabled per cluster) publishes discovery docs the same way EKS's does.
  2. The Azure Workload Identity mutating webhook (installed as part of the AKS add-on) injects AZURE_CLIENT_ID, AZURE_TENANT_ID, AZURE_FEDERATED_TOKEN_FILE into pods whose ServiceAccount carries the azure.workload.identity/use: "true" label.
  3. The Azure Identity SDK exchanges the projected token at Entra ID's token endpoint, presenting the Federated Identity Credential binding (issuer + subject + audience api://AzureADTokenExchange) as proof.
  4. Entra issues an access token scoped to the managed identity's role assignments — no client secret ever exists for this identity.

Failure scenarios and recovery:

  • Pod Identity Agent DaemonSet crash-loops on a node: every pod on that node loses new AWS credential issuance; existing cached SDK credentials keep working until expiry (up to the session TTL), then start failing with AccessDenied/timeout. Recovery: DaemonSet health must page on-call before the cache window elapses — treat agent readiness as gating node schedulability for identity-dependent workloads.
  • OIDC discovery endpoint unreachable (IRSA): STS can't validate new tokens; existing STS-issued credentials remain valid until their own expiry. This is why the S3 bucket hosting a self-managed OIDC discovery doc needs the same availability SLO as the control plane itself.
  • Federated Identity Credential propagation delay (Azure): newly created bindings take up to a few seconds to minutes to propagate; a pod scheduled immediately after creating the binding can hit transient AADSTS errors — the platform's Helm chart post-install hook includes a bounded retry/backoff specifically for this window.
  • Clock skew: JWT exp/nbf validation fails silently as "invalid token" with no clear signal it's a clock issue — NTP drift on nodes is a known root cause worth ruling out first during a federation outage.

6. Production Troubleshooting

Symptom: Pods in payments-prod intermittently return AccessDenied calling S3, correlated with node scale-up events.

Investigation, the way a senior SRE runs it:

# 1. Confirm which mechanism the pod is using
kubectl get pod payments-worker-7f9c -n payments-prod -o jsonpath='{.spec.serviceAccountName}'
kubectl get sa payments-sa -n payments-prod -o yaml | grep -A2 annotations

# 2. Check Pod Identity Agent health on the pod's node
kubectl get pods -n kube-system -l app.kubernetes.io/name=eks-pod-identity-agent -o wide | grep <node-name>
kubectl logs -n kube-system eks-pod-identity-agent-<id> --since=15m | grep -i error

# 3. Verify the association actually exists and matches
aws eks list-pod-identity-associations --cluster-name prod-payments \
  --namespace payments-prod --service-account payments-sa

# 4. Check IAM role trust + permissions boundary
aws iam get-role --role-name payments-s3-role --query 'Role.AssumeRolePolicyDocument'
aws iam simulate-principal-policy --policy-source-arn arn:aws:iam::123456789012:role/payments-s3-role \
  --action-names s3:GetObject --resource-arns arn:aws:s3:::payments-artifacts/*

# 5. Cross-reference CloudTrail for the actual denied call
aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=AssumeRoleForPodIdentity \
  --start-time "$(date -u -d '30 min ago' +%Y-%m-%dT%H:%M:%S)"

Root cause found: new nodes were being launched from a node pool whose launch template pre-dated the Pod Identity Agent's addition to the EKS-managed add-on baseline — the agent DaemonSet's nodeSelector excluded a custom workload-type label these nodes carried, so the agent never scheduled onto them. Pods landed, got a ServiceAccount token, but had no local agent to broker the exchange, and the SDK's fallback IMDS credential provider returned the node's own instance-profile role, not the workload's — which happened to lack S3 access, hence AccessDenied (and, worryingly, this fallback is itself a finding: it means a misconfigured agent silently downgrades to the node role rather than failing loudly).

Fix: correct the DaemonSet nodeSelector/tolerations to cover all node pools; add a Prometheus alert on kube_daemonset_status_number_ready / kube_daemonset_status_desired_number_scheduled < 1 for the agent DaemonSet specifically, and a Kyverno policy that blocks scheduling identity-dependent pods onto nodes lacking the agent's pod IP in NodeStatus.

Dashboards/metrics worth having permanently: STS AssumeRoleWithWebIdentity throttle rate (CloudWatch), Pod Identity Agent DaemonSet readiness ratio, Entra Microsoft.Insights sign-in logs filtered to workload identity sign-ins with failure reason, and a Grafana panel joining "pods with cloud SDK errors" (from app logs via Loki) against "identity binding changed in last 10 minutes" (from the drift-detection job's audit log) to catch binding-change-induced incidents fast.

7. Hands-on Lab

Goal: stand up EKS Pod Identity end-to-end on a real cluster, prove least-privilege scoping, then repeat conceptually on AKS.

# --- AWS: EKS Pod Identity ---
CLUSTER=lab-identity-demo
aws eks create-cluster --name $CLUSTER --role-arn arn:aws:iam::<acct>:role/eks-cluster-role \
  --resources-vpc-config subnetIds=<subnet-a>,<subnet-b>

# Install the Pod Identity Agent add-on
aws eks create-addon --cluster-name $CLUSTER --addon-name eks-pod-identity-agent

# Create a least-privilege role scoped to one bucket, no wildcards
cat <<'EOF' > policy.json
{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":["s3:GetObject"],
"Resource":"arn:aws:s3:::lab-identity-bucket/demo/*"}]}
EOF
aws iam create-role --role-name lab-pod-identity-role \
  --assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow",
  "Principal":{"Service":"pods.eks.amazonaws.com"},
  "Action":["sts:AssumeRole","sts:TagSession"]}]}'
aws iam put-role-policy --role-name lab-pod-identity-role --policy-name s3-read \
  --policy-document file://policy.json

# Bind namespace:serviceaccount to the role — no OIDC provider setup required
aws eks create-pod-identity-association --cluster-name $CLUSTER \
  --namespace demo --service-account demo-sa --role-arn arn:aws:iam::<acct>:role/lab-pod-identity-role

kubectl create ns demo
kubectl create serviceaccount demo-sa -n demo
kubectl run s3-test -n demo --image=amazon/aws-cli --serviceaccount=demo-sa -- \
  s3 cp s3://lab-identity-bucket/demo/file.txt /tmp/file.txt

# Validate: prove the SA CANNOT access an out-of-scope bucket
kubectl run s3-negative -n demo --image=amazon/aws-cli --serviceaccount=demo-sa -- \
  s3 ls s3://some-other-bucket/   # expect AccessDenied

# --- Azure: Workload Identity on AKS ---
RG=lab-identity-rg; AKS=lab-aks; ISSUER=$(az aks show -g $RG -n $AKS --query oidcIssuerProfile.issuerUrl -o tsv)

az identity create -g $RG -n lab-workload-identity
CLIENT_ID=$(az identity show -g $RG -n lab-workload-identity --query clientId -o tsv)

az identity federated-credential create --name lab-fic -g $RG \
  --identity-name lab-workload-identity --issuer $ISSUER \
  --subject system:serviceaccount:demo:demo-sa --audience api://AzureADTokenExchange

kubectl create serviceaccount demo-sa -n demo \
  --dry-run=client -o yaml | kubectl label -f - --local \
  azure.workload.identity/use=true -o yaml | \
  kubectl annotate -f - --local azure.workload.identity/client-id=$CLIENT_ID -o yaml | kubectl apply -f -

Validation: confirm AccessDenied on out-of-scope resources (proves least privilege, not just that federation works), tail Pod Identity Agent / webhook logs during the exchange, and check CloudTrail/Entra sign-in logs show the federated exchange, not a static key.

Cleanup: aws eks delete-pod-identity-association, aws iam delete-role, az identity federated-credential delete, az identity delete, kubectl delete ns demo, aws eks delete-cluster.

8. Production Case Study

Netflix's device and studio platforms have long publicized moving away from static IAM credentials toward short-lived, federated identity for exactly this reason — their engineering blog has repeatedly emphasized "credentials that expire" as a first-class security control, not an afterthought, because at their scale a single long-lived key leaking into a public repo or a compromised build artifact is a statistical certainty over enough time, not an edge case. Uber's internal platform work on service-to-service identity converged on a SPIFFE-like model for the same reason multi-cloud teams eventually will: once you have more than one trust domain (multiple clusters, multiple clouds, on-prem plus cloud), hand-authoring OIDC trust policies per role stops scaling and you want a uniform identity document (an SVID or equivalent) that every relying party — cloud IAM included — can federate against through one broker instead of N bespoke integrations.

AWS's own internal guidance (echoed in their public EKS best-practices documentation) for Pod Identity's design explicitly cites reducing OIDC-provider sprawl as the primary driver — a direct answer to the exact audit finding in this post's business problem, at a scale (many EKS clusters, one IAM boundary) common in large AWS-native shops. Microsoft's deprecation of AAD Pod Identity in favor of Workload Identity followed the identical logic Kubernetes upstream applied to Pod Security Policies: a privileged node-level broker (NMI) was replaceable by a stateless, OIDC-native mechanism with a smaller blast radius, and the ecosystem moved once the standards-based alternative matured.

9. Architecture Review

Strengths: no static credentials at rest anywhere in the fleet; blast radius of a compromised pod bounded to one workload's exact permission set for a 15-minute window; identity bindings are declarative, GitOps-manageable, and diffable, which is what makes the nightly drift-detection job effective; DR failover no longer requires manual credential rotation.

Weaknesses: Pod Identity introduces a new single point of per-node failure (the agent DaemonSet) that IRSA didn't have — the architecture trades "provider sprawl" for "node-agent liveness dependency." The two-cloud design also means two operationally distinct troubleshooting playbooks and two separate drift-detection integrations, which is real ongoing toil, not a one-time migration cost.

What breaks first at 10x scale: the nightly drift-detection job's runtime — enumerating federated credentials via Azure Graph API and IAM trust policies via list-roles/get-role across hundreds of accounts will start hitting API rate limits and taking hours instead of minutes; it needs to become event-driven (CloudTrail/EventBridge on IAM changes, Azure Activity Log on identity changes) rather than a nightly full scan well before 10x.

At 100M users / hyperscale: the EKS Auth API and Entra's token endpoint are AWS/Microsoft-managed and already operate at that scale, so the federation primitive itself isn't the bottleneck — the bottleneck becomes governance: who can create a Pod Identity association or Federated Identity Credential becomes as sensitive an operation as creating the IAM role itself, and needs the same PR-review-and-policy-gate treatment, or the wildcard-subject problem simply reappears at greater scale, faster, because self-service platforms make it easier to create bindings than to review them.

What to redesign: move to a SPIFFE/SPIRE-fronted model where cloud IAM trusts one SPIRE-issued root (or a small number of trust domains) instead of federating directly against each cluster's OIDC issuer — this collapses the "two distinct per-cloud playbooks" weakness into one identity model with cloud-specific plugins, and is the natural next architecture once a third cloud or significant on-prem footprint enters the picture.

10. Best Practices

Reliability comes from treating the credential-issuing path (Pod Identity Agent, OIDC discovery endpoint, Entra token endpoint reachability) as Tier-0 infrastructure with its own SLOs and paging alerts, not as "just auth plumbing." Scalability means one IAM role or managed identity per workload function, never per team or per cluster, and event-driven drift detection instead of full periodic scans once the fleet crosses a few hundred bindings. Observability requires correlating CloudTrail/Entra sign-in logs with Kubernetes admission events for ServiceAccount and association/credential changes, so an incident review can answer "was this identity binding created five minutes before the breach" in one query. Security is subject-claim pinning by default (namespace:serviceaccount:* wildcards forbidden by policy gate), automountServiceAccountToken: false unless explicitly opted in, and short token TTLs everywhere. Cost optimization is mostly about avoiding shared, over-scoped identities that force broader-than-needed IAM policies just to cover multiple tenants — narrow scope is usually also the cheaper blast-radius outcome, not a separate spend lever here. Maintainability means the identity binding lives next to the workload's manifest in the same GitOps repo, reviewed in the same PR, not managed out-of-band by a platform team that becomes a bottleneck. Operational excellence is the nightly (soon event-driven) drift report with a named owner and an SLA to remediate findings, not a report nobody reads.

11. Common Production Mistakes

Wildcard subject claims (system:serviceaccount:*:* or a namespace-only wildcard) are the single most common and most dangerous mistake, because they silently convert a scoped trust relationship into an ambient one that any workload in the wrong namespace can inherit by creating a matching ServiceAccount name. Sharing one IAM role or managed identity across many workloads "to save time" defeats least privilege and makes CloudTrail/audit-log forensics far harder, since every action attributed to that identity could be any one of N workloads. Leaving deprecated brokers like AAD Pod Identity running because "nothing's broken" ignores that unpatched, privileged, IMDS-intercepting DaemonSets are exactly the kind of thing that turns a minor app compromise into a cluster-wide credential-theft incident. Long token TTLs (the historical 1-hour default) extend the exploitation window of a stolen projected token far beyond what most workloads actually need — 15 minutes or less should be the default, tuned up only where cold-start cost genuinely requires it. Finally, treating identity bindings as infrastructure-team-only knowledge instead of GitOps-managed, PR-reviewed artifacts means the people best positioned to catch an over-broad grant (the workload's own developers, in code review) never see it.

12. Interview Preparation

Q: Explain the structural difference between IRSA and EKS Pod Identity in terms of trust establishment. A: IRSA relies on a customer-registered OIDC identity provider per cluster, with each IAM role's trust policy hardcoding that provider's issuer URL and a Condition matching the ServiceAccount's sub/aud claims — the role is coupled to one cluster. Pod Identity replaces that with an EKS-managed control-plane API (eks-auth) and a first-class EksPodIdentityAssociation object binding cluster+namespace+ServiceAccount to a role, with a DaemonSet agent brokering the STS exchange — no per-cluster OIDC provider registration, and roles aren't coupled to a specific cluster's issuer.

Q: Why is a wildcard subject claim in a federated trust policy dangerous, and how do you prevent it structurally rather than just by review? A: A wildcard subject means any ServiceAccount matching the pattern — potentially creatable by any user with namespace-create or ServiceAccount-create RBAC — inherits the trust, turning a scoped binding into an ambient one. Prevent it structurally with an admission policy (Kyverno/OPA) that validates every new IAM trust policy or Federated Identity Credential against an exact-match subject before it's allowed to apply, rather than relying on manual review to catch it after the fact.

Q: A pod's cloud SDK calls intermittently return AccessDenied only on newly scaled nodes. Walk through your diagnostic approach. A: Confirm which federation mechanism the pod uses; check whether the credential-broker component (Pod Identity Agent DaemonSet / Azure Workload Identity webhook) is actually scheduled and healthy on that specific node via label/taint matching; check whether the SDK is silently falling back to a node-level identity (instance profile / VM managed identity) rather than the workload identity, which explains why permissions look wrong rather than the call simply failing outright; cross-reference CloudTrail/Entra logs for the actual principal used in the denied call to confirm the hypothesis before touching any IAM policy.

Q: When would you deliberately choose SPIFFE/SPIRE over native cloud OIDC federation for workload identity? A: When the fleet spans more trust domains than "per-cluster cloud IAM" can reasonably cover — multiple clouds plus on-prem, or a service-mesh-wide mTLS identity requirement that needs to extend beyond just cloud API calls to service-to-service auth generally. SPIRE centralizes issuance behind one attested identity document (SVID) that cloud IAM, service mesh, and internal auth can all federate against, trading the operational cost of running SPIRE's own control plane for consistency across N trust domains instead of N bespoke integrations.

Q: What's the operational risk introduced by EKS Pod Identity that didn't exist with IRSA, and how do you mitigate it? A: The Pod Identity Agent DaemonSet becomes a per-node dependency in the credential path — if it's unscheduled or unhealthy on a node, every pod there loses new credential issuance, which is a failure mode IRSA (no node-local agent) didn't have. Mitigate by monitoring DaemonSet readiness ratio as a Tier-0 SLI, gating node schedulability for identity-dependent workloads on agent presence, and alerting before cached credentials on that node expire.

13. Latest Industry Updates

AWS's guidance through 2026 continues to position EKS Pod Identity as the default for new workloads on standard EC2-backed clusters, with IRSA explicitly retained (not deprecated) for Fargate, Windows nodes, and EKS Anywhere hybrid topologies where the node-agent model doesn't apply — both mechanisms remain fully supported on current EKS versions, so this is an incremental-adoption story, not a forced migration (Rafay: Pod Identity vs IRSA, AWS Builder Center: Rethinking Workload Identity). On Azure, 2026 documentation continues emphasizing Workload Identity as the sole recommended path (AAD Pod Identity is deprecated), with recent guidance covering federating AKS's OIDC issuer against external OIDC providers as well as Entra — relevant for hybrid and multi-cloud identity brokering — and reiterating the 20-federated-credential-per-managed-identity quota as a real design constraint at scale (Microsoft Learn: Workload ID on AKS, OneUptime: AKS Workload Identity Federation). On the threat side, 2025–2026 research kept surfacing Kubernetes identity misconfiguration — over-permissioned service accounts, exposed API servers with default-service-account cluster-admin, and CI-runner credential harvesting (the SANDCLOCK stealer targeting Kubernetes tokens and cloud credentials from build pipelines) — as the dominant lateral-movement path into cloud accounts, reinforcing that the federation mechanism matters less than the discipline of scoping it tightly (NHI Mgmt Group: K8s identity and runtime control, BlogWolf: Kubernetes Security News 2026).

14. Summary & Cheat Sheet

Workload identity federation replaces static cloud credentials with short-lived tokens exchanged via OIDC: a Kubernetes ServiceAccount's projected JWT proves identity, cloud IAM validates it against a scoped trust binding, and mints a temporary credential. AWS offers two mechanisms — IRSA (per-cluster OIDC provider + trust-policy JSON, required for Fargate/Windows/hybrid) and EKS Pod Identity (EKS-native association object, DaemonSet-brokered, default for new standard-node workloads) — while Azure's single current mechanism is Workload Identity (Federated Identity Credential binding a managed identity to an AKS OIDC subject, superseding the deprecated, privileged AAD Pod Identity).

Key architecture decisions: one IAM role/managed identity per workload function, never shared; exact-match subject claims, never wildcards, enforced by admission policy, not just review; short token TTLs (15 minutes as a strong default); Pod Identity Agent / Workload Identity webhook health treated as Tier-0; identity bindings managed as GitOps-reviewed manifests co-located with workload code.

Troubleshooting checklist: confirm the federation mechanism and check the broker component's health on the specific node before touching IAM; watch for silent fallback to node-level/VM-level identity as a symptom of a missing broker, not a permissions bug; correlate CloudTrail/Entra sign-in logs against Kubernetes admission events for binding changes; rule out clock skew on unexplained token-validation failures.

Interview and design-review anchor points: know the structural difference between IRSA's per-cluster OIDC trust policy and Pod Identity's control-plane association object; be able to explain why wildcard subject claims are a privilege-escalation vector and how to gate against them structurally; understand when SPIFFE/SPIRE earns its operational cost over native per-cloud federation — namely, once trust domains multiply beyond what per-cluster cloud IAM integration can cleanly cover.