Skip to content

Getting rid of access keys

I (Christophe) have a nasty habbit of sticking to doing things I'm familiar with and resisting change. So even though AWS has launched options that make using long-term access keys almost a thing of the past over the last few years, I still had some access keys being used for a couple of use cases. So I decided to roll up my sleeves and work on removing every long-term access key from all of my AWS accounts. Here's some advice for how you can do it too.

Alternative to access keys

Instead of using long-term access keys, we can use temporary security credentials through the AWS Security Token Service (STS).

Temporary credentials work almost the same as long-term access keys but with two major differences:

  1. Temporary security credentials are short-term and expire after anywhere from a few minutes to hours ( length of time depends). After they’ve expired, they no longer work and can’t be re-used.
  2. Temporary security credentials are generated only when they are needed instead of being stored with the user. New credentials can be generated as they expire, or even before they expire, and you don’t have to revoke them when they’re no longer needed

You can use these temporary security credentials with IAM roles and identity federation ( more info here), which means that once you get rid of access keys, you can start to get rid of (most) IAM Users.

Remove unused long-term access keys

The CIS Benchmark recommends removing access keys that haven't been used in 90 days, but that's up to your comfort level and could be shorter.

Prevent creating new access keys

This one might hurt a bit for those still defaulting to using them, but it's also a very effective approach at changing old habits. Prevent people from creating new access keys entirely.

An easy way of doing this is by creating this policy:

    "Version": "2012-10-17", 
    "Statement": { 
        "Effect": "Deny", 
        "Action": "iam:CreateAccessKey", 
        "Resource": "*" 

You can apply this as an SCP organization-wide.

This will also help protect against the iam:CreateAccessKey PrivEsc.

Remove all other access keys and IAM users

The above steps are easy wins, but this next step is where it gets more challenging. The path to being long-term access key free is to then look for:

  • AWS resources using access keys - use IAM Roles instead
  • Find external applications using long-term access keys - use IAM Roles Anywhere for workloads, and Identity Center / SSO for user access
  • Change how your humans access your AWS environments - with Identity Center
  • Prevent the creationg of new users - by applying an SCP that applies to all of your AWS accounts and that prevents iam:CreateUser

Start with removing unused long-term access keys and preventing creation of new keys first, and then go through this section. Keep in mind that some use cases may still require IAM Users, so some organizations may not be able to completely eliminate them. However, they need to become the exception, not the norm.

Example of when you may still want to have IAM Users

If you are using Identity Center with with or without an external identity provider, if you experience an outage of that external provider or Identity Center, or if for whatever reason you lose access to either of those, you will be in a very bad spot because you won't be able to access your AWS environments and resources at a time whe you might need it the most. In that case, it's acceptable to have what AWS refers to as a "Break Glass" IAM User that has access to a SecurityBreakGlass role that can access all of your AWS accounts with admin-level permissions for incident response. This is only to be used in emergencies.