Pedrum Jalali

When most companies start out, they usually have a single AWS account. This account is used for development, QA, staging and production. There is normally just a few engineers on the team and they all probably log into this account using the root credentials.

As the company grows not only will the number of people on the team grow but also the number of AWS accounts. It will no longer be viable to have all environments using the same account. QA will have a separate AWS account from production and staging. As different teams are formed within the company each responsible for a different service it wouldn’t make sense for all these teams to share the same AWS account. New AWS accounts will be opened to create separation between services. Things can get even more complex as you start creating regional builds each introducing more accounts to manage.

Now imagine you have 100s of AWS accounts and 100s of employees. How do you manage permissions? Accounting should have access to billing but they shouldn’t be able to spin up a new EC2 instance. You probably want developers to have admin access to QA environments but only select few should have admin access to production.

How do you manage all of this?

AWS SSO

AWS SSO really helps in the situations described above. In such cases you will normally have a separate gsuite account for each of the employee in your company. They will each belong to different groups in gsuite. These groups help break down organizations. For example there might be a group for the  billing department, another group for developers.

After integrating with AWS SSO (for instruction see https://aws.amazon.com/blogs/security/how-to-use-g-suite-as-external-identity-provider-aws-sso/) you can manage the level of access members of each group have to each account.

Simple Example

I’ve setup a simple example with an organization that has 4 AWS accounts and a single gsuite user and group.  The image below shows the organization I’ve setup for FaxDroid

main is the organization owner. prod, qa and dev are all other accounts that have joined the organization.

There is a single gsuite account called [email protected] and a single group called developers. As the company grows you would be adding more gsuite accounts.

Note that the accounts [email protected], [email protected], [email protected], [email protected] are very different than [email protected]. The first four are AWS accounts. The later is a user account. Once everything is setup if you visit the AWS SSO console you will see the accounts that belong to the organization:

You can next setup permission sets. Permission sets are effectively the different permission users can acquire when signing into an account. For example you could create a permission set specific to users in accounting. This permission set will only allow access to billing information. Another permission set could grant read access to logs and dashboards only. In my example as I was the only member of the organization, I created a single Admin permission set:

You can next create groups in AWS SSO. Unfortunately there is no official support yet to automatically sync gsuite groups with AWS SSO groups. As of writing this however there is ongoing work in this direction and also some workarounds for syncing the groups (https://aws.amazon.com/blogs/security/how-to-use-g-suite-as-external-identity-provider-aws-sso/). I’ve added the single user [email protected] to the group developers:

Next you can assign groups to accounts along with the permission sets that can be acquired. In this example the Developer group was assigned to all accounts with the permission set Admin:

AWS SSO will provide you with a URL to share with your employees. After visiting this URL, AWS SSO first redirects users to the google sign in page:

After completing this users will be redirected to the AWS SSO sign in page. The available accounts the user can login to and the permissions they will acquire will depend on the settings that have been set in the previous sections: