Summary

The ordering of AWS credential fetching defined in the auth spec is:

1. The URI
2. Environment variables
3. A custom AWS credential provider if the driver supports it.
4. Using `AssumeRoleWithWebIdentity` if `AWS_WEB_IDENTITY_TOKEN_FILE` and `AWS_ROLE_ARN` are set.
5. The ECS endpoint if `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI` is set. Otherwise, the EC2 endpoint.

However, some environments (ex: AWS lambda) include AWS-auth related environment variables automatically.  This makes it impossible to use a different credential fetching mechanism to obtain credentials with a custom credential provider (ex: Node bug).

The custom credential provider likely should have highest precedence of all credential fetching mechanisms.

Motivation

Who is the affected end user?

AWS auth users with custom credential providers.

How does this affect the end user?

Users are unable to authenticate in environments where AWS credentials are present in the environment but want to use a different credential fetching mechanism.

How likely is it that this problem or use case will occur?

Always, in certain environments.

If the problem does occur, what are the consequences and how severe are they?

Users are unable to authenticate without workarounds (ex: removing all AWS-auth related secrets from the environment before launching the driver process).

Is this issue urgent?

unsure.

Is this ticket required by a downstream team?

no.

Is this ticket only for tests?

no.

Acceptance Criteria

• Determine the correct precedence ordering of the credential fetching in drivers.
• Ensure that the correct ordering is tested - we likely need a test in an environment that has AWS auth variables in the environment but uses a non-env variable related auth mechanism.