The team I was working with had responsibility for seven AWS accounts. Some accounts hosted production workloads, some were used for development and staging. As a result, there were several painful problems we encountered.
On boarding team members
When a new team member started, we had to create IAM users in every account they required access to. In most cases this was all of them.
Having to manage seven different passwords in your password manager to log into the AWS console is not fun. Managing seven different MFA tokens is even worse.
Managing access keys
Similar to passwords, having lots of different sets of access keys makes it hard to ensure they are tracked and secured appropriately.
As an APRA regulated entity, my client has to follow APRA risk management guidelines. One of which relates to reviewing who has access to which environments. With IAM users spread across lots of accounts, this was not an easy task.
Identity Accounts to the rescue
None of these problems are new. AWS know this and have previously published an article on how to approach various problems with using multiple AWS accounts: Link
The section of interest for this discussion relates to identity accounts.
An identity account manages all of the authentication and authorisation for users, so the other AWS accounts don’t have to. This means team members would only need to log into the identity account, and the identity account would take care of granting access to all of the other accounts. The implications of this are:
- Each team member only needs to manage one password and one MFA token.
- On boarding and off boarding of team members takes far less time and is less error prone.
- Auditing account access can be done from one place, the identity account.
Design of the bakery
I won’t delve too far into the implementation and design of our identity account solution here, but I do think it’s worth mentioning how we arrived at the name “Bakery” for the identity account we built, and “Burgers” for the accounts you are granted access to.
For a person to access an AWS account, they first log into Bakery. Then they must choose which cross-account role to assume (a Bakery - where you get rolls!). Once the role has been assumed, they are able to access the Burger account. You can’t go straight to the Burger without first grabbing a role (because, well, then it’s not a burger).
How many roles?
How many cross-account roles are used is completely up to the needs of the team. To begin with, we tried to keep things simple an minimise the amount of roles.
Our roles were broken down according to the following attributes:
- The environment of the accounts the role grants access to.
- The access level the role gives to that account.
Our environment breakdown looked like this:
- Development - accounts that were used for development.
- Management - accounts that hosted production tooling such as build pipelines.
- Production - accounts that hosted production workloads used by customers.
On the access level side:
- Read only - cannot change any aspects of the account.
- Power user - can modify and create resources in the account.
- Admin - can modify and create resources as well as modify account permissions.
The combination of roles and access levels gave us nine roles to use for controlling a users account access.
Using the Bakery
Assuming the roles can be done via the console or command line. For command line access, the team created a script that when run, would list all the roles you had access to. Then assuming a role was as simple as selecting one from the list.
The Bakery was demonstrated to other teams during a weekly showcase. We received really positive feedback, and other teams were keen to spin up their own Bakery.
After successfully guiding other teams though adopting their own Bakery, making the Bakery goodness available outside the organisation seemed like a good idea. So we did!
If you are eager to grab some roles from the Bakery take a look here: https://github.com/iagcl/bakery
It’s all open sourced, so won’t cost you any dough.