An IAM role must already exist whose trust policy names the cluster OIDC provider and conditions on sub system:serviceaccount:<namespace>:<name> plus aud sts.amazonaws.com
The IAM role trusts the cluster OIDC provider and evaluates whatever token claims its trust policy names, most commonly the subject and the audience
Those conditions are policy specific rather than built into IRSA, and the ServiceAccount annotation takes no part in the authorization decision
A pod running under that ServiceAccount, projecting a serviceAccountToken with audience sts.amazonaws.com, receives an assertion STS accepts
AssumeRoleWithWebIdentity is unauthenticated, so the exchange needs no AWS credentials and returns whatever the role itself grants
create serviceaccounts/token mints the same assertion with no pod involved, and the credentials work from outside the cluster
The eks.amazonaws.com/role-arn annotation only drives the pod-identity-webhook, which injects at admission and so never reaches running pods
That annotation is also the discovery path, since it names the role and the ServiceAccount it trusts, and reading it needs only list serviceaccounts
Rights needed, any one set:
· any one; running a pod under the bound ServiceAccount claims the role, and setting serviceAccountName needs no permission on the object
· any one; mints the assertion directly, with no pod and no node
· scoped to a trust policy whose subject names a ServiceAccount that does not exist yet
· squatting the bound name, then running under it
· scoped to using the webhook rather than a hand-built projection
· patch alone is not enough on EKS, since injection happens at pod admission
Note:
Not a defect and nothing to patch.
The IAM trust policy is the anchor, so an audit that looks only for the eks.amazonaws.com/role-arn annotation misses every variant that bypasses the webhook.