AWS Secrets Manager
User Guide

Using Resource-based Policies for Secrets Manager

You can control access to secrets in AWS Secrets Manager by using secret (resource-based) policies. Secrets Manager defines a secret as a resource in Secrets Manager. You, as the account administrator, control access to resources in an AWS service You can add permissions to the policy attached to a secret. Secrets Manager attaches permissions policies directly to secrets refers to resource-based policies. You can use resource-based policies to manage secret access and management permissions.

One advantage of resource-based policies over identity-based policies is that a resource-based policy enables you to grant access to principals from different accounts. See the second example in the first section that follows.

For an overview of the basic elements for policies, see Managing Access to Resources with Policies.

For information about the alternative, identity-based permission policies, see Using Identity-based Policies (IAM Policies) for Secrets Manager.

Controlling Which Principals Can Access a Secret

When you use a resource-based policy with Secrets Manager attached directly to a secret, the Resource automatically and implicitly becomes the secret attached to the policy. You now specify the Principal element. The Principal element enables you to specify which IAM users, groups, roles, accounts, or AWS service principals can access this secret, and which actions they can perform on this secret. For more information about the different ways to specify a Principal, see Principal in the IAM User Guide.

Example: Granting permission to a user in the same account as the secret

The following policy, when attached directly to a secret (as part of the metadata), grants the user Anaya permission to run any Secrets Manager operation on it.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "secretsmanager:*", "Principal": {"AWS": "arn:aws:iam::123456789012:user/anaya"}, "Resource": "*" } ] }

Example: Granting permission to authorized users in a different account

The following policy, when attached directly to a secret (as part of the metadata), grants the IAM user Mateo in the account 123456789012 access to read any version of a specific secret:

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": {"AWS": "arn:aws:iam::123456789012:user/mateo" }, "Action": "secretsmanager:GetSecretValue", "Resource": "*" } ] }

Grant Read-Only Access to a Role

A common Secrets Manager scenario may be an application running on an Amazon EC2 instance and requires access to a database to perform the required tasks. The application must retrieve the database credentials from Secrets Manager. To make a request to Secrets Manager, like any other AWS service, you must have AWS credentials with permissions to perform the request. AWS recommends achieving this by creating an IAM role attached to the EC2 instance profile. For more information, see IAM Roles for Amazon EC2 in the Amazon EC2 User Guide for Linux Instances—and specifically the section Retrieving Security Credentials from Instance Metadata.

If you then attach the following example resource-based policy to the secret, any requests to retrieve the secret work only if the requester uses credentials associated with that role, and if the request only asks for the current version of the secret:

{ "Version" : "2012-10-17", "Statement" : [ { "Effect": "Allow", "Principal": {"AWS": "arn:aws:iam::123456789012:role/EC2RoleToAccessSecrets"}, "Action": "secretsmanager:GetSecretValue", "Resource": "*", "Condition": { "ForAnyValue:StringEquals": { "secretsmanager:VersionStage" : "AWSCURRENT" } } } ] }