本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
访问 AWS Secrets Manager 来自不同账户的秘密
一个账户中的用户可以访问另一个账户中的密钥(跨账户访问),您必须允许在资源策略和身份策略中进行访问。这与授予密钥所在账户中的身份访问权限不同。
Cross-account 权限仅对以下操作有效:
您可以将BlockPublicPolicy参数与PutResourcePolicy操作一起使用,防止通过直接附加到您的机密的资源策略授予公共访问权限,从而帮助保护您的资源。您也可以使用 IAM Access Analyzer 验证跨账户访问权限。
您还必须允许身份使用密钥加密的 KMS 密钥。这是因为你不能使用 AWS 托管式密钥 (aws/secretsmanager) 进行跨账户访问。相反,您必须使用您创建的 KMS 密钥加密密钥,然后随附密钥策略。创建 KMS 密钥需支付费用。要更改密钥的加密密钥,请参阅 修改 AWS Secrets Manager 机密密钥。
重要
Resource-based 策略授予secretsmanager:PutResourcePolicy权限使委托人,即使是其他账户中的委托人,也能够修改您的基于资源的策略。此权限可让主体升级现有权限,例如获得对密钥的完全管理访问权限。我们建议您对策略应用最低权限访问的原则。有关更多信息,请参阅 Resource-based 政策。
下列示例策略假定您在 Account1 中有密钥和加密密钥,而在 Account2 的身份希望有访问密钥值的权限。
步骤 1:将资源策略附加到中的密钥 账户 1
-
以下策略允许
ApplicationRole入Account2口访问中的密钥Account1。要使用该策略,请参阅 Resource-based 政策。
第 2 步:在 KMS 密钥的密钥策略中添加声明 账户 1
-
以下密钥政策语句允许
Account2中的ApplicationRole使用Account1中的 KMS 密钥来解密Account1中的密钥。要使用此语句,请将其添加到 KMS 密钥的密钥策略中。有关更多信息,请参阅更改密钥策略。{ "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::Account2:role/ApplicationRole" }, "Action": [ "kms:Decrypt", "kms:DescribeKey" ], "Resource": "*" }
步骤 3:将身份策略附加到中的身份 账户 2
-
以下策略允许
Account2中的ApplicationRole访问Account1中的密钥,并通过使用同样位于Account1中的加密密钥来解密密钥值。要使用该策略,请参阅 Identity-based 政策。您可以在 Secrets Manager 控制台的密钥详细信息页面的密钥 ARN 下方找到您的密钥 ARN。此外,您也可以调用describe-secret。