Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Explicit --profile option should have precedence over credentials env vars #113

Closed
ches opened this issue May 8, 2013 · 13 comments
Closed

Explicit --profile option should have precedence over credentials env vars #113

ches opened this issue May 8, 2013 · 13 comments
Assignees
@jamesls
Labels
feature-request A feature should be added or improved.
Milestone
0.20.0

Comments

@ches
Copy link

ches commented May 8, 2013

I have credentials for a primary account set in AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY to support other tools. When I try to pass a --profile option for an aws-cli command, the profile is not used and the account in env is -- I have to unset the env vars in order to use profiles. I believe that an option given explicitly should have precedence over the environment.
@ghost ghost assigned garnaat May 9, 2013
@adamsb6
Copy link

adamsb6 commented Feb 21, 2014

I have the same issue, and agree that an explicit profile should take precedence over environment variables that are commonly used by other tools in addition to aws-cli.

Is there a design reason for this? I'll implement the fix and create a PR if one would be welcome.

@jamesls jamesls assigned jamesls and unassigned garnaat Mar 5, 2014
@GuiSim
Copy link

GuiSim commented Mar 24, 2014

If I have AWS environment variables, is there anyway for me to give the AWS config file precedence over the environment variables?

So far the only way I've found is to delete the environment variables.

@ionFish ionFish mentioned this issue Aug 4, 2014
Closed
@davidski
Copy link

davidski commented Aug 4, 2014

Is there any movement on this issue?

@asieira
Copy link
Contributor

asieira commented Nov 5, 2014

+1

@jdotjdot
Copy link

100% agree on this.

What I've done for the time being is actually have an alias around the aws command that checks if a --profile option was supplied, and if so, unsets the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environmental variables that I have to keep for configuration reasons for other applications.

No question in my mind that an explicitly specified --profile should override the config var.

@jamesls jamesls mentioned this issue Feb 2, 2015
Closed
@cristianobaptista
Copy link

I'm currently having the same issue. As stated above I also think that explicitly defined options should have precedence over the environment.

Setting AWS_DEFAULT_PROFILE also does not change the behaviour described above.

@pims
Copy link

pims commented Mar 5, 2015

I’ve been struggling with IAM setting up IAM policies and testing them with --profile before figuring out aws-cli is using my general environment variables.

Any chance to get this into the next release?

@ajmath
Copy link

ajmath commented Mar 9, 2015

Also having this issue.

@davidski
Copy link

davidski commented Mar 9, 2015

What can we do to assist with closing out this nearly 2 year old issue? Folks seem unified that having explicitly defined option overridden by environment variables is a Bad Thing(tm). Is a PR needed to get this done?

@ajmath
Copy link

ajmath commented Mar 9, 2015

This behavior contradicts the documentation found at http://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#config-settings-and-precedence
screen shot 2015-03-09 at 11 48 18 am

@jamesls
Copy link
Member

jamesls commented Mar 9, 2015

Taking a look. I agree this should be fixed.

@danielgtaylor danielgtaylor mentioned this issue Mar 10, 2015
Merged
danielgtaylor added a commit to boto/botocore that referenced this issue Mar 16, 2015
@danielgtaylor
Explicit profile overrides environment variables
cfc5a92 
This changes the behavior of environment variable credential loading to
function as described in aws/aws-cli#113. Here is what this looks like
for both the CLI and Botocore/Boto 3:

CLI:
```bash
$ AWS_ACCESS_KEY_ID=foo AWS_SECRET_ACCESS_KEY=bar aws s3 ls

$ AWS_ACCESS_KEY_ID=foo AWS_SECRET_ACCESS_KEY=bar aws --profile dev s3 ls
```

Python:
```python
$ AWS_ACCESS_KEY_ID=foo AWS_SECRET_ACCESS_KEY=bar python
>>> import boto3
>>> boto3.setup_default_session(profile_name='dev')
>>> # The following will use the profile, not the env vars!
>>> s3dev = boto3.resource('s3')
```

Added a test and a new log message to ensure it's obvious what is happening.
@kyleknap
Copy link
Contributor

This is now fixed. See below:

$ export AWS_ACCESS_KEY_ID=foo
$ export AWS_SECRET_ACCESS_KEY=bar
$ 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.

$ aws s3 ls --profile my-profile
2014-11-24 13:33:43 mybucket
....
....

Closing issue.

@ches
Copy link
Author

ches commented Mar 19, 2015

👏 🎉

@mtdowling mtdowling mentioned this issue Nov 19, 2015
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jamesls jamesls

Labels
feature-request A feature should be added or improved.
Projects
None yet
Milestone
0.20.0
Development

No branches or pull requests