EKS Pod Identity vs IRSA. I moved one cluster to find out.

I have been an IRSA defender for years — wrote up the whole setup earlier this year and meant it. But the honest cost of IRSA was never the setup. It was the bookkeeping: an OIDC provider per cluster, a trust policy per role keyed to that cluster’s provider, an annotation per service account, and three places where a typo becomes an AccessDenied at runtime instead of a validation error at deploy time. When the third cluster in the account needed the same role, I ran the experiment. One weekend, one cluster, moved to Pod Identity.

What Pod Identity actually changes

IRSA solves “let this pod assume this role” with standard building blocks: the cluster’s OIDC provider is registered in IAM, the role’s trust policy names that provider and matches the service account in the sub claim, and a webhook projects a token into the pod. It is elegant and completely cluster-scoped — every new cluster repeats all three steps.

EKS Pod Identity moves the mapping into the EKS control plane. You install the Pod Identity agent add-on, then create an association — a cluster, a namespace, a service account name, a role — through the EKS API. The trust policy becomes a one-liner naming pods.eks.amazonaws.com as principal with a condition on the cluster name, and that condition accepts wildcards, so one role can serve ten clusters without ten trust policy edits. The pod gets credentials from the agent on a link-local address instead of exchanging a token with STS itself. No annotation on the service account at all.

The actual differences

• Multi-cluster reuse. This is the headline. With IRSA, each cluster’s OIDC provider needs its own condition block in the trust policy. With Pod Identity, StringLike on eks-authn:cluster-name covers the fleet. Whether a role should serve a fleet is your decision — the point is that IRSA makes the default narrow and Pod Identity makes it one wildcard away.
• Decoupling from Kubernetes objects. The association lives in the EKS API, not in an annotation, so the role assignment survives SA renames in manifests, applies to SAs created by charts you do not own, and can be granted (and revoked) without touching the repo.
• Cross-account. Both can reach other accounts — IRSA by trusting the web identity from the target role, Pod Identity by chaining through the association role. The chaining route is more wiring but keeps the cluster account’s roles thin.
• Cold start. The agent holds and refreshes credentials, so pods read them from a local endpoint rather than doing a web identity exchange on boot. Faster pod start, fewer STS calls at scale, one less token rotation in your logs.
• Client requirements. The local-endpoint credential provider needs reasonably modern AWS SDKs. Anything constructing credential chains by hand — some vendored SDKs, some legacy jobs — needed a dependency bump during the migration. IRSA’s projected-token flow works with older clients.

The honest trade-offs

• Pod Identity is EKS-only, by construction. IRSA is a webhook and an OIDC provider, so it runs anywhere Kubernetes runs — other clouds, self-managed clusters, the OpenShift box someone insists on. A tool that must work everywhere stays on IRSA.
• The agent is a new moving part on every node. It is a first-party add-on with its own lifecycle, and when a pod cannot get credentials the debugging starts at the EKS API and the agent logs instead of the IAM policy simulator. New muscle memory required.
• Wildcards cut both ways. cluster-name matching * in a trust policy is fleet-wide convenience and fleet-wide blast radius. Scope it to a pattern, not the universe.
• Launch-era gaps (Fargate, Windows nodes) have been closing release by release — check the current compatibility table before planning the migration, not after.
• Association counts and agent versions are quotas and changelogs to track now. Small ones. Non-zero ones.

Where I landed

New clusters start on Pod Identity. The multi-cluster role reuse alone repaid the migration, and deleting three OIDC providers from the account was its own small pleasure. IRSA keeps the workloads that live outside EKS proper, the ones pinned to old SDKs, and any platform where an EKS add-on cannot follow. Both arrangements beat the static keys that were in the account before either of them, which is the comparison that actually shows up in incident reviews.