[larusso]

In my company everything goes through Active Directory and we use saml2aws [1] to generate credentials with two factor involved. It works quite well for us. We even use this for our artists to create local builds of our games since we keep all important secrets and such in aws secrets mananger. We scope access to said secrets with custom roles and tags.

[1] https://github.com/Versent/saml2aws

[solatic]

We do the same, through Google Workspace. saml2aws has a propensity to randomly break (probably Google's fault, as saml2aws scrapes the login pages) but it's "good enough".

Quoting original link:

> The regular approach taken by many software companies is either:

> Using expensive SSO solutions (3rd party single sign-on SaaS platforms) and writing custom CLI toolkits for integrating with said platforms for programmatic AWS access (early and unnecessary complexity, financial and development time costs). > Or not using any MFA at all and just using plain permanent AWS IAM user credentials (terribly insecure).

saml2aws is open-source code that anybody can use and contribute to, and can be used off-the-shelf. Google Workspace is "free" in that we were already using it and paying for it. Meanwhile the approach asked for in the parent, with a hub and spoke model, requires long-lived IAM users in the hub account that need to be managed separately from the company's SSO directory and thus violates SSO principles.

[larusso]

We have the rule to limit down shared and manual maintained users in all our services. More so we not only want to limit down the attack vector but also are able to know where a potential breach came from. A shared IAM role coming from an ansible vault or git crypt repo does not cut it. Also the credentials valid to the end of time. There is also on and off boarding issues. A person which has access today should have his access easily being revoked if necessary. With shared tokens that is super hard to maintain.