What are AWS Access keys?
Automation is a must in the cloud, regardless of which Cloud Service Provider you work on. Start automation from the beginning. You can’t afford to backlog security controls anymore, especially in the cloud computing realm. In order to automate you first have to connect your tools to AWS; we can do this by creating a set of keys. This set of keys can be used for the AWS Command Line Interface (CLI). Read about CLI here. Keep in mind this pair of keys are sensitive information. Let’s first create a set!
Install AWS CLI
It’s best to install the AWS CLI prior to creating keys so you can enter the keys into the CLI immediately.
Generate AWS Access Keys – Console
Your very first set can only be done from the console.
- Login with an account that has the correct permissions to create keys. (See IAM statement policy below)
- Navigate to the IAM service.
- Click on users -> your username and then Security Credentials
- Click on Create Access Key
- Jump into the terminal so we can enter the info directly into the CLI instead of saving the .csv file.
- aws configure –profile {account-name}
aws configure –profile master - Copy and paste the key Id
- Copy and paste the secret
- Enter region code; i.e us-east-1
- Enter output format: Either json or table or text
The statement policy below allows each user to create access keys only for themselves.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "CreateOwnAccessKeys",
"Effect": "Allow",
"Action": [
"iam:CreateAccessKey",
"iam:GetUser",
"iam:ListAccessKeys"
],
"Resource": "arn:aws:iam::*:user/${aws:username}"
}
]
}
GENERATE AWS ACCESS KEYS – CLI
Now going forward you can manage your keys with code using the CLI or any of the SDKs.
TIP: Always create a new set of keys prior to setting the existing set to inactive or delete. Otherwise you’ll have to use the console again.
You’ll need this IAM statement policy to allow rotation of keys for own keys.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ManageOwnAccessKeys",
"Effect": "Allow",
"Action": [
"iam:CreateAccessKey",
"iam:DeleteAccessKey",
"iam:GetAccessKeyLastUsed",
"iam:GetUser",
"iam:ListAccessKeys",
"iam:UpdateAccessKey"
],
"Resource": "arn:aws:iam::*:user/${aws:username}"
}
]
}
List your access keys
aws iam list-access-keys --user-name {your-username}
Create a new set of access keys
aws iam create-access-key --user-name {your-username}
List your access keys with the new one this time
aws iam create-access-key --user-name {your-username}
Delete the old access key – You should be able to get the key id from the previous command. Look for the “CreateDate” that has the oldest timestamp.
aws iam delete-access-key --access-key-id AKIDPMS9RO4H3FEXAMPLE --user-name {your-username}
For more details refer to the original AWS documentation.
Rotate keys regularly
Let’s say you accidentally put your access keys in your GitHub repository that’s public. If no one yet discovered your keys and you don’t want to scrub your entire repo to find those keys then just rotate them. This way the old set is useless and you’ll update your code so that in the future your new set is not in code. No need to go back and scrub the old set.
One way to set notifications for rotating is using AWS Config. I’ll set this up later. “access-keys-rotated” is the name of that AWS Config rule. You can setup SNS notification as the remediation for this rule to let you know when someone’s access keys are older than X amount of days.
Script
A good friend (Tim) who’s also a Cloud Engineer has written a script that can rotate the keys as described above.
Link: https://github.com/easttimor/aws-scripts/blob/master/aws_rotate_access_key.sh
Usage:
Execute:
# Assumes the default profile
# ./aws_rotate_access_key.sh
#
# For a specific profile
# ./aws_rotate_access_key.sh -p abc
#
# For a specific profiles
# ./aws_rotate_access_key.sh -p abc -p def
#
# For all profiles
# ./aws_rotate_access_key.sh -a
#
# Description:
# Creates a new access key and deletes the old one
Never share
Each person that needs keys should have their own keys, do not create shared keys! Don’t share personal keys with third-party vendors and software. Everything is logged in AWS, any calls with your personal keys are your responsibility!
Never use in AMI’s or EC2’s
A lot of rookie’s make this mistake! Don’t ever use your personal keys to make CLI calls from an EC2, you must use IAM roles for that. On top of that, engineers creates AMI’s with those personal keys so they can build bootstrap solutions, so bad!
separate personal & service keys
I know these days using IAM roles with multi-account architecture are limited with some third-party software. Or setting up IAM roles for cross account is too complex for beginners so creating keys is the fastest solutions. Create a service user like “service-{software-name}” or “service-ansible”, create a group like so “service-ansible”, place that user in that group. Then create the minimum IAM policy and attach to the group. Lastly, generate keys for the service account.
- Disable console login
- Set MFA for the account
- Tag the account
TIP: Naming convention is very important for resource management and security purposes.
Delete AWS access keys
Monitor all AWS access keys; specifically if it’s not being used at all. Delete them and create them when it’s needed. On the Security Credentials tab, the “Last Used” will either be N/A or a timestamp. N/A obviously means it’s been never used. The Credential Report also lists unused access keys. You can automate this process by using the API/CLI command to view the “LastUsedDate” with the “get-access-key-last-used” and apply simple date logic. I’ll create this automation with Ansible later so be sure to subscribe to get notified.

AWS CLI cheat sheets
Be sure to checkout the cheat sheets at the Download page on this site.
As always if you see any errors, mistakes, have suggestions or questions please comment below. Don’t forget to like, share, and subscribe for more!
Published by