Report #12217
[bug\_fix] Unable to locate credentials in AWS SDK
Configure IAM Roles for Service Accounts \(IRSA\) by annotating the Kubernetes service account with the IAM role ARN and ensuring the OIDC provider is associated with the EKS cluster. The root cause is that the AWS SDK's default credential chain checks environment variables, ~/.aws/credentials, and the EC2 metadata service \(IMDS\), but inside an EKS pod without IRSA, none of these sources are available \(IMDS is blocked or returns 404\), and no static credentials are injected, resulting in the provider chain failing.
Journey Context:
A developer migrates a microservice from Amazon EC2 to Amazon EKS \(Kubernetes\). The service uses the AWS SDK for Go to publish messages to SNS and DynamoDB. On EC2, the service worked because the instance had an IAM instance profile attached, and the SDK successfully retrieved credentials from the EC2 metadata service \(IMDSv2\) at 169.254.169.254. After deploying to EKS, the pod fails to start with CrashLoopBackOff. The logs show "SharedConfigAssumeRoleError: failed to retrieve credentials\\ncaused by: EnvConfigCredentialsNotFound: unable to find environment credentials\\nSharedCredentialsNotFound: failed to load credentials from shared config file\\nEC2MetadataError: failed to make EC2Metadata request\\n\\". The developer execs into the pod and attempts to curl the metadata endpoint: \`curl -v http://169.254.169.254/latest/meta-data/iam/security-credentials/\`, but it times out. They realize that EKS nodes often block IMDS from pods for security \(or the hop limit is 1\). They consider injecting static AWS credentials as secrets but know that's an anti-pattern. Researching EKS IAM integration, they discover IAM Roles for Service Accounts \(IRSA\). They create an IAM role with the necessary trust policy allowing the EKS OIDC provider to assume it with the condition \`StringEquals: \{sub: system:serviceaccount:default:my-sa\}\`. They annotate the Kubernetes service account with \`eks.amazonaws.com/role-arn: arn:aws:iam::123:role/MyRole\`. When the pod restarts, the EKS mutating webhook injects the environment variables \`AWS\_ROLE\_ARN\` and \`AWS\_WEB\_IDENTITY\_TOKEN\_FILE\` \(pointing to the projected service account token\). The AWS SDK now uses the WebIdentityTokenFile provider, reads the JWT, and calls STS AssumeRoleWithWebIdentity to obtain temporary credentials, resolving the "Unable to locate credentials" error without static keys.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T15:20:38.844498+00:00— report_created — created