SSO auth failure if AWS_DEFAULT_PROFILE != AWS_PROFILE #3891
Assignees
Labels
bug
This issue is a confirmed bug.
credentials
needs-major-version
Can only be considered for the next major release
p2
This is a standard priority issue
Comments
Peter-Darton-i2
added
bug
RyanFitzSimmonsAK
added
credentials
investigating
|
Hi @Peter-Darton-i2, thanks for reaching out. I had some trouble reproducing this behavior; could you provide debug logs for both AWS CLI ( |
RyanFitzSimmonsAK
added
response-requested
|
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. |
github-actions
bot
added
the
closing-soon
|
OK, to make things a little simpler, I did this from my "vanilla" WSL2 environment (rather than a docker container inside WSL2) but the results are much the same. Both profiles are in First, we do Then we use Then we use the AWS CLI to do "describe alarms" (there aren't any right now): Next, to show the problem, we do However, if we edit the command and instead do TL;DR: |
github-actions
bot
removed
closing-soon
|
Thanks for following up. The team is aware of this behavior, but fixing it would be considered a breaking change. It is worth noting that |
RyanFitzSimmonsAK
added
the
needs-major-version
|
I understand that changing the actual behaviour would, technically, be a breaking change ... but from my point of view, the existing behaviour is a violation of "the principal of least surprise" (in that I was expecting this to work "just like the AWS cli"). I wonder if, in the interim, we could have a difficult-to-miss warning telling folks something like "WARNING: Problem exists between keyboard and chair: You've set both AWS_PROFILE and AWS_DEFAULT_PROFILE, and set them to different values. Things are not going to work the way you might expect". ...or, perhaps, introduce a new way (so not a breaking change, just an addition) of getting a boto3.Session that will "behave exactly like the AWS cli" so that folks can write code that calls upon boto3 in a way that it will authenticate "just like the AWS cli" (and then this new way can be made the default behaviour as a needs-major-version breaking change some time in the future). Basically, I'd like to ensure that my users can't get confused by my (boto3 based) python code behaving differently to the AWS cli. So, if I can't have the default functionality of boto3 changed, I'd either like an easy-to-code workaround, or a warning that users can't miss. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Summary: boto3 seems to use $AWS_DEFAULT_PROFILE in preference to $AWS_PROFILE, which is the opposite to the aws cli's behavior.
Details:
I'm using SSO.
I've got a
~/.aws/configfile containing multiple profiles, including[profile foo]and[profile bar].I've set AWS_DEFAULT_PROFILE=foo and AWS_PROFILE=bar.
I'm logged in - the aws cli is working and accessing stuff in "bar" (as expected).
I've got a python script that gets a session by calling
boto3.Session()...but client calls fail unless I unset AWS_DEFAULT_PROFILE.
Expected Behavior
I expected
boto3.Session()to use the profile from$AWS_PROFILEand to ignore$AWS_DEFAULT_PROFILE(because$AWS_PROFILEtakes precedence and it was set).i.e. the default should be ignored if a non-default value is provided.
Current Behavior
Reproduction Steps
set AWS_DEFAULT_PROFILE=foo and AWS_PROFILE=bar, where foo and bar are valid aws profiles described in
~/.aws/configLogin to aws by doing
aws sso loginCheck aws cli is working; it should be accessing stuff in "bar".
Run a python script:
... then instead of getting alarms read (which this script doesn't output), we get an exception thrown:
botocore.exceptions.SSOTokenLoadError: Error loading SSO Token: Token for https://d-12345abcde.awsapps.com/start#/ does not existIf I unset AWS_DEFAULT_PROFILE or if I set AWS_DEFAULT_PROFILE to be == $AWS_PROFILE then things work again.
Similarly, if I change the code to say
session = boto3.Session(profile_name='bar')then it all works.Possible Solution
I suspect that some (if not all) of the code is looking at AWS_DEFAULT_PROFILE when it should be looking at "AWS_PROFILE if that's set, otherwise use AWS_DEFAULT_PROFILE".
I found that if I did
export AWS_DEFAULT_PROFILE=$AWS_PROFILEor I unset AWS_DEFAULT_PROFILE then boto3 was happy again ... but "in an ideal world" these workarounds shouldn't be necessary.Additional Information/Context
As an end user, having different AWS technologies use different authentication controls & requirements is confusing. I want them all to work the same way, so as the aws cli uses AWS_PROFILE if it's set but defaulting to AWS_DEFAULT_PROFILE (if AWS_PROFILE isn't set) then that's the behaviour I expect from boto3.
It might be that this issue was the underlying cause of the confusion reported in #913, although these two scenarios are significantly different.
Environment details:
I'm using a docker container running under Windows WSL2 & docker desktop (layers in layers in layers...) but the short version is that "it's basically linux".
python --versionreportsPython 3.9.16pip show boto3reports:...and
pip show botocoretells me it'sVersion: 1.31.57SDK version used
boto3 version 1.28.57
Environment details (OS name and version, etc.)
Linux 752a5f9ee677 5.10.102.1-microsoft-standard-WSL2 #1 SMP Wed Mar 2 00:30:59 UTC 2022 x86_64 x86_64 x86_64 GNU/Linuxwith python 3.9.16The text was updated successfully, but these errors were encountered: