Remote Access Using SSH Cryptographic Keys
To use AWS programmatically, the caller must provide credentials to verify their identity. In most cases you will want to use temporary credentials, but some situations may call for use of a longer-term credential (i.e. AWS IAM Access Keys). Access keys consist of two complex strings: the access key ID and paired secret access key, which work together like a username/password to authenticate requests.
Anyone who has your access keys has the same level of access to your AWS resources that you do. Consequently, organizations should go to significant lengths to protect access keys.
The most important governance control for AWS IAM Access Keys is to ensure they are periodically rotated based on your company policies to avoid risk exposure. We will look at rotation best practices and see how Turbot Guardrails can help you enforce them.
Best Practices
Our simple shortlist of IAM access key best practices:
Root User: Never create access keys for root user.
CLI/API: Use temporary STS generated credentials.
Instances, containers, Lambda functions: Use IAM role-based access.
Don’t use static access keys.
The bottom-line is that the “best practice” is simply not to use access keys. However, we don’t work in a perfect world, so we need compensating controls for the access keys that do exist in our environment.
Compensating Controls for the Real-World:
Do not allow IAM users to have console access and access keys.
Limit your exposure blast radius by micro-segmenting your AWS accounts.
Only allow static access keys via an approved exception process.
Design any attached IAM policies as “least privilege”.
Treat access keys as an elevated access credential, and rotate frequently.
Requiring an exception, ensuring least privilege and enforcing rotation of access keys will ensure that teams are thoughtful in their use of access key capabilities. While all of these best practices can be enforced by Turbot Guardrails.
This post focuses on automation of credential rotation.
Once you have made the decision to allow access keys, ensuring that they are rotated is the most critical governance control to automate.
With Turbot Guardrails, you can use our active guardrails to identify if a resource is in active use. Once Turbot Guardrails automation identifies a resource (e.g. an access key) as inactive, it has the ability to remediate it with complimentary corrective controls (or alert you with detective controls).
“Active” type policies have defined sub-policies (that you configure) that Turbot Guardrails uses to determine if the resource is active or inactive. Common “Active” sub-policies are Age, Recently used, Last modified, etc.
Example: Setting “Active” policies in the web console.
Create a new policy to force the access key to “inactive” state if it is older than 90 days:
Create a new policy to take corrective action for resources that are in an “inactive” state:
After setting these policies, Turbot Guardrails automation will identify all access keys that are older than 90 days, and then handle remediation (access key deletion) with a configurable warning period. To evaluate the impact of setting this policy in your environment we suggest setting the value to Check: Active at the Turbot level, which will alert you to any old keys. You can then selectively apply enforcement settings to development and/or sandbox environments to gain confidence in how the corrective controls work.
Make it happen!
See for yourself how easy it is to expire aged access keys with just a few clicks. Terraform templates with policy examples for how to do this example above, including “Recently Used” conditions are available in the Turbot Development Kit (TDK). If you need any assistance, let us know in our Slack community #guardrails channel. If you are new to Turbot, connect with us to learn more!