aws-sso-util console should just work if AWS_PROFILE is set to an SSO-enabled profile

[mmerickel]

Right now --account-id and --role-name as well as --sso-start-url and --sso-region, and --region are all required when using aws-sso-util console launch or aws-sso-util get-token-config and at least in my common case those can generally all be inferred from the config settings in ~/.aws/config if AWS_PROFILE env var is set. Similarly I would expect AWS_DEFAULT_REGION env var to take priority if not specific on cli.

I'd then be able to run aws-sso-util console launch with no arguments!

[thewmo]

Funny, I opened up the issues tab to see if anybody else had said the same thing. Given all the other profile-centered goodness of aws-sso-util it's odd to have to recapitulate so many data elements that are already present (potentially, anyway) in a profile, rather than simply being able to specify a profile name. I really thought I was missing something. This would be a worthwhile enhancement.

[benkehoe]

This is the same as #61. In general, the idea behind aws-sso-util console is not to be an all-purpose web console launcher (which should work as long as there are valid credentials available), but rather to leverage the unique capabilities that AWS SSO provides, which is that you can have a specification of what identity to use without having actual credentials for that identity. That's what is contained in a config token.

Wouldn't it be confusing if aws-sso-util console launch "just worked" if you had AWS_PROFILE set to a profile that contained AWS SSO config, but didn't work if that profile contained, for example, a credential process? Or didn't work if credentials were set in environment variables?

Is what you're looking for a generic console launcher? As in, you don't have a use for the saveable/shareable config token functionality provided by aws-sso-util console, and you don't have a standalone tool that can accomplish console launching for you?

[mmerickel]

aws/aws-cli#4642 is what I want, but it doesn't exist so I was hoping this tool would provide it and the AWS_PROFILE variable that I already have set (it's the right way to use AWS SSO) provides you all the info you need to generate the args required by aws-sso-util console launch.

[benkehoe]

My point is that if you have the following config file:

[profile sso-profile]
sso_start_url = https://foo.awsapps.com/start
sso_region = us-east-2
sso_account_id = 123456789012
sso_role_name = SSORole
region = us-west-2

[profile assumed-role-profile]
role_arn = arn:aws:iam::123456789012:role/RoleToAssume
source_profile = sso-profile

then AWS_PROFILE=sso-profile aws-sso-util console launch would work but AWS_PROFILE=assumed-role-profile aws-sso-util console launch would not, and that's confusing. Or if it you think that it should work, then I would argue aws-sso-util is not the place for this functionality, because it's not an obvious place for people to find a general-purpose console-launching tool. I quickly whipped up a standalone launcher here (it requires boto3 and requests be installed). While it doesn't log into Identity Center for you, an alias that did alias aws-console='aws-sso-util login && python aws_console_launcher.py' would do it. If there's sufficient interest I can polish the standalone thing into a proper tool (I might write it in Go instead).

[lorengordon]

You could check out granted... It offers assume -c <profile> to launch a console with a given profile, it works for all types of profiles, and it will manage the login to Identity Center also.

[benkehoe]

That's basically what I'm saying, there are tools out there to do this in a comprehensive way. aws-sso-util console is meant to explore packaging up console launching information in a saveable/shareable way.

The only difference I'd draw with existing tools if I was making a general-purpose launcher is that I wouldn't aim to fully manage the credentials; granted, awsume, etc. do things like stash the login token in the keychain and inject credentials through environment variables, but then breaks assumptions like the SDKs being able to refresh credentials themselves. I usually build things as thinly on top of AWS-provided tooling as possible.

[lorengordon]

Thankfully granted recently implemented a credential_process option, so now I use that. That way, the profile works fine with pretty much every SDK these days, and it doesn't clutter the env.