How to get ephemeral access keys to an AWS account using MFA

Programmatic access makes it easier to automate tasks like cloud deployments, application upgrades, learning new AWS services, running migration scripts, cloud configuration analysis, incident response, and infrastructure maintenance.

That ease of development access, however, comes at a cost. Having programmatic access turned on all the time in an organization requires a vast set of Identity and Access Management (IAM) permissions that, without proper controls in place, may present too much risk.

This post shows how you can overcome those risks by enumerating AWS best practices on access keys management.

Common security risks with IAM access keys

1. Cryptojacking: Usage of access keys to utilize cloud compute resources to mine cryptocurrencies.
2. Data exfiltration: Once access keys are compromised, data resources or compute resources with access to those might be compromised as well depending on the perimeter of IAM profile. If access keys have a role that enable editing AWS Lambda and the lambda has access to RDS instance, this instance data can be compromised.
3. Malicious activity: An over permissive access key can grant access to shut down instances and cause downtime to an application.

AWS IAM credentials best practices

AWS IAM is a crucial service used to grant and restrict access to AWS services and resources securely. To get programmatic access, we need to apply IAM best practices such as:

1. A user must perform an MFA challenge to get such a level of access.
2. Programmatic access must be temporary. That way, if AWS access keys do get leaked into a public git repository or unencrypted log, they will exist only in the short-term and will automatically expire after a few hours.
3. Requests for keys should integrate with our identity provider as a source of allowed users.
4. Roles must be controlled and monitored via AWS CloudTrail.
5. Roles should follow least-privilege principles, and the tool should allow you to choose which role to use, assuming each role grants a different level of access.

With these requirements in mind, there are three services that can help us:

• onelogin-python-aws-assume-role: Assume an AWS Role and get temporary credentials using OneLogin.
• Gimme AWS Creds: A CLI that utilizes an Okta IdP via SAML to acquire temporary AWS credentials via AWS STS.
• AWS SSO: AWS SSO enables developers to sign in directly to the CLI using the same Active Directory or AWS SSO credentials that they normally use to sign in to AWS SSO and access their assigned accounts and roles.

Getting ephemeral access keys

After installing one of the above tools, you can now begin to obtain access keys. I set up onelogin-python-aws-assume-role  and then started the process of obtaining temporary access keys described in the following diagram, with modified session duration to 12 hours.

Let’s run it step-by-step:

First, request AWS credentials by running:

You will then be prompted to answer the MFA challenge:

If the challenge is passed, you then select your AWS account and IAM role:

Override the AWS default profile with new temporary credentials located at ~/.aws/credentials:

Now you can run AWS CLI commands using those credentials for the following hours.

Supporting multiple AWS Organizations

One of the challenges with this approach is integrating several multi-role and multi-account configurations under several separate OneLogin applications.

This kind of configuration allows us to have multiple levels of SSO apps segregation in our organization. A typical example would be: having an SSO application for multiple dev AWS accounts and roles, with a separate SSO application for production accounts.

To enable just that, we made an open source contribution which is currently available on a GitHub fork, with a pull request open pending feedback. Using our contribution, you will be able to get time-bound access keys using SAML and an MFA application that you’re familiar with, such as OneLogin.

Following least-privilege roles in AWS

Allowing temporary roles solves a portion of the possible risk related to access. To follow least-privilege principles means that only the required access level is granted to those who need it when they need it. On an existing AWS account, we might find orphaned AWS IAM roles that are no longer in use and over-privileged roles, which can be restricted by modeling the actual usage.

To solve this next part of the puzzle, we created AirIAM, an open source tool that helps identify unused and over-privileged IAM roles.