IAM Access Keys - Does the user really require them?

I have very strong feelings when it comes to IAM Access Keys which I can sum up rather quickly - never - ever - provide Access Keys to your users - end of story.

Let me explain why I take this stance - in my experience 99% of the time the user doesn’t actually require them. Sure you have power users within the organization who want to interact with AWS via the CLI or maybe a script or two (more on that later), but in my experience the vast majority of AWS users interact with the platform via the AWS Management Console and these users do not need keys.

Here’s why IAM Access Keys are evil.

The are long-term credentials

There is no native functionally to rotate keys, therefore, it is the responsibility of the user (we know how that works) and/or the AWS Administrators to rotate the keys regularly. Some organizations do a fantastic job at this, but the majority do not. For organizations who struggle here it means you most likely have old (very old) keys in your account.

Having old IAM Access Keys in your account leads to the next issue.

Key Leakage

Key leakage is what happens when even though you did all the right things when starting your AWS Journey - like creating a best practices or strategy document - eventually an IAM Access Key (or two) will find its way outside of the organization.

Impossible you say! In our environment a key could never leak out. I’ll give you a couple of real world examples on how keys will eventually leak:

1. Someone loses a laptop with an unencrypted drive.
2. An internal script gets accidentally checked into a public GitHub repository.

Leaked keys lead to the next issue.

Practice Least Privilege

We regularly provide security audit services on AWS accounts for customers and routinely we find IAM policies that look something like this:

"Statement":[
	{
		"Effect":"Allow",
		"Action":"*:*",
		"Resource: "*"
	}
]

This kind of thing keeps me up a night. Let’s connect a few dots. You have a wide open IAM policy, which allows entities assigned this policy (via a IAM group right?) full, uncontrolled access to all AWS services and actions. Now, let’s say you’ve also assigned IAM Access Keys to a user in this group and they left their laptop on the train the other day (it happens) - see where this is going? Here is where its going - a 25K bill for a fleet of EC2 instances which were stood up in the Singapore region over the weekend for - you guessed it Bitcoin mining. Not the kinda of AWS Budget alert you want to receive - you have budgeting setup right?

Don’t give anyone any more access than they need to do their job - period. If a user needs to occasionally access a service they don’t normally need then use IAM Roles to provide temporary access to the service.

So, how do you avoid all this bedlam? Read on…

Here’s my simple two step (and a half step) plan

1. Don’t give out IAM access keys - ever. If a user says they need them make them justify their requirements before creating Access Keys.
2. Use IAM Roles for everything you can. Doing this is one of the simplest ways I have found to increase the security of your AWS account. If you run into something that cannot be done by IAM Roles find a way to use IAM Roles.

2.5: Automation is your friend. Create Lambda functions to automatically rotate Access Keys and ruthless. Active Keys should be rotated automatically, Inactive Keys (90 days or less even) disable them, and then delete them - no exceptions. By doing this you can have some comfort knowing that if 1) you have IAM Keys in the first place that 2) when they leak out of the organization they won’t be usable for (to) long.

Hard Coding Access Keys

I mentioned early on I’d talk about scripts and Access Keys. I have a pretty basic rule here as well - never - ever hard-code Access Keys in scripts - use IAM Roles instead they are much safer.

Here’s the argument I hear all the time - well its just a simple script on my laptop so what difference does it make or another favourite of mine - I needed to get it done quickly so I hardcoded the Access Keys - ugh. See my early notes about why this is a bad idea - if you’re doing this you’re setting yourself up for future discomfort.