Proudly written by Gert Leenders (AWS Cloud Solution Architect at DPG Media)
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) for multiple accounts is far more complex.
As an answer to this problem, IDP’s often provide tools to access a cloud provider securely.
This article focuses on AWS as the cloud provider and on OneLogin as the IDP to get proper access to the AWS CLI.
Hey, now, 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 to enable user access for every application in a single place when onboarding people and revoking access if someone leaves.
Answering the question about OneLogin is relatively easy now; it’s the IDP that 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 the 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 installing and managing multiple AWS accounts), we decided to write a tool ourselves. Enter MASL: https://github.com/glnds/masl.
With a polyglot mindset, we firmly believe the open-source programming language Go is 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 straightforward; 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 highly recommend you to read a bit about them: https://github.com/toml-lang/toml. But we digress ;-)
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.
This post 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 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. On the other hand, MASL will use ‘masl’ as the 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. You can achieve this 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!
