Configuring AWS Credentials with Access Keys, Secret Keys, and IAM Roles

Marcus Bastian amazon-web-services May 9, 2018 | 0

AWS Credentials - IAM Access Keys and Secret Keys

Configuring Access Keys, Secret Keys, and IAM Roles

So you’re brand new to AWS and you’re looking to find out how you can use the AWS CLI or scripts to interact with AWS‘s APIs. It’s not nearly as difficult as it may seem, and you can get a workstation set up with AWS Credentials in just a few minutes (I mean it. Really!).

For local workstations, in order to interact with the API, you’ll want to create an access key and secret key under your IAM user. If you’re working with multiple AWS accounts and you have an IAM user in each account, you’ll need separate access/secret key pairs for each. Along with those key pairs, you’ll need separate AWS profiles for each. We’re going to cover that below, don’t worry.

In many organizations, the typical user model is like so: IAM users for folks are created in the development/test account, and IAM roles are created in the production account. This means that your dev IAM user has access to ‘assume’ the role in the production account.

In layman’s terms, this simply means that you can put on another hat which extends the functionality of your user to another account. I’ll cover this more in-depth in the IAM roles section below.

Just to give you a quick overview of what we’re going to cover:

Installing the AWS Command Line Interface (CLI)
How to create an access key and secret key in IAM
Downsides to Using Access Keys
What are IAM Roles and When to Use Them
How the SDK Knows Where to Look For Credentials
IAM Roles Use Cases
Configuring AWS Credentials and Profiles for AWS CLI and SDKs
Configuring AWS Credentials to Leverage an IAM Role
IAM General Best Practices

Installing the AWS Command Line Interface (CLI)

Depending on your operating system, the method by which you install the AWS CLI differs; who would have thought?

I’ll spare you the minutia here, but here are a few links where AWS has clearly outlined the steps needed.

Official AWS CLI Installation Guides:

Windows Installation
Linux Installation
MacOS Installation

How to Create an Access Key and Secret Key in IAM

The process for creating an access key is straightforward. Jump into the IAM console and find the user you want to create the access key for. Next, you’ll click the “security credentials” tab and then click the “create access key” button. I recommend downloading these credentials; AWS provides you with a CSV file that details the access key and secret key.

Important note on security:

It’s worth mentioning that anyone who has your access key and secret key will be able to perform any operations that your IAM user can. This is why it’s imperative that these credentials don’t end up unencrypted in a Git repository.

See the video below for a visual walk-through of this process.

Configuring AWS Credentials and profiles for AWS CLI and SDKs

Once the AWS CLI is installed, you can quickly get your Bash, PowerShell, Python or other scripts properly authenticating with AWS‘s APIs. Check out the video below for a visual walk through.

I’ll also be detailing some more advanced configurations below that leverage multiple profiles; some of which leverage an IAM role.

Downsides to Using Access Keys

There are some downsides to using access keys that you should be aware of:

Access keys should be rotated every so often, delimited by a time frame. Many people in the community employ policies that require access keys be rotated every 90 days.

Access keys should also be rotated when employees that have access to them leave the company. Just some food for thought: if an access key isn’t rotated in 3 years, how many potentially disgruntled employees could still use these credentials from home? Depending on the nature of the keys, if someone acted out after exiting the company, the business impact could be severe.

In terms of applications running in AWS, access keys and secret keys should be a last resort. AWS has a solution to many of the problems surrounding access keys; enter IAM roles!

What are IAM Roles and When to Use Them

Simply put, an IAM role is a type of identity in AWS that is granted certain permissions per any attached IAM policies. Other identities can leverage these permissions granted by assuming the role. These identities could be users in another account, or an Amazon service itself. For example, a Lambda function’s execution role.

How are they different from access keys?

Under the hood, IAM roles still use access keys, but AWS manages rotating them for you. IAM roles are also nice from a code perspective because they allow the code to be more dynamic in terms of credential discovery. In this case, being less explicit is beneficial.

