Simplifying account management on AWS cloud using AssumeRole

Welcome to the first edition of our series on technology case studies from our portfolio companies.

In this post, RMC DevOps Consultant Eryk Zalejski and Quoka CTO Holger Marquetant will show you how to simplify account management on the AWS cloud using AssumeRole.

This post was also published on Medium.

Enter Eryk and Holger:

Bit of Quoka’s background

Our history reaches back to 1983. Soon we will turn 40, but it does not mean we are getting old. Our CTO Holger Marquetant is passionate about the newest technologies and we tend to always improve and modernize our platform. A few years back we started our cloud journey. First, we migrated to docker, then ECS and finally, we landed on EKS. As you may expect with all the migrations we learned quite a few things. We decided it will be great to share some of it with the world.

Multiple AWS accounts issue

During our cloud journey, we always planned to go on with as much automation as possible. We have also chosen to describe our infrastructure as a terraform code. Having everything terraformed we went with multiple AWS accounts, we wanted to separate our “PROD” “DEV” and “Other” environments as much as possible.

At first, managing users seemed easy — we defined users in our .tfvars and applied the terraform configs using separate workspaces. From the administration perspective, it seemed perfectly OK, but soon we realized it was a true nightmare to our developers and other AWS users. We ended up with a ton of AWS profiles in our .aws/credentials that we needed to maintain between console sessions and we needed to run multiple browsers or at least multiple browser profiles when working on many AWS accounts concurrently.

The solution: AWS AssumeRole

We finally discovered the AWS Mechanism that allows transferring permission from one account to another. It seemed like bingo to us! Here is the initial draft of how we planned to do this:

Putting the idea into the code

We chose to have one and only account defining our users and their roles. It basically means one user for everyone, one AWS credential and just one place to log into AWS console. Bingo right? We only define our master account and define other profiles once. This is how our .aws/credentials is looking like:

All of the user management goes to our ‘Master’ AWS admin account:

Users.tf:

Groups.tf (this example shows just one group — administrator access to prod account):

And finally group_membership.tf:

Each target (AssumeRole managed) AWS account (like “PROD” “DEV” and “Other”) needs to have such config applied in order to create “Trust” (please replace <MASTER_ACCOUNT_ID> with the ID of the account you manage your user in):

Assumed_roles.tf:

Now in order to use only quoka-master AWS profile within the shell and during our terraform plan and applies, we only needed to instrument our terraform installations to use the assume-role profile (<PROD_ACCOUNT_ID> can be used as a per workspace terraform variable i.e. ${var.aws_account_id}) :

Providers.tf:

Summary

It took us a while to find this solution. We realize that it is never one size fits all option, but if this article can help you and users within the company we will be very pleased. Quoka is part of Russmedia Group. We are a group of companies that embrace knowledge and tech sharing. We regularly meet at internal conferences and organize calls to make it happen. It is seriously pushing us forward and we are hoping to spread this kind of spirit all over the world. Let this article be the first of a long series. Enjoy!