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:
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
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.
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.
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!
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:
#!/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.
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.
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
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.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::555555555555:root" }, "Action": "sts:AssumeRole" } ] }
{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::555555555555:role/ProdAccountRoleName" } }
Here are some best practices when it comes to IAM Users, Access Keys, and Roles:
chmod 600 ~/.aws/credentials
)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.
--I work at a staffing agency. Day in and day out, I get to hear our recruiters prep candidates as…
Getting into DevOps is like any other career, in the sense that it is a life-altering decision - and, with…
If you've managed PostgreSQL databases in the past, you know how important it is to have proper monitoring in place…
Not too long ago, I was searching for information on the AWS Solutions Architect Professional certification exam. I was trying…
So you've launched a new application in production, and your applications are performing snappily as you might expect. The cloud…
It's Not Easy Doing Everything There's an oft-circulated image in the technology sector - a company looking for a Swift…