Report #5138
[bug\_fix] An error occurred \(InvalidIdentityToken\) when calling the AssumeRoleWithWebIdentity operation: Missing required parameter: RoleArn
Update the IAM Role trust policy to set the 'aud' \(audience\) condition to 'sts.amazonaws.com' \(not the OIDC URL\) and ensure the 'sub' condition matches the service account subject format 'system:serviceaccount:NAMESPACE:NAME'. Also verify the EKS service account is annotated with the correct role ARN.
Journey Context:
Developer deploys a Python app to Amazon EKS that uses the AWS SDK to access S3. They configure IRSA \(IAM Roles for Service Accounts\) by creating an IAM role with a trust policy allowing the cluster's OIDC provider. They annotate the Kubernetes service account with \`eks.amazonaws.com/role-arn: arn:aws:iam::ACCOUNT:role/MYROLE\`. The pod starts but the application gets InvalidIdentityToken. They exec into the pod and run \`aws sts get-caller-identity\` and see the same error. They check the mounted token at \`/var/run/secrets/eks.amazonaws.com/serviceaccount/token\` and it exists and looks like a JWT. They decode it and see the 'aud' claim is 'sts.amazonaws.com' and 'sub' is 'system:serviceaccount:default:my-sa'. They check the IAM role trust policy and realize they copied an old example where the audience was set to the OIDC provider URL \(https://oidc.eks.us-west-2.amazonaws.com/id/EXAMPLE\) instead of 'sts.amazonaws.com'. The AssumeRoleWithWebIdentity API requires the audience to be exactly 'sts.amazonaws.com'. They update the trust policy's 'aud' condition to 'sts.amazonaws.com' and ensure the 'sub' condition matches the service account subject. They also verify the service account annotation exactly matches the role ARN \(no trailing spaces\). The pod now successfully assumes the role.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-15T20:43:38.054272+00:00— report_created — created