system-wide awscli config (/etc/aws/config)

[pmoody-]

Describe the feature

I would like to see a system-wide aws config file.

Use Case

I'm thinking in terms of being able to distribute a single system-wide configuration to a set of employees, while allowing users to maintain their local ~/.aws/config with whatever specific profiles they want to maintain.

Proposed Solution

something similar to how ssh(1) supports /etc/ssh/config and ~/.ssh/config, in my mind the configuration precedence would be

command line option
environment variable
~/.aws/config
/etc/aws/config

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

CLI version used

aws-cli/2.11.0 Python/3.11.2 Darwin/22.3.0 source/x86_64 prompt/off

Environment details (OS name and version, etc.)

osx, 13.2.1

[tim-finnigan]

Hi @pmoody- thanks for the feature request. I'll share the current credential precedence here for reference: https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-precedence.

Can you elaborate on your use case a bit more? Feature requests like this would need to be considered at a cross-SDK level, similar to #9036. It seems like there may be some overlap between this issue and #9036 in terms of the problem you're trying to solve. You might also consider trying Identity Center as an alternative for managing different accounts.

[pmoody-]

Hey @tim-finnigan, thanks for looking at this.

at $job, we use identity center with our aws accounts. we don't have hundreds, but we have enough that trying to manage the roles by hand is impossible. we manage the accounts and the roles assigned to each account centrally and I would like to be able to push a fully generated config file to each managed machine (employee laptop). since we're using identity center, having the configuration doesn't get you access to a given account/role, it's being a member of the right group. so centrally managing this file makes my life, and the lives of everyone at work, a little easier.

for every account we might have three basic roles that look like

[profile prod-readonly]
sso_start_url = https://foo.awsapps.com/start
sso_region = us-west-2
sso_account_id = 111122223333
sso_role_name = readonly

[profile prod-eng]
sso_start_url = https://foo.awsapps.com/start
sso_region = us-west-2
sso_account_id = 111122223333
sso_role_name = eng

[profile prod-admin]
sso_start_url = https://foo.awsapps.com/start
sso_region = us-west-2
sso_account_id = 111122223333
sso_role_name = admin

and some accounts have lots of profiles with custom roles, eks admin, sales demos, qa, etc. so there are several hundred aws profiles.

any time an sso_role_name changes, the new role name needs to be reflected in the config file, or the user can't use that role. ie, if we make the eng role eng-without-ec2-in-us-east-1, anyone trying to run --profile account-eng will be blocked until they update their ~/.aws/config file to say sso_role_name = eng-without-ec2-in-us-east-1.

in a world with a system-wide configuration, I can use machine management (kandji, puppet, ansible, whatever) to push the updated configuration file out to everyone's machine automatically. I could also use the same machine management to push out a ~/.aws/config, but that would stomp on any personal customization's the users have made. that would make quinnypig's life much worse.

so I see this as similar but different to #9036. where as he has a ridiculously large set of personal settings that he'd like to be able to organize outside of a monolithic ~/.aws/config, I have a group of centrally managed settings I would like to automatically configure for my users.

the centrally managed system-wide settings vs personal settings is a well understood paradigm, with personal settings taking precedence over system wide settings.

These two features could definitely co-exist and they do for things like ssh(1) at least on debian (https://manpages.debian.org/unstable/openssh-client/ssh_config.5.en.html#Include).

Please let me know if you have any questions. I did some basic testing with pr#7728 and that implements this feature. like I said, the plumbing already exists in the repo.

[tim-finnigan]

Thanks for following up and sharing more information regarding this feature request. As discussed in your PR (#7728) this issue can be tracked in the cross-SDK repository going forward. So I will close this issue in favor of #9033.

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one. If you wish to keep having a conversation with other community members under this issue feel free to do so.