AWS Secrets Manager Best practices

The following recommendations help you to more securely use AWS Secrets Manager:

Topics

• Protecting additional sensitive information
• Improving performance by using the AWS provided client-side caching components
• Adding retries to your application
• Mitigating the risks of logging and debugging your Lambda function
• Mitigating the risks of using the AWS CLI to store your secrets
• Cross-account access – should I specify a user/role or the account?
• Running everything in a VPC
• Tag your secrets
• Rotating secrets on a schedule
• Auditing access to secrets
• Monitoring your secrets with AWS Config
• Using Secrets Manager to provide database credentials to Lambda functions
• More resources on best practices

Protecting additional sensitive information

A secret often includes several pieces of information besides the user name and password. Depending on the database, service, or website, you can choose to include additional sensitive data. This data can include password hints, or question-and-answer pairs you can use to recover your password.

Ensure you protect any information that might be used to gain access to the credentials in the secret as securely as the credentials themselves. Don't store this type of information in the Description or any other non-encrypted part of the secret.

Instead, store all such sensitive information as part of the encrypted secret value, either in the SecretString or SecretBinary field. You can store up to 65536 bytes in the secret. In the SecretString field, the text usually takes the form of JSON key-value string pairs, as shown in the following example:

{
  "engine": "mysql",
  "username": "user1",
  "password": "i29wwX!%9wFV",
  "host": "my-database-endpoint.us-east-1.rds.amazonaws.com",
  "dbname": "myDatabase",
  "port": "3306"
}