Best Practices For Using and Protecting AWS Access Keys

Is your development team taking shortcuts with AWS access keys? Is your team passing around keys on Slack or email? If you don’t know the answer off the top of your head, it’s worth asking around. This post is for you.

Access keys (also referred to as an access token, credentials, or just keys) are used to identify a user or role when making an API call through the command line or an HTTPS request to AWS, or through a Software Development Kit like the Python SDK. You can create them after creating a user or role, and they are tied to that user or role.

After you’ve done all the work of defining Users, Groups, and Roles, you don’t want to flush it down the drain by getting sloppy with access keys. In fact, you want to follow these best practices to make the most of this powerful AWS feature.

Why is it powerful? Because with access keys, you are not limited to using AWS as just a User poking around the console. You can send complex commands through the command line, or you can program EC2 instances and Lambda functions to perform work on your behalf remotely and automatically. All the while, you have limited the resource’s access to only what is needed. This is the principle of Least Privilege Access.

But, bad things can happen if someone gets your access keys. Anyone who has your access keys can act like you unimpeded in the AWS ecosystem. So, this post is all about keeping them safe. It comes from years of working with AWS Accounts.

CloudSheriff’s best practices for using and storing AWS Access Keys

First of all, don’t create access keys for the root user, which has unimpeded Administrator Access. There really is no reason. Just create users instead. We’re not sure why AWS still allows this, but they do.
We recommend not using MFA on your access keys. That’s because you may need to run a script that calls the AWS API multiple times, and it might re-prompt you for your access keys. This is a big productivity killer. Hold back on using MFA on access keys for only the most mission-critical purposes.
Lean toward only generating access keys for Roles, not Users. Not all Users must have access keys. If they must have them, for users who are not really frequent CLI users, just have them assume a role from the CLI. There are guides for this.
Weirdly, AWS sends your access keys for a brand new user through a downloaded .csv file. If you have team members passing things around on Slack, which is common, just make sure they tuck the credentials away in the hidden files as described above, and delete it from Slack when complete.
If you lose access keys, just rotate them (meaning, delete and re-create them). There is no reason to go overboard in hanging onto them.
On that note, rotate keys every 90 days. This does a couple things. In the event that someone gets access keys like a contractor, and you forget about them, if you delete the keys after 3 months, then you are safe from the keys being re-used elsewhere. It also protects you in situations where a developer placed the keys somewhere they shouldn’t. If you’re in the habit of cycling keys often, then you are rendering useless keys that could be floating around.
When you rotate keys, try to understand where they are being used. If you have “lost” the keys or forgot where they are being deployed, things might break when you rotate keys. This is good, because now you know where you need to use a Role instead of User access keys (see below).
Store your access keys in a secure file on your desktop. Follow this pattern here: https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html This is the only place you should be saving your access keys locally.
Once the credentials are available as a “profile” on your local machine, that means anyone who logs into the machine now has access. So, you have to back up a couple steps and secure the laptop login process. For example, you can have a corporate policy that laptops lock up after a period of inactivity – so if someone steps away to the bathroom, and forgets to lock the laptop, it locks up.
You can also add MFA to your computer login. For Mac users, it’s a global iCloud setting.https://support.apple.com/en-us/HT204915 You need to completely log out of the machine in order to force a 2FA upon re-logging in.
The best keys are no keys. When using compute, instead of manually managing access keys to EC2 or Lambda, assign an execution role to the Lambda function, or an Instance Profile to an EC2 instance. In both cases, when you load an aws library like boto3, the credentials are passed automatically to the instance. That means you do not need to save the credentials anywhere, like in environment variables or in an encrypted config file.
    Another really good reason for this, is when you rotate the keys, you don’t have to go around hunting for EC2 configuration files, or Lambda environment variables, to update the keys. AWS Roles do not have keys to manage, copy/paste, or lose. You just handle the permissions directly in the role.

And the most important takeaway:

Never, ever hard-code the access keys anywhere. Not even for “dev” purposes. This is such a problem that AWS scans public github repositories to find access keys and warn users. A typical nightmare scenario often bandied about, is some bad actor found public access keys, and used them to spin up EC2 instances to mine bitcoin and send the bitcoin back to their own wallet.

Yes, this takes effort and focus. It’s hard enough to think through Users, Groups, and Roles. But now you have, quite literally, the keys to the kingdom in AWS access keys. Follow the best practices above to limit their use and exposure. If this seems like a headache, or you think you already have a bunch of keys out in the wild and need a solution to get it under control, contact us. We fix situations like this all the time.