Caveats:

In some code patterns, using the temporary access keys provided by an IAM role might cause unexpected problems.

Example Scenario:

Let’s say you have an EC2 instance that runs a web application that requires write-access to Amazon S3. Locally, the developers use access keys and secret keys to test the code. The code is written such that it retrieves AWS credentials from the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables.

Note:

If an application’s AWS service client object is constructed in such a way that it specifically supplies an access key and secret key (as is in the below), there are some downsides.

No one with a local AWS config (~/.aws/credentials) would be able to use the application without additional configurations. See below for a code sample and scenario that illustrates what I mean.

Here’s what the constructor that’s specifying an access/secret key in code looks like:

# Less flexible
client = boto3.client(
    's3',
    aws_access_key_id=ACCESS_KEY,
    aws_secret_access_key=SECRET_KEY,
    aws_session_token=SESSION_TOKEN,
)

Instead, we can write our code like the below so that it will use the credentials provider chain to look for credentials in various locations, in a particular order (more on this below).

#!/usr/bin/python
import boto3
# More flexible
# Works with access keys and IAM roles, right out of the box!
client = boto3.client('s3')

For more information on using the Python Boto3 SDK for AWS, check out another one of my blog posts.

How the SDK Knows Where to Look For Credentials

The order in which the SDK searches for AWS credentials is established based on the credential provider chain you’ve chosen. We won’t get into that too much here, but it’s worth mentioning that things are sought in a certain order and that AWS will take the first set of credentials it finds.

IAM Roles Use Case: AWS SDK / CLI

Let’s say your user has permission to assume a role that gives it access to resources in production. You want to be able to leverage your role via the CLI.

Here’s an example ~/.aws/credentials file that would accomplish this.

[default]
region=us-east-1
aws_access_key_id=AKIAJLSYG5DZ73YABKZQ
aws_secret_access_key=0sStvPECqpRBFnL4w64MRxkj3upbgZ+LZH4R0yQk

[profile production]
# The IAM user that the access keys above reference must have permission to assume the role.
role_arn = arn:aws:iam::555555555555:role/ProdAccountRoleName
source_profile = default

If you’re running Mac or Linux, you can leverage this role by exporting the AWS_PROFILE environment variable prior to running your command, or like so:

#!/bin/bash
# Assumes the role specified in the 'production' AWS profile
AWS_PROFILE=production aws s3 ls clouductivity-demo-bucket

IAM Roles Use Case: Cross-Account Access

So we’ve established that EC2 IAM roles are ideal for applications running inside AWS, but they can also be used for other purposes. For example, if you wanted to allow users in your DEV AWS account to be able to perform certain operations in your PROD account, you might consider doing the following.

Create an IAM role in PROD, specifying the DEV AWS account number as a ‘trusted entity’. See below for example trust relationship.

Just establishes that admins in the DEV account can delegate access to this role to DEV account users

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::555555555555:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Create an IAM policy in the DEV account and attach it to users that are allowed to assume the role. Here’s an example policy; just fill in the PROD account number and role name.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws:iam::555555555555:role/ProdAccountRoleName"
  }
}

Best practices

Here are some best practices when it comes to IAM Users, Access Keys, and Roles:

Rotate your access keys every 90 days
Don’t share your personal access key with anyone
For Linux/Mac, secure your AWS credentials file like you would a private key (chmod 600 ~/.aws/credentials)
Use IAM roles wherever possible
Suggestion: Don’t make your production AWS profile the default, if possible
Require MFA in order to assume a role in your production account
Implement a password expiration policy
Do store your IAM user password in a secure place (i.e. not on a sticky note)

Whether you’re getting your feet wet with AWS or you’re an advanced user, Clouductivity Navigator can help you be more efficient in AWS. Save yourself some time and clicks; take advantage of our free trial offer now.