Description
Description
The .NET SDK prioritizes credentials from the default
profile over credentials set by environment variables. This is inconsistent with other language SDKs.
Reproduction Steps
- Configure a
default
profile (add values to~/.aws/credentials
and~/.aws/config
). - Set
AWS_ACCESS_KEY_ID
andAWS_SECRET_ACCESS_KEY
environment variables to a different set of credentials. - Run a process with the .NET SDK without programmatically specifying the credential configuration (allow it to use its own fallback behavior).
Expected result:
The credentials specified in step 2 are used by the process.
Actual result:
The credentials specified in the default profile are used by the process. Once a default profile is defined, the only environment variable that is respected is AWS_PROFILE
.
All other SDKs (that I examined: python, javascript) will prioritize the environment variables before looking at the profiles defined in the configuration files.
I understand that this behavior is documented, so one could argue that it "works as designed". This page clearly states the problem: https://docs.aws.amazon.com/sdk-for-net/latest/developer-guide/creds-assign.html
1. Credentials that are explicitly set on the AWS service client, as described in Accessing credentials and profiles in an application.
2. A credentials profile with the name specified by a value in AWSConfigs.AWSProfileName.
3. A credentials profile with the name specified by the AWS_PROFILE environment variable.
4. The [default] credentials profile.
5. SessionAWSCredentials that are created from the AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_SESSION_TOKEN environment variables, if they're all non-empty.
6. BasicAWSCredentials that are created from the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables, if they're both non-empty.
7. IAM Roles for Tasks for Amazon ECS tasks.
8. Amazon EC2 instance metadata.
The item currently ranked at 4 should at least be moved down below 5 and 6, and possibly lower to make it consistent with other SDKs.
This currently leads to very confusing behavior merely by the existence of a default profile that nothing references. It is very difficult to diagnose.
Resolution
- 👋 I can/would-like-to implement a fix for this problem myself
Change the fallback to the default profile to be below the attempt to load from environment variables. I'm happy to make a PR if it will be accepted. The fact that the current behavior is documented makes me think there may have been a specific decision to make the .NET SDK behave different from the others. If that is the case, I would like you to reconsider, or better explain/document the justification.
This is a 🐛 bug-report