Cloud Security Fitness Guide – Exercise #6: Rotate all the Keys Regularly

In the previous article, we had a pretty deep discussion on how and why to limit privilege in the AWS IAM service. This time, I’ll continue down the IAM path and talk a little about key management for IAM.

I’ve already discussed why EC2 instances having API access keys is a bad thing. Next time, I’ll talk about how users and other automated processes can use roles to get away from the whole key management business. However, there are some places where API keys still have to be used.

For example, if you manage a Continuous Integration tool like Jenkins outside of AWS and in your on-premise environment, there is no way you could use Roles for EC2.  You’d have to create an IAM user and generate an API Access Key and Secret key to place on that Jenkins server.

AWS recommends that as a best practice that all credentials, passwords and API Access Keys alike, be rotated on a regular basis. If a credential is compromised, this limits the amount of time that a key valid for.

One best practice I followed was that API Access keys were to be rotated every 90 days. My process was simple, but burdensome: 1) An operator tracked the age of an Access Key; 2) The operator created a new Access Key; 3)

The operator then supplied the new Access Key to the automation process; 4) After testing and deploying, the old Access Key was deactivated. Eventually, or at next rotation, the old Access Key was deleted. This process can be made easier with encrypted data snippet mechanisms like Chef’s Encrypted Data Bags.

The AWS Security Blog has a great article outlining a very similar process, and in that process they describe how to get the age of API Access Keys using the AWS CLI iam list-access-keys command.

I find another pair of AWS CLI commands to be useful for getting the age of all users’ (including the Root account user’s) API Access Keys age and other credential data: iam generate-credential-report and iam get-credential-report.

The Credentials Report page describes all of the fields that come out of the generated CSV file. The CSV data is base64 encoded, so you’ll have to do some Linux command-line wizardry to get the data out:

Sample Credential Report Output Sample Credential Report Output

As you can see, the IAM Credentials Report gives me a different view of API Access Key Age from all IAM users in my AWS account.

A quick recap of our past AWS Best Practice posts:

  1. Disable Root API Access Key and Secret Key
  2. Enable MFA Tokens Everywhere
  3. Reduce Number of IAM Users with Admin Rights
  4. Use Roles for EC2
  5. Least Privilege: Limit what IAM Entities Can Do with Strong Policies
  6. Rotate all the Keys Regularly
  7. Use IAM Roles with STS AssumeRole Where Possible
  8. Use AutoScaling to Dampen DDoS Effects
  9. Do Not Allow Unless You Mean It
  10. Watch World-Readable and Listable S3 Bucket Policies