Page Comparison

Keys may need to be changed for any of a host of reasons, this page will offer a general guide for when, why, and how to rotate IAM keys.

Causes:

Currently we do not engage in regular key rotation. AWS recommends keys be rotated every 90 days but that is not needed given our small and stable environment. Keys may need to be rotated for a few reasons

...

Normally only the vulnerable keys (i.e. keys that the person could access) need to be rotated, but Amazon has an internal policy requiring all keys be rotated if one of them is compromised. In public leaks this is required, in other cases use best judgement if that should be followed.

Risk Assessment:

When a key is placed at risk, the first step is to determine the affected resources and risk it poses. While this cannot be broken down into a simple flow chart, a few key steps will help cover most of the issues.

1. Log onto AWS and go to the IAM (Identity Access Management) section
2. Select the Users section
3. Search by Access Key or Username to find the affected Key(s)
4. Assess the likelihood that the leaked keys can be gained by a malicious actor.
5. In the Permissions Tab, look at what policies or groups are attached.
   1. Read each permission to assess what types of access the key has
      1. Full Admin access or IAM edit access are instant red flags, these can elevate themselves.
      2. Access to production is another red flag.
      3. Access to broadly edit a class of resources (S3, EC2) is another serious risk.
6. Using a combination of 4 and 5, make an estimate of the danger.
   1. Work out with other technical team members and stakeholders if this is worth downtime in affected resources.

Rotation:

Currently (7/17/19) a shared list of keys and all use locations is not on the wiki though one will soon be added. We should also add data in the keys themselves to help track use location.

1. Find out where the key is used.
   1. Ansible's group_vars/vault has most of the keys and you can then rapidly search to see where they are used
   2. Capistrano's aws_credential file is another spot
   3. Local server(s) with access to AWS resources are also a place to look (dubnium, and cloudberry)
2. If the threat assessment shows you do not need to risk downtime
   1. In IAM (https://console.aws.amazon.com/iam/home?region=us-east-1#/users ) go to the affected key and the Security Credentials tab
   2. Generate a new Access Key
   3. Download/save the access key CSV to share as needed
   4. Update the access key (may require running ansible updates after editing the vault file or changing server config files)
   5. Check that the old access key(s) are removed
      1. If not in ansible, the places to check are Cloudberry, Dubnium, capistrano's aws_credentials, or on your own personal AWS configuration file(s)
   6. Set the old access keys to inactive with the Make Inactive link, which disables them. They can easily be reactivated if a problem occurs.
   7. Check that service functions normally
   8. Delete the old access keys.
3. If the threat assessment shows that we can risk downtime, first disable the affected key.
   1. If a production server will be broken, set maintenance mode or a downtime server to let users know service is disrupted.
   2. Then follow steps under 2.