Access Amazon Secrets Manager secrets from a different account - Amazon Secrets Manager
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

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 in Account2 to access the secret in Account1. To use this policy, see Resource-based policies.

    JSON
    {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws-cn:iam::Account2:role/ApplicationRole"
      },
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "*"
    }
  ]
}
Step 2: Add a statement to the key policy for the KMS key in Account1

  • The following key policy statement allows ApplicationRole in Account2 to use the KMS key in Account1 to decrypt the secret in Account1. 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 in Account2 to access the secret in Account1 and decrypt the secret value by using the encryption key which is also in Account1. 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 call describe-secret.

    JSON
    {
  "Version" : "2012-10-17",
  "Statement" : [
    {
      "Effect": "Allow",
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "SecretARN"
    },
    {
      "Effect": "Allow",
      "Action": "kms:Decrypt",
      "Resource": "arn:aws-cn:kms:Region:Account1:key/EncryptionKey"
    }
  ]
}