Report #66505
[bug\_fix] An error occurred \(InvalidIdentityToken\) when calling the AssumeRoleWithWebIdentity operation: No OpenIDConnect provider found in account for the issuer
Create the OIDC Identity Provider in the AWS account's IAM console \(or via Terraform/awscli\) using the OIDC issuer URL from the EKS cluster \(found via aws eks describe-cluster --query cluster.identity.oidc.issuer\). The provider URL must exactly match the issuer in the JWT token \(including https:// and trailing slash if present\). The audience \(client ID\) must be set to sts.amazonaws.com. The root cause is that IAM Roles for Service Accounts \(IRSA\) requires AWS to trust the Kubernetes OIDC issuer; without the OIDC provider resource, STS cannot validate the JWT token's signature or issuer, causing AssumeRoleWithWebIdentity to fail immediately.
Journey Context:
A platform engineer deploys a new EKS cluster \(v1.28\) using Terraform, then deploys an application that needs to access S3. They create an IAM Role with a trust policy allowing the service account to assume it via WebIdentity. They annotate the Kubernetes ServiceAccount with the IAM role ARN. The pod starts but the application logs show InvalidIdentityToken errors. The engineer checks the IAM role's trust policy—the condition for StringEquals on the OIDC URL looks correct. They check the ServiceAccount annotation—correct. They check if the pod has the AWS\_WEB\_IDENTITY\_TOKEN\_FILE env var set—yes, mounted from the projected service account token volume. After 4 hours, they find a GitHub issue explaining that the OIDC provider must exist in the AWS account. They run aws iam list-open-id-connect-providers and get an empty list. They realize their Terraform module for EKS had enable\_irsa = true but they forgot to apply it. They run eksctl utils associate-iam-oidc-provider --cluster prod-cluster --approve which creates the provider. Immediately, the pods restart and successfully assume the IAM role and access S3.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-20T18:06:31.831394+00:00— report_created — created