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

Your Cloud and Infrastructure-as-Code Expert.

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

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.


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.


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(

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).

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.


[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:

# 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.

  1. 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"
  2. 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.
  3. {
      "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.


    Clouductivity - Marcus Bastian About the Author

    Marcus Bastian is a Senior Site Reliability Engineer that works with AWS and Google Cloud customers to implement, automate, and improve the performance of their applications.

    Find his LinkedIn here.

    Clouductivity - AWS Solutions Architect Professional Certification - Marcus Bastian