Access Amazon Secrets Manager secrets from a different account
To allow users in one account to access secrets in another account (cross-account access), you must allow access both in a resource policy and in an identity policy. This is different than granting access to identities in the same account as the secret.
Cross-account permission is effective only for the following operations:
You can use the BlockPublicPolicy
parameter with the PutResourcePolicy action to help protect your resources by
preventing public access from being granted through the resource policies that are directly
attached to your secrets. You can also use IAM Access Analyzer to
verify cross-account access.
You must also allow the identity to use the KMS key that the secret is encrypted with.
This is because you can't use the Amazon managed key (aws/secretsmanager
) for
cross-account access. Instead, you must encrypt your secret with a KMS key that you create,
and then attach a key policy to it. There is a charge for creating KMS keys. To change the
encryption key for a secret, see Modify an Amazon Secrets Manager secret.
Important
Resource-based policies granting secretsmanager:PutResourcePolicy
permission gives principals, even those in other accounts, the ability to modify your
resource-based policies. This permission lets principals escalate existing permissions like
obtaining full administrative access to secrets. We recommend you apply the principle of
least privileged
access to your policies. For more information, see Resource-based policies.
The following example policies assume you have a secret and encryption key in Account1, and an identity in Account2 that you want to allow to access the secret value.
Step 1: Attach a resource policy to the secret in Account1
-
The following policy allows
ApplicationRole
inAccount2
to access the secret inAccount1
. To use this policy, see Resource-based policies.
Step 2: Add a statement to the key policy for the KMS key in Account1
-
The following key policy statement allows
ApplicationRole
inAccount2
to use the KMS key inAccount1
to decrypt the secret inAccount1
. To use this statement, add it to the key policy for your KMS key. For more information, see Changing a key policy.{ "Effect": "Allow", "Principal": { "AWS": "arn:aws-cn:iam::
Account2
:role/ApplicationRole
" }, "Action": [ "kms:Decrypt", "kms:DescribeKey" ], "Resource": "*" }
Step 3: Attach an identity policy to the identity in Account2
-
The following policy allows
ApplicationRole
inAccount2
to access the secret inAccount1
and decrypt the secret value by using the encryption key which is also inAccount1
. To use this policy, see Identity-based policies. You can find the ARN for your secret in the Secrets Manager console on the secret details page under Secret ARN. Alternatively, you can calldescribe-secret
.