When specifying a shared profile credentials in env vars are ignored, contrary to the documentation

[AustinGomez]

Documentation

• I've gone though the API reference
• I've checked AWS Forums and StackOverflow for answers
• I've searched for previous similar issues and didn't find any solution

Describe the bug

We are trying to specify a shared profile config as follows:

config.LoadDefaultConfig(context.Background(), config.WithSharedConfigProfile("some-profile"))

The docs state here: "If you specify credentials in environment variables, the SDK always uses those credentials, no matter which profile you specify." However, if you specify a shared profile, the SDK uses the credentials in the specified shared config profile rather than the env vars.

After a quick investigation it looks like the bug comes from the following case statement. Maybe fallthrough was intended here.

aws-sdk-go-v2/config/resolve_credentials.go

Line 98 in 3ec6226

err = resolveCredsFromProfile(ctx, cfg, envConfig, sharedConfig, other)

Expected behavior

The SDK should use the credentials in the environment variables.

Current behavior

The SDK uses the credentials in the aws Config file.

Steps to Reproduce

repro.go:

import "github.com/aws/aws-sdk-go-v2/config"

cfg, err := config.LoadDefaultConfig(context.Background(), config.WithSharedConfigProfile("some-profile"))
if err != nil {
	panic(err)
}

1. Set credentials in AWS Config
2. Run AWS_ACCESS_KEY=XXXXXXX AWS_SECRET_ACCESS_KEY=XXXXXXX AWS_SESSION_TOKEN=XXXXXXXX go run repro.go

The credentials are set in the env vars, but the ones in the Config file are used.

Possible Solution

Fix the control flow here if the intended behaviour is to have the env vars to take precedence, or update the docs otherwise.

AWS Go SDK version used

1.1.6

Compiler and Version used

go version go1.17.3 darwin/amd64

Operating System and version

macOS Big Sur 11.6.2

[skmcgrail]

Thanks for reaching out to us @AustinGomez . I believe this particular statement is the documentation needs some clarification, and we should take an action to update it to make it clearer.

When specifying WithSharedConfigProfile this is considered higher-precedence since your application is programmatically setting an explicit profile to use when loading. This statement is meant to reflect that absent of any programmatic overrides, if both AWS_PROFILE and credential values AWS_ACCESS_KEY, AWS_SECRET_ACCESS_KEY are present in the environment, then the credential defined in the environment will have higher priority. But this is confusing since the lead-up to this statement explains programmatic overrides.

[AustinGomez]

Hi Sean, I figured that might be the case. Looks like this section could also use some clarity, since the numbered list of credentials priorities puts environment variables higher than shared config and doesn't mention programmatic overrides at all.

https://aws.github.io/aws-sdk-go-v2/docs/configuring-sdk/#specifying-credentials

I'm also a little confused about the behaviour when a shared profile is specified while using an IAM role. My understanding is that the IAM role takes precedence? Which would also contradict the docs.

[AustinGomez]

Also, no error occurs if you make this mistake. If you specify a named profile override but don't provide it and instead set credentials in an environment variable, the SDK will not error and instead only errors when it tries to make a request, leading to a pretty tough debugging experience.

E.G., for our secretsmanager call:

error getting secret arn:aws:secretsmanager:us-west-2:xxxxxxxxxxx: operation error Secrets Manager: GetSecretValue, failed to sign request: failed to retrieve credentials: no EC2 IMDS role found, operation error ec2imds: GetMetadata, http response error StatusCode: 403, request to EC2 IMDS failed

[lucix-aws]

The developer guide has been migrated to the main AWS doc portal, this is no longer actionable for the SDK

[github-actions]

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.