locate_credentials() should be more informative
Closed this issue · 10 comments
Please specify whether your issue is about:
- a possible bug
- a question about package functionality
- a suggested code or documentation change, improvement to the code, or feature request
When calling locate_credentials(profile='myprofile') I was surprised to see that it kept returning the credentials associated with a different profile. This appears to happen because locate_credentials gives precedence to credentials that are present in environment variables -- it'd be great to log or warn the user somehow that locate_credentials is disregarding the profile argument in favor of using the credentials found in the environment.
Not sure to what extent this behavior is intended -- if the maintainer has ideas about what you want to do in this situation I can take a stab at implementing.
The behaviour is intended (in line with how the official SDKs work): https://boto3.amazonaws.com/v1/documentation/api/latest/guide/configuration.html#configuring-credentials - env variables have precedence over profiles.
However, printing a warning in that case (profile specifically provided, but environment will be used) would be a helpful thing to do.
Interestingly, while I agree that the documentation is a little bit unclear, the way the python SDK works matches my expectations, not the way this library currently works.
import boto3
import os
os.environ["AWS_ACCESS_KEY_ID"] = "TOINFINITY"
os.environ["AWS_SECRET_ACCESS_KEY"] = "ANDBEYOND"
# Read "buzz" credentials out of environment variables
session = boto3.Session()
credentials = session.get_credentials()
credentials = credentials.get_frozen_credentials()
print(credentials)
# prints "TO INFINITY" and "AND BEYOND"
session = boto3.Session(profile_name='woody')
credentials = session.get_credentials()
credentials = credentials.get_frozen_credentials()
print(credentials)
# prints "HOWDY" and "PARTNER"Where of course I have these lines in my ~/.aws/credentials file:
[woody]
aws_access_key_id=HOWDY
aws_secret_access_key=PARTNER
That is, settting the profile-name in the boto3.Session() method overrrides the credentials that are present in the environment.
I think we should update this library to match boto!
Okay, I agree we should be in line with running behaviour.
I just wish the documentation was clearer about that.
Yeah, for sure. I was initially surprised when I looked at the docs from your answer, but I've used boto3 pretty extensively which was I expected this to work in aws.signature. This statement:
The mechanism in which boto3 looks for credentials is to search through a list of possible locations and stop as soon as it finds credentials. The order in which Boto3 searches for credentials is:
- Passing credentials as parameters in the boto.client() method
- Passing credentials as parameters when creating a Session object
- Environment variables
Should refer to both credentials and a profile name -- I think in this context, when the authors say "credentials" they mean not only the keys themselves, but also any manner of "selecting" credentials, which in this case includes referencing a given profile.
I can take a stab at this this weekend -- do you have concerns about breaking functionality that other folks might be relying on in terms of the current order-of-credentials-search? Or would you be comfortable releasing this straight-away?
That's a fair interpretation, and it's certainly not inconsistent with how boto3 works. Just not being aware of how that worked in this precise case, I was reading it differently. Ah well.
I really have very little idea how this is being used in the wild. I'm tempted to maybe say release it when it's done. If it turns out that breaks a lot of code, I'd probably have to roll it back, gated behind an option() so people can opt in (or out, maybe?)
I mean, if you can add an opt out option as part of re-writing the ordering, I think that's a better solution
Happy to help with things like that, yes