How can we make ~/.aws/config easier to manage?

[chrnorm]

In #173 we had a feature request for automatically updating ~/.aws/config based on roles available in an AWS SSO instance.

#230 has added support for this. This PR adds the granted sso generate and granted sso populate commands:

granted sso generate [--prefix <prefix>] [--region <region>] <start url>

I'm opening a discussion here to track conversation on how we can continue to improve the UX of configuring the AWS config file. If you'd like to see any additional customisability added to these commands, please request them here.

I'll also note that aws-sso-util has a fantastic config file generator built in with a lot of customisability. Rather than Granted trying to handle all cases, I think it makes sense to advise advanced users to use aws-sso-util if they have specific templating requirements.

That being said, I'd love to hear any feature requests you might have to improve functionality here.

[chrnorm]

From Alex (via Common Fate Community Slack):

I use ~20 accounts and currently populate my config with aws-sso-util and then perform some automated rewrites. I'd put this usage more at the "power user" end of scale.
I start with a command like
aws-sso-util configure populate -r us-east-1 -r eu-central-1 -r eu-west-1 -r ap-southeast-2 --components account_name,role_name,region --include-region always --trim-account-name "MyCompany-" --trim-role-name 'mydivision-' --separator __
Then I'll use several sed invocations to rewrite profile names for consistency:
Development -> dev
Production -> prod
secondary -> DR
failover -> DR
(simplified regex for illustrative purposes)
Notes:
Most accounts have only two interesting regions, the "primary region" for infra and us-east-1. But across all our accounts there are many primary regions so I end up specifying about six regions and relying on assume's frecency to ignore the irrelevant combinations
All this to say I feel like our situation is quite complex, and I don't expect granted's system to support all this customisation natively. But hopefully it's an illustration of one use-case. Ways to make it easier to share this logic between $work's employees (currently we share a shell script of aws-sso-util;sed;sed;...) would be awesome.

[chrnorm]

From Erik (via Common Fate Community Slack):

I have used aws-sso-util to generate profiles, and with that I have used alternate account and role/permissionSet names. E.g. instead of AWSAdmininistratorAccess just "admin" has been used. In one organisation the region was included in the profile name also, since some accounts have deployments/workloads in multiple regions and it is convenient to include a shortened form of the region in the name, which aws-sso-util can generate.
The organisations I have among my profiles belong to different customers and they may have slightly different naming conventions for the account names. I have tried to keep my profiles consistent in terms of naming and thus changed name patterns, including keep profile names all lowercase, for example.

[lorengordon]

I have a bit of a "similar but different" question. Instead of purely using SSO for every account/role combination, we tend to land users in a single account with SSO and then assume-role to a target account/role. Populating ~/.aws/config for that setup is harder, since there is no authoritative source for the accounts and roles. Instead, I was wondering if it might make sense to build options into granted-cli where it might accept account id and role as arguments and perform the assume-role itself? This would in effect be pretty similar to the Console "Switch Role" feature...

I did see the existing --account-id and --role-name options, but those appear to correspond to the config options sso_account_id and sso_role_name. What I'm talking about would be more like role_arn (but maybe hoping to avoid having to specify the ARN).

assume -c <profile> --<account-arg> account-id --<role-arg> role-name

# or

assume -c <profile> --<role-arn-arg> role-arn

And then assume would use the SSO config from <profile> to get that credential, and then use sts:AssumeRole to get a credential for that role.

That way we wouldn't need profiles for every account/role combination in the aws config...