AWS_PROFILE is ignored when AWS_ROLE_ARN is set

[Slevy35]

Describe the bug

when using the environment variable AWS_PROFILE, if the AWS_ROLE_ARN env exists the profile env is ignored. but when using the --profile the new profile is used.

Expected Behavior

AWS_PROFILE should not get override

Current Behavior

AWS_PROFILE env is ignored if AWS_ROLE_ARN is set

Reproduction Steps

run aws configure

aws configure set --profile <NEW_PROFILE> web_identity_token_file /var/run/secrets/eks.amazonaws.com/serviceaccount/token
aws configure set --profile <NEW_PROFILE> ****
aws configure set --profile <NEW_PROFILE> region cn-north-1

run aws sts get-caller-identity

root:/# env |  grep -i aws
AWS_DEFAULT_REGION=us-east-1
AWS_REGION=us-east-1
AWS_ROLE_ARN=<CURRENT_ROLE_ARN>
AWS_WEB_IDENTITY_TOKEN_FILE=/var/run/secrets/eks.amazonaws.com/serviceaccount/token
AWS_STS_REGIONAL_ENDPOINTS=regional
root:/# AWS_PROFILE=<NEW_PROFILE> aws sts get-caller-identity --region cn-north-1

An error occurred (InvalidClientTokenId) when calling the GetCallerIdentity operation: The security token included in the request is invalid
root:/# unset AWS_ROLE_ARN
root:/# AWS_PROFILE=<NEW_PROFILE> aws sts get-caller-identity --region cn-north-1
{
    "UserId": "***",
    "Account": "***",
    "Arn": "arn:aws-cn:sts::****:assumed-role/****"
}

Possible Solution

No response

Additional Information/Context

No response

CLI version used

aws-cli/2.17.33 Python/3.11.9 Linux/5.10.219-208.866.amzn2.x86_64 exe/x86_64.debian.11

Environment details (OS name and version, etc.)

docker image python:3.11-slim-bullseye

[tim-finnigan]

Thanks for reaching out. I'm not able to reproduce this, when I set AWS_PROFILE and AWS_ROLE_ARN, then AWS_PROFILE is getting used, which is expected based on the configuration and credentials precedence documentation.

Also the documentation for assuming a role with web identity notes for environment variables AWS_ROLE_ARN and AWS_WEB_IDENTITY_TOKEN_FILE:

These environment variables currently apply only to the assume role with web identity provider. They don't apply to the general assume role provider configuration.

For further investigation, could you provide your debug logs (with any sensitive info redacted) by adding --debug to the command?)

[github-actions[bot]]

Greetings! It looks like this issue hasn’t been active in longer than five days. We encourage you to check if this is still an issue in the latest release. In the absence of more information, we will be closing this issue soon. If you find that this is still a problem, please feel free to provide a comment or upvote with a reaction on the initial post to prevent automatic closure. If the issue is already closed, please feel free to open a new one.

[eternaltyro]

I face this issue when I use aws sso login.

➜  .aws git:(main) ✗ aws --version
aws-cli/2.17.45 Python/3.11.9 Linux/6.10.7-arch1-1 docker/x86_64.amzn.2

$ cat ~/.aws/config
[default]
sso_session = workstation
sso_account_id = 012312312312
sso_role_name = AdministratorAccess
region = us-west-1
output = json
s3 =
    use_dualstack_endpoint = true

[profile client1]
region = ap-south-1
sso_session = client1
sso_account_id = 045645645645
sso_role_name = AdministratorAccess

[sso-session workstation]
sso_start_url = https://d-123123123.awsapps.com/start
sso_region = eu-west-1
sso_registration_scopes = sso:account:access

[sso-session client1]
sso_start_url = https://d-456456456.awsapps.com/start
sso_region = ap-south-1
sso_registration_scopes = sso:account:access

Setting AWS_PROFILE envvar does nothing. I'm having to explicitly provide --profile switch for it to work.

[github-actions[bot]]

Greetings! It looks like this issue hasn’t been active in longer than five days. We encourage you to check if this is still an issue in the latest release. In the absence of more information, we will be closing this issue soon. If you find that this is still a problem, please feel free to provide a comment or upvote with a reaction on the initial post to prevent automatic closure. If the issue is already closed, please feel free to open a new one.

[eternaltyro]

Issue persists in version 2.17.52

[tim-finnigan]

If you add --debug to your command, then you should see the order in which the CLI is looking for credentials, which is documented here: https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html. Can you share your logs (with any sensitive info redacted) for further investigation? I'm not sure that what you're describing is directly related to the original issue here, or if either case is reproducible.