benkehoe / aws-sso-util

Smooth out the rough edges of AWS SSO (temporarily, until AWS makes it better).
Apache License 2.0
953 stars 72 forks source link

Populate command requires --region when AWS_DEFAULT_SSO_REGION is set #110

Closed tomharvey closed 4 months ago

tomharvey commented 1 year ago

Is that expected behaviour from your standpoint or would it be safe to assume that region when running configure populate without specifying --region option?

iainelder commented 1 year ago

Did you mean to set AWS_DEFAULT_REGION?

AWS_DEFAULT_SSO_REGION isn't one of the standard CLI environment variables.

When AWS_DEFAULT_REGION is set for me the aws configure populate command does its job.

When AWS_DEFAULT_REGION is unset I do need to add the region parameter like this: aws configure populate --region ....

tomharvey commented 1 year ago

Thanks for the quick suggestion @iainelder I'll look into that!

I used AWS_DEFAULT_SSO_REGION because of the docs for aws-sso-util here state to use that.

You probably want to set the environment variables AWS_DEFAULT_SSO_START_URL and AWS_DEFAULT_SSO_REGION, which will inform these commands of your Identity Center start url and region (that is, the region that you've configured Identity Center in), so that you don't have to pass them in as parameters every time.

Happy to set both as a quick workaround, but I'd still be interested to hear if it's best practice to set both so AWS_DEFAULT_REGION serves some purposes and AWS_DEFAULT_SSO_REGION serves others. Or, if aws-sso-util should/could/would fall back to the AWS_DEFAULT_REGION var for all purposes.

tomharvey commented 1 year ago

And, PS @iainelder - I'm also a 🏴󠁧󠁢󠁳󠁣󠁴󠁿 living in 🇪🇸 - a small world!

iainelder commented 1 year ago

Hm, good point about aws-sso-util's own environment variables.

My own Bash profile is pretty complex because I've hacked up some scripting around this tool to generate profiles for multiple AWS organizations. It mixes environment variables for this tool with those of the stock CLI and I'm still figuring out the sanest way to configure everything.

Tomorrow I'll remind myself exactly how my own works to try to give you a better answer.

I see you've adapted to the local climate 😄

tomharvey commented 1 year ago

Confirmed that AWS_DEFAULT_REGION is used by aws-sso-util configure populate, meaning that I don't need --region in that command.

I can see a world where the SSO is in one region but I want to default to a different region for other SDK calls. So, I might want a different AWS_DEFAULT_REGION from AWS_DEFAULT_SSO_REGION.

But, I'm not sure of the logic behind aws-sso-util configure populate using AWS_DEFAULT_REGION and ignoring AWS_DEFAULT_SSO_REGION. Would love to know if that's intentional, or if we can change the behaviour (if my toddler agrees with my spare time expectations, I'm sure I could whip up a PR)

iainelder commented 1 year ago

I stepped through the behavior with a clean profile to understand what happens.

No output here means I have no AWS environment variables set.

$ printenv | grep AWS

Set some basic environment variables to isolate aws-sso-util from my real configuration.

It makes sense that populate can't find the instance yet.

$ cd "$(mktemp --dir)"
$ export AWS_CONFIG_FILE="$PWD/config"
$ export AWS_SHARED_CREDENTIALS_FILE=/dev/null
$ aws-sso-util configure populate
No Identity Center instance found

Set the just the start URL.

It makes sense that populate still doesn't find the instance because it also needs to know the host region.

(Is there some reason that AWS doesn't include the region in the URL? It could simplify this step.)

$ export AWS_DEFAULT_SSO_START_URL=https://d-1111111111.awsapps.com/start/
$ aws-sso-util configure populate
No Identity Center instance found

Set the SSO region.

Now here's where the CLI behavior gets a little confusing.

(Is this when you created the issue, @TomHarvey?)

It's unclear whether populate finds the instance or not.

What's clear is that it fails because I haven't set the region for the profiles. You can check the --help output to get what --region means.

$ export AWS_DEFAULT_SSO_REGION=eu-central-1
$ aws-sso-util configure populate
Usage: aws-sso-util configure populate [OPTIONS]
Try 'aws-sso-util configure populate --help' for help.

Error: Missing arguments: --region

Set the profile region.

Now populate has enough information to do its job.

$ export AWS_DEFAULT_REGION=eu-central-1
$ aws-sso-util configure populate
Logging in to https://d-1111111111.awsapps.com/start/
Login with IAM Identity Center required.
Attempting to open the authorization page in your default browser.
If the browser does not open or you wish to use a different device to
authorize this request, open the following URL:

https://device.sso.eu-central-1.amazonaws.com/

Then enter the code:

XXXX-XXXX

^C
Aborted!

On the surface it seems reasonable and safe when AWS_DEFAULT_REGIONis not set to reuse AWS_DEFAULT_SSO_REGION for the profile region. On the other hand, it risk conflating distinct settings.

@BenKehoe, is there some security reason for keeping these settings separate?

Either way I'm happy to keep the behavior as it is because I can just set all these once in my Bash profile.

And I learned that I can update my own scripts to use the proper environment variables (AWS_DEFAULT_SSO_START_URL and AWS_DEFAULT_SSO_REGION) instead of the ones I made up for the same purpose! Thanks @TomHarvey for the question :-))

benkehoe commented 4 months ago

Identity Center has a region associated with it, which is distinct from the region credentials retrieved from Identity Center (in that Identity Center region) are used in. AWS_DEFAULT_REGION is the credential-use region, and AWS_SSO_DEFAULT_REGION is the Identity Center region. I keep them explicitly separate always (including in the configure populate parameters), because I think it's important for people to be clear on the difference.

You can also use AWS_CONFIGURE_DEFAULT_REGION to only affect the configuration commands, not other SDK or CLI calls.