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
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.
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.
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.
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
- in your
masl.tomladd the line
Profile = 'default'
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 ...
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!