9 May 2020

Managing Multiple AWS Accounts using the CLI

Let’s face it, whenever you use AWS, inevitably one day you will need access to the AWS Command Line Interface (CLI). And although a single account setup is pretty straightforward, a secure setup with SAML, AWS STS using an Identity Provider (IDP) and for multiple accounts is far more complex.

As an answer to this problem, IDP’s often provide tools to securely access a cloud provider. In this article, I will focus on both AWS as the cloud provider and OneLogin as the IDP to get proper access to the AWS CLI.

Hey, How, wait a minute: IDP, OneLogin… what are you talking about?

So, an identity provider is just a system entity that creates, maintains, and manages identity information, it offers user authentication as a service. Other applications relying on it, such as web applications or a cloud provider like AWS, outsource the user authentication step to this trusted identity provider.

At its core we use an IDP to avoid user management in every single application. We want single sign-on (SSO) for our users. This makes it easy to enable user access for every application in a single place when onboarding people and revoking access in case someone leaves.

Answering the question about OneLogin is rather easy now, it’s the IDP which was chosen by DPG Media.

So What’s the problem exactly?

The first issue we stumbled upon with the tools provided by OneLogin to access the AWS CLI was ease of installation (or the lack of it to be more precise).

In a company with a BYOD (bring-your-own-device) and CHOW (choose-your-own-device) policy, devices are like snowflakes (i.e. they’re all a bit different). With that in mind the last thing you want is a different install workflow for each device or even worse: things to get broken with every upgrade.

On top of this, the AWS landscape within an organization will most likely consist of multiple AWS accounts instead of just one. So we want accessing the right account to be easy-peasy, a choice list with just the account’s identifier will not work when you have access to a dozen accounts, a list using account aliases is by far a better choice.

Meet MASL

Not finding a tool available to deal with the above problems (easiness of install and management of multiple AWS accounts) ,we decided to write a tool ourselves. Enter MASL: https://github.com/glnds/masl.

MASL Logo

With the mindset of a polyglot we strongly believe the open source programming language Go was the right pick for the job. Why you ask? The big advantage of using Go in this context is its artefact type: Go binaries. When you build a Go program it results in a single binary, both small and self-contained, and that’s all you need to tackle the problem of ease of installation.

Besides choosing Go, our main focus during development was multi account support. With that in mind, account aliases and account grouping was built in from day one. Let’s look at this in practice to give you a better idea of MASL’s workflow.

Getting started with MASL

Installation is very easy, everything is described in detail in the README on GitHub. Basically, all you need to do is to download the binary to a directory somewhere in your PATH and adjust the masl.toml config file. In case you struggle to get things running within minutes, be sure to check out the FAQ, it tackles the most common issues.

Diving a bit deeper into the config

Besides installing the binary you also need to do some configuration. All config is done in a configuration file named masl.toml in your home directory. If you’re not familiar with TOML files I can highly recommend you to read a bit about it: https://github.com/toml-lang/toml. but we digress ;-)

In order to give you a head start an example config file is included in the git repository. All you have to do is: copy, rename and adjust. In this post, we will not go over every config parameter as most configuration values should speak for themselves and everything is explained in detail in the readme file. Nevertheless let us emphasize on the most important configuration parameters.

Configuring AWS_PROFILE

Behind the scenes MASL will just store your temporary credentials in the standard aws/credentials file. However, if not specified AWS will use ‘default’ as default for the variable AWS_PROFILE. MASL on the other hand will use ‘masl’ as default AWS profile name to store the AWS credentials (as a safety net for not overriding your default settings). Not using the right AWS_PROFILE value is the most common issue when things are not working as expected. To fix this do one of the following:

  • set the value of AWS_PROFILE to masl
  • in your masl.toml add the line Profile = 'default'
  • start masl with the -profile default option

Multi-Account management

One of the main drivers to develop MASL was to ease the management of multiple AWS accounts. Most of the tools currently lack those features and that makes switching AWS accounts bothersome. this is why masl.toml supports the following features:

Account naming: you can provide account names (aliases) for all accounts you have access to:

...

[[Accounts]]
ID = '1234567890'
Name = 'account-x'

[[Accounts]]
ID = '1122334455'
Name = 'account-y'

[[Accounts]]
ID = '0987654321'
Name = 'account-z'

...

Environments containing account subsets

If your account list grows too big it’s often handy to limit the list to your current work context. This can be achieved by defining environments:

...

[[Environments]]
Name = 'governance'
Accounts = ['1234567890', '1122334455']

...

Furthermore accounts can be marked as ‘Environment Independent’, in that case they will show up in all your environments.

...

[[Accounts]]
ID = '1234567890'
Name = 'base-account'
EnvironmentIndependent = true

...

Usage

This brings us to the final step usage. Just run masl on your command line.

Optional command line arguments:

-account string
      AWS Account ID or name
-env string
      Work environment
-legacy-token
      configures legacy aws_security_token (for Boto support)
-profile string
      AWS profile name (default "masl")
-role string
      AWS role name
-version
      prints MASL version

You’re all set! As said before, you find all documentation in the readme on https://github.com/glnds/masl. Please don’t hesitate to raise bugs, ask for features or just contribute!