Amazon EKS offers two AWS-side mechanisms for giving a pod its own IAM role: IAM Roles for Service Accounts (IRSA) and EKS Pod Identity. How do they differ operationally, and how would you choose between them?

## The problem both mechanisms solve A workload in an EKS cluster needs to call an AWS API — read an S3 object, publish to SNS, decrypt with KMS. The bad answers are a static access key in a Secret, or attaching a broad role to the node so that *every* pod on that node inherits it through the instance metadata service. AWS's answer is to give each workload identity its own IAM role with short-lived credentials. There are two implementations, and interviewers ask about the difference because both exist in the wild and the migration is a live topic. ## IRSA: federate the cluster's issuer into IAM Every EKS cluster publishes an OIDC issuer URL and serves signed service-account tokens. IRSA works by registering that issuer as an IAM OIDC identity provider in your account, then writing role trust policies that accept a token from it: ```json { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.eu-west-1.amazonaws.com/id/EXAMPLE" }, "Action": "sts:AssumeRoleWithWebIdentity" } ``` The critical part is the condition block. Without a condition on the `sub` claim — which carries the value `system:serviceaccount:<namespace>:<name>` — *any* service account in the cluster could assume the role. A condition on `aud` (`sts.amazonaws.com`) belongs there too. Annotate the service account with `eks.amazonaws.com/role-arn`, and an admission webhook injects `AWS_ROLE_ARN` and `AWS_WEB_IDENTITY_TOKEN_FILE` into the pod; the AWS SDKs read the projected token from that path and call STS themselves. Credentials are short-lived and the token is refreshed by the kubelet. IRSA's operational cost is that identity is anchored to *the cluster's issuer URL*. A role usable from two clusters needs both issuers in its trust policy. Rebuild a cluster and the issuer changes, so every role trusting it must be edited. At a hundred roles across a dozen clusters, the trust policies become the thing that breaks. ## EKS Pod Identity: move the mapping into the EKS API Pod Identity, added at the end of 2023, inverts the arrangement. The role's trust policy names an AWS service principal once and never changes: ```json { "Effect": "Allow", "Principal": { "Service": "pods.eks.amazonaws.com" }, "Action": ["sts:AssumeRole", "sts:TagSession"] } ``` The cluster/namespace/service-account binding lives in an EKS *pod identity association* created with `aws eks create-pod-identity-association`. The Pod Identity Agent, installed as an EKS add-on, runs on each node and serves credentials over a link-local endpoint that the SDKs discover through `AWS_CONTAINER_CREDENTIALS_FULL_URI`. No OIDC provider per cluster, no trust-policy edit when a cluster is rebuilt, no service-account annotation carrying an account-specific ARN — which also means the same manifests deploy unchanged to dev and prod. Note `sts:TagSession` in the trust policy: Pod Identity attaches session tags for the cluster, namespace and service account, which you can use in policy conditions. ## How to choose - **Fargate pods: IRSA.** The Pod Identity Agent is a node-level DaemonSet, and Fargate pods run no DaemonSets, so Pod Identity does not apply there. - **Many clusters, many roles, clusters that get rebuilt: Pod Identity.** This is the case it was built for; the trust policy stops being per-cluster state. - **Anything outside EKS — self-managed Kubernetes, another cloud, an on-prem cluster federating into AWS: OIDC federation only.** Pod Identity is an EKS API and does not exist elsewhere. - **Existing IRSA that works: leave it.** Both mechanisms coexist in one cluster, and per-service migration is safe. If a service account has both, the Pod Identity association takes precedence. ## The failure modes worth naming An IRSA trust policy with no `sub` condition is a real privilege-escalation path — any pod in the cluster can mint that role. An SDK too old to understand the web-identity or container-credentials providers silently falls back to the node role and "works" with the wrong identity, which is worse than failing. And a pod that never gets credentials at all is usually a missing annotation, a missing association, or the Pod Identity Agent add-on not being installed on that node. What neither mechanism changes: the role's *permissions* are still an ordinary IAM policy problem, and the scoping discipline is the same one you would apply anywhere else.