Get Baking

On a roll - our client releases their second project to open source.

As the number of AWS accounts a team uses increases, so does the headache of access and credential management. Identity accounts can help. We called ours Bakery.

Henrik Axelsson

Accounts everywhere

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.

  1. 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.

  2. Managing passwords
    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.

  3. 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.

  4. Auditing access
    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 published an article on how to approach various problems with using multiple AWS accounts: https://aws.amazon.com/answers/account-management/aws-multi-account-security-strategy/

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:

  1. Each team member only needs to manage one password and one MFA token.
  2. On boarding and off boarding of team members takes far less time and is less error prone.
  3. 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:

  1. The environment of the accounts the role grants access to.
  2. The access level the role gives to that account.

Our environment breakdown looked like this:

  1. Development - accounts that were used for development.
  2. Management - accounts that hosted production tooling such as build pipelines.
  3. Production - accounts that hosted production workloads used by customers.

On the access level side:

  1. Read only - cannot change any aspects of the account.
  2. Power user - can modify and create resources in the account.
  3. 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.

Open sourcing

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.

Contact us

We will get back to you within 24 hours.