SEC02-BP02 Use temporary credentials
When doing any type of authentication, it’s best to use temporary credentials instead of long-term credentials to reduce or eliminate risks, such as credentials being inadvertently disclosed, shared, or stolen.
Desired outcome: To reduce the risk of long-term credentials, use temporary credentials wherever possible for both human and machine identities. Long-term credentials create many risks, for example, they can be uploaded in code to public GitHub repositories. By using temporary credentials, you significantly reduce the chances of credentials becoming compromised.
Common anti-patterns:
-
Developers using long-term access keys from IAM users rather than obtaining temporary credentials from the CLI using federation.
-
Developers embedding long-term access keys in their code and uploading that code to public Git repositories.
-
Developers embedding long-term access keys in mobile apps that are then made available in app stores.
-
Users sharing long-term access keys with other users, or employees leaving the company with long-term access keys still in their possession.
-
Using long-term access keys for machine identities when temporary credentials could be used.
Level of risk exposed if this best practice is not established: High
Implementation guidance
Use temporary security credentials instead of long-term credentials for all AWS API and CLI requests. API and CLI requests to AWS services must, in nearly every case, be signed using AWS access keys. These requests can be signed with either temporary or long-term credentials. The only time you should use long-term credentials, also known as long-term access keys, is if you are using an IAM user or the AWS account root user. When you federate to AWS or assume an IAM role through other methods, temporary credentials are generated. Even when you access the AWS Management Console using sign-in credentials, temporary credentials are generated for you to make calls to AWS services. There are few situations where you need long-term credentials and you can accomplish nearly all tasks using temporary credentials.
Avoiding the use of long-term credentials in favor of temporary credentials should go hand in hand with a strategy of reducing the usage of IAM users in favor of federation and IAM roles. While IAM users have been used for both human and machine identities in the past, we now recommend not using them to avoid the risks in using long-term access keys.
Implementation steps
For human identities like employees, administrators, developers, operators, and customers:
-
You should rely on a centralized identity provider and require human users to use federation with an identity provider to access AWS using temporary credentials. Federation for your users can be done either with direct federation to each AWS account
or using AWS IAM Identity Center (successor to AWS IAM Identity Center) and the identity provider of your choice. Federation provides a number of advantages over using IAM users in addition to eliminating long-term credentials. Your users can also request temporary credentials from the command line for direct federation or by using IAM Identity Center. This means that there are few uses cases that require IAM users or long-term credentials for your users. -
When granting third parties, such as software as a service (SaaS) providers, access to resources in your AWS account, you can use cross-account roles and resource-based policies.
-
If you need to grant applications for consumers or customers access to your AWS resources, you can use Amazon Cognito identity pools or Amazon Cognito user pools to provide temporary credentials. The permissions for the credentials are configured through IAM roles. You can also define a separate IAM role with limited permissions for guest users who are not authenticated.
For machine identities, you might need to use long-term credentials. In these cases, you should require workloads to use temporary credentials with IAM roles to access AWS.
-
For Amazon Elastic Compute Cloud
(Amazon EC2), you can use roles for Amazon EC2.
-
AWS Lambda
allows you to configure a Lambda execution role to grant the service permissions to perform AWS actions using temporary credentials. There are many other similar models for AWS services to grant temporary credentials using IAM roles. -
For IoT devices, you can use the AWS IoT Core credential provider to request temporary credentials.
-
For on-premises systems or systems that run outside of AWS that need access to AWS resources, you can use IAM Roles Anywhere.
There are scenarios where temporary credentials are not an
option and you might need to use long-term credentials. In these
situations,
audit
and rotate credentials periodically and
rotate
access keys regularly for use cases that require long-term
credentials. Some examples that might require long-term
credentials include WordPress plugins and third-party AWS
clients. In situations where you must use long-term credentials,
or for credentials other than AWS access keys, such as database
logins, you can use a service that is designed to handle the
management of secrets, such as
AWS Secrets Manager
Resources
Related best practices:
Related documents:
Related videos:
