AWS access keys — 5 Tips To Safely Use Them.

Lou (🚀 Open Up The Cloud ☁️) - Sep 20 '19 - - Dev Community

AWS Access Keys are how you can programatically access the AWS cloud. AWS Access Keys can be used to provision, update — or even delete cloud resources. When it comes to your cloud account, personal or work you don’t want your account to be compromised — it could cost you at a minimum thousands of pounds. So keeping your AWS Access Keys safe is paramount.

Managing your AWS Access keys isn’t as scary as it first seems. With a little knowledge you can experiment and build software in the cloud, all whilst staying safe.

By the end of this article you should know what AWS keys are, why they’re important and five tips you can use to make sure you’re safe when using your access keys.

What Are AWS Access Keys?

As always, let’s start by discussing what AWS access keys are in the first place.

When you need to access AWS via their API, you’ll need to use an access key and secret. The two bits of information for the key are: AWS_ACCESS_KEY_ID and an AWS_SECRET_ACCESS_KEY.

Your access key can be seen in plain sight, as it is used to identify which key made a transaction. The secret however, is like a password and must never be given to anyone and you won’t see it shown on any interfaces except when it is first given to you.

An access key is associated with a given user, and that user is given a set of permissions for what it can do. Importantly, to note is that access keys don’t automatically expire.

Why Would Someone Want Your AWS Access Key?

It might seem odd that someone would want your keys in the first place, right? After all — maybe you don’t have anything interesting in your AWS account. Which begs the question: why would anyone want your AWS Access Keys?

And there are many reasons, but let me give you just one that will apply no matter what you’ve got in your AWS account — and that reason is: access to free resources. Even if you have nothing of interest in your AWS account, since you’ve likely got active billing details that means a would -be hacker has the opportunity to utilise your account to launch resources all funded by you — urgh.

Hopefully I’ve convinced you (read: scared!) you enough that you realise this is an important topic. So lets’ get to the tips!

1. Don’t Use Your Root Account AWS Access Key

AWS IAM Dashboard

When you first login to AWS you’re given a root account, by default this user is given full access rights to the whole of AWS. The first thing you want to do is create another user with more limited permissions, store the details of your root account somewhere safe, and then never use them again.

(Read this article for more details on how to securely setup your AWS account)

2. Keep AWS Access Key Permissions Limited.

Giving Access Permissions To AWS Access Keys

Following on from the point about root access keys, when you setup a key you should use keys that are related to users with limited access. When you’re working with AWS it makes sense to create a user (or users) that has limited access only to the services you need at the time. The more privileged your access keys, the more vigilant you should be with them.

3. Refresh / Rotate Your AWS Access Key Often.

AWS Interface To InActivate Keys

It doesn’t hurt to rotate your keys every now and then. It might seem scary, but if you keep your keys only locally it’s a two minute job to swap them over. Just jump into the AWS console, delete your old key and download a new one. By rotating your keys if an old one did get leaked somehow by accident you’re going to block any future access by generating a new key.

4. Don’t Put Your AWS Access Key In Code.

Using Git Staged Commits

Whatever you do with your keys, don’t put your keys into your code anywhere. Be very careful when you commit. If you’re using git, I recommend getting into the habit of committing using the git add -p command which allows staged commits. Staged commits allow you to step through your code chunk by chunk selecting what to put in. Working this way makes it a lot less likely you’re going to add anything you didn’t mean, by accident.

5. Use Bash Sourcing For Your AWS Access Key

Process For Storing AWS Keys Locally

When it comes to keeping your keys on your machine, you’ll want a solid process to store and use the keys. Personally, I use the bash sourcing feature, which allows you to execute a script within your current terminal process. This is useful as it allows you to set your current environment variables (your AWS keys) for immediate use.

I have several files, for different projects or different access keys, and I run the source command to switch between these profiles. An added benefit (in my eyes) is that it forces me to run a source in a terminal window before I can start work, so I have to explicitly “authenticate” my current process. If you want to use the same process…

  • Choose a directory to store the keys — I use my home directory cd ~
  • Create a new file touch .example — name it what you like!
  • And a line in the file export AWS_ACCESS_KEY_ID=YOUR-KEY for your access key.
  • And another line export AWS_SECRET_ACCESS_KEY=YOUR-SECRET-ACCESS-KEY for your secret key

Your AWS Access Keys Are Now Safe

That’s it — a quick run through of what AWS keys are and how you can use them safely. There’s no real need to be afraid of them. Just ensure you don’t have keys with broad permissions, avoid putting them in code and rotate them often just to be safe.

Have you ever made a mistake setting up your AWS Access Keys?


The post AWS access keys — 5 Tips To Safely Use Them. appeared first on The Dev Coach.

Join the community of cloud native software engineers just like you. Keep up-to-date with the latest in cloud tech and learn fundamental skills on core cloud engineering topics like: Docker. Serverless and Linux, and more.

Join us and get ahead!

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .