Integrating AWS SSO with the Gruntwork Reference Architecture

[pete0emerson]

Could give me some links or other advice for using AWS SSO with the gruntwork reference architecture?

I understand the basic concept that IAM users are created in the security account, and are expected to assume roles in other accounts as needed. I’m not sure how we should configure permission sets in SSO to avoid duplicating the trust relationships between accounts.

---

Tracked in ticket #109106

[pete0emerson]

We currently don’t have an AWS SSO module and our team lacks expertise in the service to offer concrete steps to roll out SSO into the Reference Architecture. However, we have seen customers successfully integrate AWS SSO into the Reference Architecture in one of two ways:

Using AWS SSO as a full replacement for the security account

In this model, you configure the permission sets in SSO to directly access each of the child accounts, bypassing the security account as a concept. Most customers taking this approach either remove the security account, or keep it as a backup in case something fails in SSO and users are locked out of AWS. The drawback of this approach is that it requires managing the permission sets explicitly in the root account, requiring access to the root account to tweak permissions for individual users in the accounts (e.g., dev and sandbox), which may not be desirable depending on the maturity of the organization.

Using AWS SSO to only access the security account, and then chaining role assume to access the various child accounts

This gives you the advantage of delegating permission management without access to the root account (via the security account), and lets individual users manage permissions in the individual accounts that they own. However, the drawback is that it requires role chaining (SSO => security => child account), which has limitations on certain actions you can take on AWS, as well as limiting you to 1 hour sessions. Refer to this knowledge base article #308 for more info on this setup.

[antonl]

I'm happy to report that there's a third answer now using the new Customer-Managed Policies. The idea here is to reuse the new standalone policy documents that gruntwork modules provide in different accounts (eg allow-ops-access-from-other-accounts) and deploy permission sets that reference those. Since deploying permission sets creates roles automatically, one has to be careful with eg EKS auth-map bindings to make sure that the autogenerated roles are present. To tweak permissions in each account, one just modifies the policies in that account using IaC.