AWS Secrets Manager: Best Practices

In this post will discuss some best practices when using AWS Secrets Manager. We’ll touch on secret rotation, encryption and limiting access via IAM and resource policies.

What is AWS Secrets Manager?

AWS Secrets Manager is a secrets management service that enables you to protect access to secrets required by your applications and services. Secrets Manager enables easy rotation, management and retrieval of database credentials, API keys and other sensitive material throughout their lifecycle. Secrets Manager can be leveraged natively by services & resources in AWS, with a third-party service and by on-premise systems.

Secrets Manager Best Practices

While this post relates to AWS Secrets Manager, most of these best practices apply to any secrets management platform such as Azure Key Vault, Google Cloud Platform (GCP) Secret Manager or an on-premise secrets management implementation.

1. Encrypt stored secrets

Ensure that any stored secrets in Secrets Manager are encrypted with a Key Management Service (KMS) key. By default, AWS requires that all secrets stored are encrypted with a KMS key. However, many organisations have requirements around the use of Customer Managed Keys (CMK) versus AWS managed. Consult with your Security or Infrastructure team on the best approach if you are unsure.

2. Limit access to secrets with IAM

By ensuring that the scope of access to secrets is limited to trusted AWS accounts/roles, you reduce the risk of exposure. You should always follow the principle of least privilege when granting access to any resources (in the cloud or otherwise), this principle is particularly important as it relates to secrets and secrets management. Later in this post we will discuss using AWS resource policies to restrict further the access to stored secrets.

3. Do not reuse secrets

By generating unique secrets for all applications and services, you limit the impact of an potential exposure of your stored secrets.

4. Decommission unused secrets

If a stored secret is no longer required, decommission it by scheduling it for deletion within Secrets Manager. By default, AWS enforces a minimum 7 day waiting period before deleting a secret after it has been scheduled for deletion. Consider setting up CloudTrail & CloudWatch logging and alerting to notify you of nefarious attempts to delete secrets. For added security, consider an AWS Service Control Policy (SCP) to deny deletion of critical resources including secrets.

5. Define a rotation strategy for your secrets

Develop a tried and tested rotation strategy for your stored secrets. You should consider both planned and unplanned rotation events as part of this strategy. For example, what is the downstream impact of a security event/exposed secret if it needed to be rotated quickly? Ensure that service/application stakeholders are aware of this strategy and how to invoke it. This should form part of your incident response plan.

6. Routinely audit who/what can access secrets

At a regular cadence, audit who can access secrets stored in Secrets Manager. If access is no longer required, revoke it. Leverage native AWS tooling to ease/automate this process. CloudTrail provides a specific event source for Secrets Manager which can be used in conjunction with EventBridge to match on events relating to stored secrets. Additionally, as mentioned - you should pay close attention to scheduled deletion events.

7. Leverage automatic secret rotation

A useful feature of Secrets Manager is it's support for automatic secret rotation. Where possible you should leverage ephemeral secrets and reduce the lifecycle time of a secret. AWS supports automatic rotation natively for some services such as Amazon RDS and Aurora. Additionally, Lambda can be leveraged to rotate secrets for custom applications.

8. Apply a resource policy to your secrets

Finally, consider applying resource policies to your secrets to limit access further. Consider a case where an attacker obtains privileged access to your AWS account, this access could allow the adversary to read, update or delete secrets within Secrets Manager. Applying a resource policy that limits this access/management activity to a specific user or role offers additional layer of protection in addition to IAM policies.

Example Policy

The resource policy JSON below details an example of an explicit deny statement, which prevents any actions on a specific secret unless the ARN of the Principal performing the action matches a specific AWS role:

{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Deny",
        "Principal": "*",
        "Action": "secretsmanager:*",
        "Resource": "arn:aws:secretsmanager:<AWS-REGION>:<AWS-ACCOUNT-ID>:secret:<SECRET-NAME>",
        "Condition": {
            "StringNotEquals": {
                "aws:PrincipalArn": "arn:aws:iam::<AWS-ACCOUNT-ID>:role/<AWS-IAM-ROLE>"
            }
        }
    }]
}

(Note: This example does not consider an attacker assuming the given role. You should consider this as part of your IAM security strategy.)

Conclusion

AWS Secrets Manager is a powerful managed service and is something you should consider if you run workloads in AWS and/or are looking for a redundant and secure environment to store secrets. For more details on AWS Secrets Manager including pricing, you can see the AWS website here.

---

Thanks for taking the time to read this post, hopefully you can take some of the best practices detailed here and start implementing them in your own AWS environment. If you have any feedback or would just like to connect, I'd love to hear it over on LinkedIn!

-Dan