EKS Pod Identity swaps per-cluster OIDC trust for one service principal shared by every role

The trust policy JSON shows the difference most clearly. The guide's IRSA example is a single statement, and it names the cluster's OIDC provider ID three times: in the Federated principal ARN, in the sub condition key and in the aud condition key ^[15][1]. The sub value pins the role to one service account, system:serviceaccount:my-namespace:my-service-account ^[15]. Reusing a role across clusters means repeating that for each provider. The author calls it "juggling OIDC provider ARNs per cluster" ^[17]. Pod Identity removes the provider as something to "create, rotate certificates for, and keep in sync across clusters" ^[5].

The Pod Identity statement in the same guide is shorter. It allows sts:AssumeRole and sts:TagSession for the service principal pods.eks.amazonaws.com, and it has no Condition block ^[9]. Nothing in it identifies a cluster, a namespace or a service account ^[2]. That binding lives in the PodIdentityAssociation, one per triple, created with `aws eks create-pod-identity-association` ^[4][16]. For audit, I think this is the right tradeoff. Every role has the same trust shape, and the author notes that policy-as-code checks stop diffing sub/aud conditions role by role ^[6]. The cost is that a reviewer reading the IAM policy alone cannot tell which workload may assume the role. The association list holds that answer ^[2].

The credential path changes as well. Under IRSA, a mutating webhook injects a projected OIDC token, and the SDK exchanges it through sts:AssumeRoleWithWebIdentity ^[3]. Under Pod Identity, an agent daemonset on each node gets the credentials ^[4].

The guide's cutover runs in order:

1. Enable the Pod Identity Agent add-on through the console, eksctl or Terraform's aws_eks_addon ^[14]. 2. Add the pods.eks.amazonaws.com statement to each role next to the existing OIDC statement ^[8]. 3. Create the association for each cluster, namespace and service account ^[4]. 4. Confirm the new path in CloudTrail's userIdentity field or in application logs ^[10]. 5. Remove the eks.amazonaws.com/role-arn annotation only after that check passes ^[11].

If I could keep only one of these steps, it would be step four. "Don't trust that the association exists in the console," the author wrote ^[10]. What counts as proof is CloudTrail or log evidence that the pod is assuming the role through the new path ^[10]. The author also recommends keeping both trusts for at least one deploy cycle per workload. "It costs nothing and gives you an instant rollback if something's wrong," the author wrote ^[12].

The guide's headline promise is five gotchas the author hit that "aren't covered in the official docs" ^[13]. The copy of the guide on record stops partway through its Terraform association example, before any of the five appears ^[13]. So the claim that the migration hides failures the documentation misses comes from one author. None of the five can be checked against this text.