Aws-cli: AWS_DEFAULT_PROFILE does not work with profiles containing Role ARNs

Created on 25 Jan 2016  路  7Comments  路  Source: aws/aws-cli

As in #805, setting AWS_DEFAULT_PROFILE to a valid profile name is no longer working again. The --profile NAME argument does work, however.

$ aws --version
aws-cli/1.10.0 Python/2.7.10 Darwin/15.2.0 botocore/1.3.22
documentation

Most helpful comment

Yes for your use case you should unset them. If you are trying to rely on AWS_DEFAULT_PROFILE as the preliminary source for credentials, you cannot set environment variables such as AWS_ACCESS_KEY_ID and `AWS_SECRET_ACCESS_KEY. And yes we will get the documentation updated. It was not clear, especially since it is one of the more ambiguous cases.

All 7 comments

I am not seeing it. Here is what I did to try to reproduce:

1) Create a profile named fake with invalid credentials:

[profile fake]
aws_access_key_id = foo
aws_secret_access_key = bar

2) Run the following commands from the command line:

$ export AWS_DEFAULT_PROFILE=fake
$ aws s3 ls

A client error (InvalidAccessKeyId) occurred when calling the ListBuckets operation: The AWS Access Key Id you provided does not exist in our records.

which is as expected because the credentials are invalid.
3) To double check if you run configure list it should should the environment variable be used for the profile, even though I am not sure if the type should be manual:

$ aws configure list
      Name                    Value             Type    Location
      ----                    -----             ----    --------
   profile                     fake           manual    --profile
access_key      ****************foo      config-file    
secret_key      ****************bar      config-file    
    region                <not set>             None    None
(venv27)~/Documents/GitHub/aws-cli$ aws s3 ls --profile foo

Does this help or could you provide a set of steps for me to follow so that I can reproduce/debug the issue?

The issue seems to arise when you're using alternate role ARNs in your profile:

$ AWS_DEFAULT_PROFILE=tokyo aws configure list
      Name                    Value             Type    Location
      ----                    -----             ----    --------
   profile                    tokyo           manual    --profile
access_key     ****************E4RQ              env    
secret_key     ****************qs52              env    
    region           ap-northeast-1      config-file    ~/.aws/config

$ aws --profile tokyo configure list
      Name                    Value             Type    Location
      ----                    -----             ----    --------
   profile                    tokyo           manual    --profile
access_key     ****************NWKA      assume-role    
secret_key     ****************Pnw3      assume-role    
    region           ap-northeast-1      config-file    ~/.aws/config

Follow-up question: Are you setting credentials through the environment variables AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY? If you are, those environment variables take precedence over the credentials contained in the profile that was specified by AWS_DEFAULT_PROFILE because environment variables for credentials is seen as more specific/explict than environment variables for setting a default profile when it comes to determining which access and secret access key pair to use.

Yes, they are set. Should they be unset?

Can you please make the precedence of configuration information explicit in the documentation to cover this case?

Yes for your use case you should unset them. If you are trying to rely on AWS_DEFAULT_PROFILE as the preliminary source for credentials, you cannot set environment variables such as AWS_ACCESS_KEY_ID and `AWS_SECRET_ACCESS_KEY. And yes we will get the documentation updated. It was not clear, especially since it is one of the more ambiguous cases.

Thanks for the clarification!

Was this page helpful?
0 / 5 - 0 ratings