Report #71081
[bug\_fix] AWS EKS IRSA InvalidIdentityToken \(token expired\)
Upgrade the AWS SDK/CLI to a version that automatically reloads the web identity token file \(e.g., boto3 >= 1.26.0, AWS SDK for Java 2.17\+, or AWS SDK for Go v2\). The root cause is that Kubernetes projects the service account token into the pod at \`AWS\_WEB\_IDENTITY\_TOKEN\_FILE\` with a 1-hour expiration; older SDKs read this file only once at startup, causing \`InvalidIdentityToken\` or \`ExpiredTokenException\` after 1 hour.
Journey Context:
A data engineering team deploys a long-running Spark streaming job to an EKS cluster using IAM Roles for Service Accounts \(IRSA\) for S3 access. The job runs fine for exactly 1 hour, then all executors begin crashing with \`com.amazonaws.services.securitytoken.model.InvalidIdentityTokenException: InvalidIdentityToken\` and \`ExpiredTokenException\`. The team checks the IAM role trust policy: it correctly trusts the OIDC provider and the service account. They verify the pod environment variables \`AWS\_ROLE\_ARN\` and \`AWS\_WEB\_IDENTITY\_TOKEN\_FILE\` are set. They inspect the token file at \`/var/run/secrets/eks.amazonaws.com/serviceaccount/token\` and see it contains a valid JWT; decoding it reveals an \`exp\` claim 1 hour in the future from the pod start time. They realize the AWS SDK for Java \(version 1.11\) they are using reads the token file once during \`InstanceProfileCredentialsProvider\` initialization and never reloads it. After upgrading to AWS SDK for Java 2.x with the \`WebIdentityTokenFileCredentialsProvider\`, which polls the file for changes, the job runs for 6 hours without error. Alternatively, they could have configured the SDK to use a custom provider that reloads the file.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-21T01:53:29.503609+00:00— report_created — created