Skip to main content

Best Practices for Managing AWS Access Keys

  • Updated

Issue / Question

Best Practices for Managing AWS Access Keys

Environment

Amazon Web Services

Best Practices for Managing AWS Access Keys

When you access AWS programmatically, you use an access key to verify your identity and the identity of your applications. An access key consists of an access key ID (something like AKIAIOSFODNN7EXAMPLE) and a secret access key (something like wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY).

Anyone who has your access key has the same level of access to your AWS resources that you do. Consequently, AWS goes to significant lengths to protect your access keys, and, in keeping with the shared-responsibility model, you should as well.

Remove (or Don't Generate) Account Access Key

An access key is required in order to sign requests that you make using the AWS Command Line Tools, the AWS SDKs, or direct API calls. Anyone who has the access key for your AWS account root user has unrestricted access to all the resources in your account, including billing information. You cannot restrict the permissions for your AWS account root user.

One of the best ways to protect your account is to not have an access key for your AWS account root user. Unless you must have a root user access key (which is very rare), it is best not to generate one. Instead, the recommended best practice is to create one or more AWS Identity and Access Management (IAM) users, give them the necessary permissions, and use IAM users for everyday interaction with AWS.

If you already have an access key for your account, we recommend the following: Find places in your applications where you are currently using that key (if any), replace the root user access key with an IAM user access key, and then disable and remove the root user access key.

By default, AWS does not generate an access key for new accounts.

Use Temporary Security Credentials (IAM Roles) Instead of Long-Term Access Keys

In many scenarios, you don't need a long-term access key that never expires (as you have with an IAM user). Instead, you can create IAM roles and generate temporary security credentials. Temporary security credentials consist of an access key ID and a secret access key, but they also include a security token that indicates when the credentials expire.

Long-term access keys, such as those associated with IAM users and AWS account root users, remain valid until you manually revoke them. However, temporary security credentials obtained through IAM roles and other features of the AWS Security Token Service expire after a short period of time. Use temporary security credentials to help reduce your risk in case credentials are accidentally exposed.

Use an IAM role and temporary security credentials in these scenarios:

  • You have an application or AWS CLI scripts running on an Amazon EC2 instance. Do not pass an access key to the application, embed it in the application, or have the application read a key from a source such as an Amazon S3 bucket (even if the bucket is encrypted). Instead, define an IAM role that has appropriate permissions for your application and launch the Amazon EC2 instance with roles for EC2. This associates an IAM role with the Amazon EC2 instance and lets the application get temporary security credentials that it can in turn use to make AWS calls. The AWS SDKs and the AWS CLI can get temporary credentials from the role automatically.

  • You need to grant cross-account access. Use an IAM role to establish trust between accounts, and then grant users in one account limited permissions to access the trusted account.

  • You have a mobile app. Do not embed an access key with the app, even in encrypted storage. Instead, use Amazon Cognito to manage user identity in your app. This service lets you authenticate users using Login with Amazon, Facebook, Google, or any OpenID Connect (OIDC)–compatible identity provider. You can then use the Amazon Cognito credentials provider to manage credentials that your app uses to make requests to AWS.

  • You want to federate into AWS and your organization supports SAML 2.0. If you work for an organization that has an identity provider that supports SAML 2.0, configure the provider to use SAML to exchange authentication information with AWS and get back a set of temporary security credentials.

    You want to federate into AWS and your organization has an on-premises identity store. If users can authenticate inside your organization, you can write an application that can issue them temporary security credentials for access to AWS resources.

Manage IAM User Access Keys Properly

If you do need to create access keys for programmatic access to AWS, create an IAM user and grant that user only the permissions he or she needs. Then generate an access key for that user.

Note

Remember that if you are running an application on an Amazon EC2 instance and the application needs access to AWS resources, you should use IAM roles for EC2, as described in the previous section.

Observe these precautions when using access keys:

  • Don't embed access keys directly into code. The AWS SDKs and the AWS Command Line Tools allow you to put access keys in known locations so that you do not have to keep them in code.

    Put access keys in one of the following locations:

    • The AWS credentials file. The AWS SDKs and AWS CLI automatically use the credentials that you store in the AWS credentials file.

      Note

      To store credentials for the AWS SDK for .NET and the AWS Tools for Windows PowerShell, we recommend that you use the SDK Store.

    • Environment variables. On a multitenant system, choose user environment variables, not system environment variables.

       

  • Use different access keys for different applications. Do this so that you can isolate the permissions and revoke the access keys for individual applications if an access key is exposed. Having separate access keys for different applications also generates distinct entries in AWS CloudTrail log files, which makes it easier for you to determine which application performed specific actions.

  • Rotate access keys periodically. Change access keys on a regular basis.

  • Remove unused access keys. If a user leaves your organization, remove the corresponding IAM user so that the user's access to your resources is removed. To find out when an access key was last used, use the GetAccessKeyLastUsed API (AWS CLI command: aws iam get-access-key-last-used).

  • Configure multi-factor authentication for your most sensitive operations.