Do not prioritize Default profile over environment variables

[joshuaflanagan]

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

1. Configure a default profile (add values to ~/.aws/credentials and ~/.aws/config).
2. Set AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables to a different set of credentials.
3. 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

[ashishdhingra]

Hi @joshuaflanagan,

Good morning.

The behavior is as expected as listed by you in the Credential and profile resolution. Any deviation in behavior could be a breaking change for other customers. I can discuss this with the development team to get their input, not sure if this would be implemented.

Thanks,
Ashish

[joshuaflanagan]

I can discuss this with the development team to get their input, not sure if this would be implemented.

Thank you. It would be useful to get that decision documented so we can all understand why, only in .NET, the environment variable approach to configuration is disabled/broken if the user happens to have a default profile configured.

[ashishdhingra]

Thank you. It would be useful to get that decision documented so we can all understand why, only in .NET, the environment variable approach to configuration is disabled/broken if the user happens to have a default profile configured.

Hi @joshuaflanagan,

Just wanted to update here that I had discussion with development team. Since this is a breaking change, it would be prioritized in next major release (V4). We are unable to commit on a date though at this stage, but you will see updates on this issue as it is worked upon.

Thanks,
Ashish

[github-actions]

We have noticed this issue has not received attention in 1 year. We will close this issue for now. If you think this is in error, please feel free to comment and reopen the issue.

[joshuaflanagan]

Is this still on track for the v4 release? Is there an early version available to test?

[ashishdhingra]

Also refer #2580 for additional scenario.

[peterrsongg]

@joshuaflanagan As of Core 3.7.108.0 we've added a new POCO called Profile which you can specify on the config and pass it into the Client constructor to reroute the SDK to use the correct profile. If this is set, it will take precedence over everything else. We couldn't fix the root cause of the issue since that would be a breaking change, but this will at least let you set the correct profile without having to set environment variables and such.

[joshuaflanagan]

This does not seem like a solution at all. The desire is to be able to configure the application through environment variables without changing code. The application code should remain agnostic to where the credentials come from. That is the benefit of having the SDK use it's fallback mechanism. You can take the same application code and use it in different deployed contexts and it will find the credentials.

[dscpinheiro]

Sorry for the long wait, but we just released the latest preview of V4 and the SDK now does not prioritize the default profile over environment variables anymore: https://github.com/aws/aws-sdk-net/releases/tag/4.0.0.0-preview.9

We haven't updated our developer guide page yet (https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/creds-assign.html), but this is the updated priority list:

aws-sdk-net/sdk/src/Core/Amazon.Runtime/Credentials/DefaultAWSCredentialsIdentityResolver.cs

Lines 50 to 58 in b4a9df9

	{
	#if BCL
	() => new AppConfigAWSCredentials(), // Test explicit keys/profile name first.
	#endif
	() => new EnvironmentVariablesAWSCredentials(), // Look for credentials set in environment vars.
	() => AssumeRoleWithWebIdentityCredentials.FromEnvironmentVariables(),
	() => GetAWSCredentials(_credentialProfileChain),
	() => ContainerEC2CredentialsWrapper(), // either get ECS / EKS credentials or instance profile credentials
	};

[github-actions]

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.