AWS Secrets Manager best practices
Secrets Manager provides a number of security features to consider as you develop and implement your own security policies. The following best practices are general guidelines and don't represent a complete security solution. Because these best practices might not be appropriate or sufficient for your environment, treat them as helpful considerations rather than prescriptions.
Consider the following best practices for storing and managing secrets:
- Store credentials and other sensitive information in AWS Secrets Manager
- Find unprotected secrets in your code
- Choose an encryption key for your secret
- Use caching to retrieve secrets
- Rotate your secrets
- Mitigate risks of using CLI
- Limit access to secrets
- Replicate secrets
- Monitor secrets
- Run your infrastructure on private networks
Store credentials and other sensitive information in AWS Secrets Manager
Secrets Manager can help improve your security posture and compliance, and reduce the risk of unauthorized access to your sensitive information. Secrets Manager encrypts secrets at rest using encryption keys that you own and store in AWS Key Management Service (AWS KMS). When you retrieve a secret, Secrets Manager decrypts the secret and transmits it securely over TLS to your local environment. For more information, see Create an AWS Secrets Manager secret.
Find unprotected secrets in your code
CodeGuru Reviewer integrates with Secrets Manager to use a secrets detector that finds unprotected secrets in your code. The secrets detector searches for hardcoded passwords, database connection strings, user names, and more. For more information, see Find unprotected secrets in your code with Amazon CodeGuru Reviewer.
Amazon Q can scan your codebase for security vulnerabilities and code quality issues to improve the posture of your applications throughout the development cycle. For more information, see Scanning your code with Amazon Q in the Amazon Q Developer User Guide.
Choose an encryption key for your secret
For most cases, we recommend using the aws/secretsmanager
AWS managed key to encrypt secrets. There is no cost for using it.
To be able to access a secret from another account or to apply a key policy to the encryption key, use a customer managed key to encrypt the secret.
-
In the key policy, assign the value
secretsmanager.<region>.amazonaws.com
to the kms:ViaService condition key. This limits use of the key to only requests from Secrets Manager. -
To further limit use of the key to only requests from Secrets Manager with the correct context, use keys or values in the Secrets Manager encryption context as a condition for using the KMS key by creating:
-
A string condition operator in an IAM policy or key policy
-
A grant constraint in a grant
-
For more information, see Secret encryption and decryption in AWS Secrets Manager.
Use caching to retrieve secrets
To use your secrets most efficiently, we recommend you use one of the following supported Secrets Manager caching components to cache your secrets and update them only when required:
Use AWS Secrets Manager secrets in Amazon Elastic Kubernetes Service
Use AWS Secrets Manager Agent to standardize consumption of secrets from Secrets Manager across environments such as AWS Lambda, Amazon Elastic Container Service, Amazon Elastic Kubernetes Service, and Amazon Elastic Compute Cloud.
Rotate your secrets
If you don't change your secrets for a long period of time, the secrets become more likely to be compromised. With Secrets Manager, you can set up automatic rotation as often as every four hours. Secrets Manager offers two strategies for rotation: Single user and Alternating users. For more information, see Rotate AWS Secrets Manager secrets.
Mitigate risks of using CLI
When you use the AWS CLI to invoke AWS operations, you enter those commands in a command shell. Most command shells offer features that could compromise your secrets, such as logging and the ability to see the last entered command. Before you use the AWS CLI to enter sensitive information, be sure to Mitigate the risks of using the AWS CLI to store your AWS Secrets Manager secrets.
Limit access to secrets
In IAM policy statements that control access to your secrets, use the principle of least privileged access. You can use IAM roles and policies, resource policies, and attribute-based access control (ABAC). For more information, see Authentication and access control for AWS Secrets Manager.
Topics
Block broad access to secrets
In identity policies that allow the action PutResourcePolicy
, we
recommend you use BlockPublicPolicy: true
. This condition means that users
can only attach a resource policy to a secret if the policy doesn't allow broad access.
Secrets Manager uses Zelkova automated reasoning to analyze resource policies for broad access.
For more information about Zelkova, see How AWS uses automated reasoning to help you achieve security at scale
The following example shows how to use BlockPublicPolicy
.
{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "secretsmanager:PutResourcePolicy", "Resource": "
SecretId
", "Condition": { "Bool": { "secretsmanager:BlockPublicPolicy": "true" } } } }
Use caution with IP address conditions in policies
Use caution when you specify the IP address condition operators or the aws:SourceIp
condition key in a
policy statement that allows or denies access to Secrets Manager. For example, if you attach a policy
that restricts AWS actions to requests from your corporate network IP address range to a
secret, then your requests as an IAM user invoking the request from the corporate network
work as expected. However, if you enable other services to access the secret on your behalf,
such as when you enable rotation with a Lambda function, that function calls the Secrets Manager
operations from an AWS-internal address space. Requests impacted by the policy with the IP
address filter fail.
Also, the aws:sourceIP
condition key is less effective when the
request comes from an Amazon VPC endpoint. To restrict requests to a specific VPC endpoint, use
Limit requests with VPC endpoint conditions.
Limit requests with VPC endpoint conditions
To allow or deny access to requests from a particular VPC or VPC endpoint, use
aws:SourceVpc
to limit access to requests from the specified VPC or aws:SourceVpce
to limit access to requests from the specified VPC
endpoint. See Example: Permissions and VPCs.
-
aws:SourceVpc
limits access to requests from the specified VPC. -
aws:SourceVpce
limits access to requests from the specified VPC endpoint.
If you use these condition keys in a resource policy statement that allows or denies access to Secrets Manager secrets, you can inadvertently deny access to services that use Secrets Manager to access secrets on your behalf. Only some AWS services can run with an endpoint within your VPC. If you restrict requests for a secret to a VPC or VPC endpoint, then calls to Secrets Manager from a service not configured for the service can fail.
See Using an AWS Secrets Manager VPC endpoint.
Replicate secrets
Secrets Manager can automatically replicate your secrets to multiple AWS Regions to meet your resiliency or disaster recovery requirements. For more information, see Replicate AWS Secrets Manager secrets across Regions.
Monitor secrets
Secrets Manager enables you to audit and monitor secrets through integration with AWS logging, monitoring, and notification services. For more information, see:
Run your infrastructure on private networks
We recommend that you run as much of your infrastructure as possible on private networks that are not accessible from the public internet. You can establish a private connection between your VPC and Secrets Manager by creating an interface VPC endpoint. For more information, see Using an AWS Secrets Manager VPC endpoint.