AWS Secrets Manager best practices - AWS Secrets Manager
Store credentials and other sensitive information in AWS Secrets ManagerFind unprotected secrets in your codeChoose an encryption key for your secretUse caching to retrieve secrets Rotate your secretsMitigate risks of using CLI Limit access to secretsReplicate secrets Monitor secrets Run your infrastructure on private networks

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.

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:

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:

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.

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 on the AWS Security Blog.

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.