use WebIdentityRoleProvider

[tatsuo48]

EKS allows to apply IAM roles in units of kubernetes pods.
https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/

I did terraform plan with a kubernetes pod with an IAM role, but it's failed.

Error: AccessDenied: User: arn:aws:sts::12345678:assumed-role/stg-eks-worker/i-013c3bef03023133c is not authorized to perform: iam:GetGroup on resource: group admin
        status code: 403, request id: d26dd587-06af-4491-8d19-348accf20a20

※Account number is dummy

The error message shows that the IAM role applied to the EC2 instance is being used instead of the IAM role applied to the pod.
I changed priority. If AM role applied to the pod, use it.

Please review it!

[hashicorp-cla]

All committers have signed the CLA.

[tatsuo48]

AWS_WEB_IDENTITY_TOKEN_FILE is come here.

https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/

Because the service account has an eks.amazonaws.com/role-arn annotation, the webhook injects the necessary environment variables (AWS_ROLE_ARN and AWS_WEB_IDENTITY_TOKEN_FILE) and sets up the aws-iam-token projected volume in the pod that the job supervises.

[bflad]

Hi @tatsuo48 👋 Thank you for submitting this.

In general, our preference should be to only configure the AWS Go SDK credentials handlers when absolutely necessary. We try to rely on the fallback behavior of the AWS Go SDK's session.NewSession() / session.NewSessionWithOptions() (once we have tried our custom credentials handling) since those will always be up to date with the default credentials support of the AWS Go SDK and any new handlers.

AWS Go SDK web identity credentials are supported with the same environment variable via:

• session.NewSession() / session.NewSessionWithOptions()
• session.newSession()
• session.mergeConfigSrcs()
• session.resolveCredentials()
• session.assumeWebIdentity()

The problem we currently in this library is that the EC2 Metadata lookups are happening before that fallback logic can occur (see also: #7). We plan on fixing that with the next release of this library, which should resolve this issue automatically without the extra logic proposed in this pull request. Given that, I'm going to close this for now.

If we find we still have issues after those changes, we can open a new issue for tracking and potentially talking about introducing this type of change if it is necessary. I'll ensure we are tracking web identity unit testing (similar to additions in #32).