awscli should not ignore the AWS_SECRET_ACCESS_KEY env var just because the AWS_ACCESS_KEY_ID env var is not defined

[jamshid]

Describe the bug

Not a big deal and not really a bug but I was surprised that env var AWS_SECRET_ACCESS_KEY is ignored, using aws_secret_access_key from ~/.aws/config, unless AWS_ACCESS_KEY_ID is also set.
The current behavior seems to contradict the docs which simply say the env var overrides the profile setting.
https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-envvars.html

AWS_SECRET_ACCESS_KEY
Specifies the secret key associated with the access key. This is essentially the "password" for the access key.
If defined, this environment variable overrides the value for the profile setting aws_secret_access_key. You can't specify the secret access key ID as a command line option.

Regression Issue

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

Expected Behavior

AWS_SECRET_ACCESS_KEY=badsecret aws s3api list-buckets should fail

Current Behavior

Need to also set AWS_ACCESS_KEY_ID to get:
AWS_ACCESS_KEY_ID=<redacted> AWS_SECRET_ACCESS_KEY=badsecret aws s3api list-buckets to fail

Reproduction Steps

AWS_SECRET_ACCESS_KEY=badsecret aws s3api list-buckets

Possible Solution

Make the env var override regardless of other env var settings.

Additional Information/Context

No response

CLI version used

aws-cli/2.27.26 Python/3.13.3

Environment details (OS name and version, etc.)

Darwin/24.5.0 source/arm64

[RyanFitzSimmonsAK]

Hi @jamshid, thanks for reaching out. I did some testing, and it turns out that there's actually an error for when one of these environment variables is set, but not the other.

Setting access key but not secret key results in a helpful error.

C:\Users\rtsfitz>aws sts get-caller-identity
{
    "UserId": "redacted",
    "Account": "redacted",
    "Arn": "redacted"
}

C:\Users\rtsfitz>set AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE

C:\Users\rtsfitz>aws sts get-caller-identity

Partial credentials found in env, missing: AWS_SECRET_ACCESS_KEY

Setting secret key but not access key uses other credentials, as you showed.

C:\Users\rtsfitz>aws sts get-caller-identity
{
    "UserId": "redacted",
    "Account": "redacted",
    "Arn": "redacted"
}

C:\Users\rtsfitz>set AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

C:\Users\rtsfitz>aws sts get-caller-identity
{
    "UserId": "redacted",
    "Account": "redacted",
    "Arn": "redacted"
}

I think the most straightforward resolution to this issue is to make the error apply either way, but if that constitutes a breaking change, then a documentation update might be the path forward to more clearly explain this behavior. I don't think allowing partial credentials quite makes sense, and might constitute a breaking change as well. Thoughts?

[jamshid]

Yes I am using AWS S3. I have a valid ~/.aws/config:

[default]
aws_access_key_id = <redacted>
aws_secret_access_key = <redacted>

I run aws s3api list-buckets, it works as expected.
I run AWS_SECRET_ACCESS_KEY=badsecret aws s3api list-buckets and it still works. That is unexpected. IMO awscli should use the aws_access_key_id from the config file with the secret key badsecret from env and the operation should fail with a 403 SignatureDoesNotMatch.

It does fail as expected when I supply env var AWS_ACCESS_KEY_ID:

% AWS_ACCESS_KEY_ID=<redacted> AWS_SECRET_ACCESS_KEY=badsecret aws s3api list-buckets

An error occurred (SignatureDoesNotMatch) when calling the ListBuckets operation: The request signature we calculated does not match the signature you provided. Check your key and signing method.

[RyanFitzSimmonsAK]

IMO awscli should use the aws_access_key_id from the config file with the secret key badsecret from env and the operation should fail with a 403 SignatureDoesNotMatch.

Mixing and matching credential providers is not something we want to support. Additionally, this would be a breaking change to people depending on the existing behavior.

For the same reasons that the above is a breaking change, we can't make the helpful error apply either way. We're going to update the documentation to clearly explain the existing behavior. I've created a backlog item to do so, and will update this issue when it's done.