aws login credentials are silently overridden by static access keys

[k-ibaraki]

Describe the bug

When static AWS credentials (access keys) exist in ~/.aws/credentials, the aws login command displays a success message saying it "Updated profile default to use [new credentials]", but those new credentials are silently ignored. The static credentials from ~/.aws/credentials continue to be used due to credential precedence rules, with no warning to the user.

This creates a dangerous situation where users believe they have switched to different credentials (via aws login) but are actually still using their old static access keys.

Regression Issue

• Select this option if this issue appears to be a regression.

Expected Behavior

When a user runs aws login successfully:

1. If static credentials exist in ~/.aws/credentials for the same profile, AWS CLI should:

   • Display a WARNING that static credentials will take precedence, OR
   • Prompt the user to choose whether to remove the conflicting static credentials, OR
   • Fail with a clear error message about the credential conflict

2. Users should never see "Updated profile to use X" when X will not actually be used

3. The success message should accurately reflect whether the login credentials will actually be used

Current Behavior

1. User has static access keys in ~/.aws/credentials for [default] profile
2. User runs aws login and successfully authenticates
3. AWS CLI displays: "Updated profile default to use arn:aws:sts::XXXXXXXXXXXX:assumed-role/RoleName/username credentials."
4. User believes the profile now uses the new login credentials
5. User runs AWS CLI commands
6. Commands silently use the static credentials from ~/.aws/credentials
7. The login credentials are completely ignored
8. No warning or indication is given that a different credential is being used

Reproduction Steps

1. Configure static access keys in ~/.aws/credentials:
   [default]
   aws_access_key_id = AKIA...
   aws_secret_access_key = xxx...

2. Verify current identity:
   $ aws sts get-caller-identity
   {
   "Account": "111111111111",
   "Arn": "arn:aws:iam::111111111111:user/test-user"
   }

3. Run aws login and complete browser authentication
   Output shows:
   "Updated profile default to use arn:aws:sts::222222222222:assumed-role/AdminRole/username credentials."

4. Check identity again:
   $ aws sts get-caller-identity
   {
   "Account": "111111111111",
   "Arn": "arn:aws:iam::111111111111:user/test-user"
   }

   ⚠️ Still using static credentials despite success message claiming profile was updated

5. Manually remove static credentials from ~/.aws/credentials

6. Check identity again:
   $ aws sts get-caller-identity
   {
   "Account": "222222222222",
   "Arn": "arn:aws:sts::222222222222:assumed-role/AdminRole/username"
   }

   ✓ NOW using aws login credentials

Possible Solution

Option 1: Display a prominent warning when aws login detects conflicting static credentials
Option 2: Prompt user "Static credentials exist for this profile. Remove them? (y/n)"
Option 3: Change success message to indicate credentials may not be used due to precedence
Option 4: Fail aws login command with error explaining the credential conflict

Additional Information/Context

This is a security concern because:

1. Misleading success message: aws login claims "Updated profile to use [credentials]" but those credentials are not used if static keys exist in ~/.aws/credentials

2. Silent credential override: Users operate with different credentials than they authenticated with, with zero indication this is happening

3. Defeats the purpose of aws login: The feature is designed to eliminate static credentials, but silently continues using them when they exist

4. Accidental wrong-account operations: Users may believe they're operating in one AWS account (from login) while actually operating in a different account (from static credentials)

While AWS credential precedence is documented (credentials file > config file), the aws login command should either:

• Handle this conflict explicitly (warn/prompt/fail), OR
• Not display a misleading success message when the credentials won't actually be used

CLI version used

aws-cli/2.32.1

Environment details (OS name and version, etc.)

macOS 15.6.1

[ashovlin]

Hey @k-ibaraki, thanks for writing this up, we've heard this feedback from a few early adopters.

Of the suggested solutions, do you have a preference between them? Or is one of them is how you expected it to work?

[k-ibaraki]

@ashovlin
Thanks for the quick response!

Personally, I believe Proposal 2 (Interactive) is the better approach for safety.
However, Proposal 1 (Warning) would be a perfectly acceptable solution for now.

In my opinion, the most important thing is to resolve the current "Silent Failure" as soon as possible.

[tedm]

For those who use both static creds, and sts creds, is there a way to set sts creds to a higher priority than static creds? Or must one remove / rename the local .credentials file to ensure the sts creds have priority?

[jstrese]

We just found this as well.

The larger problem, in my opinion, is that we have a file called config that can define more than configuration (credentials in this case). I would suggest having the AWS CLI default to placing credentials of any sort in the file called credentials, and other configuration can be left in config (like region). A clear separation of credential and config would be ideal 👍

The expected result after running aws login is that we should be able to successfuly excecute a CLI command after all. So placing it in the location that would guarantee this expectation (credentials at this time) should at least be done.

[ashovlin]

In 2.32.32 that was released today, aws login will now print an error and fail if you run it for an existing profile that is already configured with a different style of credentials.

@tedm - Within a single profile, there is not a way to change the CLI's hierarchy. You may be able to define different profiles for different styles, and then switch which profile is active via --profile or AWS_PROFILE. See https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#configure-precedence for the hierarchy.