How to Keep AWS Access Keys and Other Secrets Safe
Information security in the cloud depends on the proper management of secrets, including AWS access keys. Authorized users and code must authenticate to use cloud resources. Authentication relies on shared secrets, but shared credentials may create security vulnerabilities, especially when they are shared naively by embedding them in application code.
Embedding AWS access keys in code seems an efficient solution when, for example, your code needs to interact with the S3 API to store data in a bucket. However, doing so exposes the keys to anyone who sees the code. AWS keys have often been exposed in this way when code is uploaded to version control services like GitHub. However, code needn’t be exposed publicly for embedded access keys to cause a vulnerability. Anyone inside the company with code access can view credentials they may not be authorized to use, undermining authentication and access control strategies.
In this article, we explore secure alternatives to embedding AWS access keys and other secrets in code.
What is an AWS Access Key?
Access keys are AWS’s primary long-term credential for programmatic authentication. An AWS access key consists of an access key ID and a secret access key; together, they authenticate requests to AWS APIs, allowing users to interact with AWS services from their code, including via AWS CLI clients and SDKs.
AWS access keys are associated with users in the AWS Identity and Access Management (IAM) platform. Because they are the programmatic equivalent of a username and password, they should be protected with the same diligence. Just as you wouldn’t embed your password in code, you should not embed your access key.
How to Manage AWS Access Keys Securely
We’ll look at two ways to manage AWS access keys securely. The first is to avoid using them altogether, instead using temporary security credentials associated with AWS roles. The second takes advantage of AWS features to use access keys without exposing them needlessly.
But before we get to secure key management, a word of warning about the root users’ access key. The IAM root user has unconstrained access to every AWS resource. A bad actor may shut down servers, delete data, create and destroy users, or any other AWS API capability with the root user’s key. For this reason, you should not use the root access key, and you should disable root user access keys already in use. In fact, it is good practice to avoid using the root account unless it’s strictly necessary, as we discussed in 10 Top Tips For Better AWS Security Today.
IAM Roles vs. IAM Users
An IAM role is an AWS identity with a set of permissions for making requests to AWS resources, but, unlike AWS users, roles are not associated with an individual. Users and applications can “assume” an IAM role, which allows them to take on the role’s permissions. Another way of putting it is that roles enable AWS customers to delegate permissions to other entities.
Roles have a couple of major advantages. First, a role can be attached to entities such as EC2 instances. That means the EC2 instance can request resources in line with the role’s permissions, obviating the need to embed an IAM user’s AWS access key in the code. Second, roles can be used to create temporary credentials. IAM access keys are permanent until they are deleted, whereas a role’s temporary credentials automatically become invalid once a configurable time has elapsed.
Secure Use of AWS Access Keys
In some cases, you may prefer to use an IAM user’s access key instead of an AWS role, but you should not embed credentials in the code. Instead, you can safely store the access key in a location your code can read.
One option is to create an environment variable within your code’s operating environment to store the key. Environment variables are managed by the environment’s operating system and can be accessed via system libraries or the AWS SDK for your preferred programming language. Several Amazon services can use AWS Secrets Manager to retrieve secrets to inject into the environment variables of containers and other resources.
Another option is the AWS credentials file. The credentials file is a text file containing an access key. AWS SDKs and the AWS CLI will look for a credentials file and use the access key when making requests for other resources.
These methods—roles, environment variables, credential files—are appropriate for different scenarios, but the critical point is this: embedding the AWS access key into your code is a bad idea.
How To Rotate AWS Access Keys
Rotation replaces an old key with a new key and retires the old key. AWS access keys are long-lasting credentials. If exposed, they may be exploited until the user or key is deleted. Key rotation limits the usefulness of leaked keys to bad actors.
AWS users can rotate keys in IAM without interrupting their software’s access to resources. The preferred approach is to create a new access key, update software to use the new key, and then make the old key inactive. Once the user is satisfied all software is using the new key, they can delete the original. AWS access key rotation can be carried out in the IAM web console, the AWS CLI, and the AWS API.
Mitigating Risk When AWS Access Keys are Exposed
We’ve discussed ways AWS users can prevent the exposure of AWS keys, but what should they do if a key is exposed? The obvious first step is to invalidate the key immediately. However, doing so will also prevent legitimate use, which could result in service disruption. Leaked keys should be invalidated as soon as possible, but you may want to rotate mission-critical software keys first.
The exposed key may already have been used, so you must also check all resources the key grants access to. Depending on the user’s access permissions, their key may have allowed a bad actor to exfiltrate sensitive data or infiltrate malicious software. Use S3 logs and AWS CloudTrail to investigate whether the key was exploited and take action to mitigate potential risks and vulnerabilities.
Securely Storing other Secrets with AWS Secrets Manager
You may need to securely manage other secrets in addition to AWS access keys, including SSH keys, database credentials, and third-party API keys. AWS Secrets Manager provides a solution for storing, rotating, managing, and retrieving a wide variety of secrets.
For example, to give an application access to a database, you would store database credentials encrypted in AWS Secrets Manager. The application can query Secrets Manager, which will decrypt and return the database credentials over an encrypted connection. Access to data stored in AWS Secrets Manager is controlled by IAM permissions policies for users, groups, and roles, providing fine-grained access control.
To learn more about AWS cloud security, visit KirkpatrickPrice’s AWS Security Services to find a wealth of cloud security and AWS audit educational content. If you would like to discuss AWS audits with an experienced auditor, contact KirkpatrickPrice today.