本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
Policies
与在几乎所有 AWS 服务中一样,Secrets Manager 创建并附加权限策略以授予权限。策略具有两种基本类型:
-
基于身份的策略 – 直接附加到用户、组或角色。该策略为附加的身份指定允许的任务。附加的用户自动且隐式地成为策略的
Principal
。您可以指定身份可以执行的Actions
以及身份可以对其执行操作的Resources
。这些策略允许您执行以下操作:-
授予多个资源的访问权限以与身份共享。
-
控制不存在的资源(如各种 APIs 操作)对
Create*
的访问。 -
向资源授予对 IAM 组的访问权限。
-
-
基于资源的策略 – 直接附加到资源—在本例中为密钥。策略指定密钥的访问权限以及用户对密钥执行的操作。附加的密钥自动且隐式地成为策略的
Resource
。您可以指定访问密钥的Principals
以及委托人可以执行的Actions
。这些策略允许您执行以下操作:-
为多个委托人 (用户或角色) 授予单个密钥的访问权限。请注意,您无法在基于资源的策略中将 IAM 组指定为委托人。仅用户和角色可以是委托人。
-
通过在策略语句的 AWS 元素中指定账户 IDs 来授予对其他
Principal
账户中的用户或角色的访问权限。如果您需要密钥的“跨账户”访问权限,这可能是使用基于资源的策略的主要原因之一。
-
您应使用哪种类型? 虽然它们的功能确实存在很多重叠,但在某些情况下,一种类型明显优于另一个类型,并且它们都应在您的安全策略中占有一席之地。当两种策略类型都可以使用时,选择可在人员进入和离开您的组织时简化策略维护的类型。
在一个账户中的 IAM 委托人访问另一个账户中的密钥时,必须使用自定义 AWS KMS 客户主密钥 (CMK) 对该密钥进行加密。使用账户的默认 Secrets Manager CMK 加密的密钥只能由该账户中的委托人进行解密。来自其他账户的委托人必须被授予对密钥和自定义 AWS KMS CMK 的权限。
作为替代方案,您可以为用户授予跨账户访问权限,并在与密钥相同的账户中担任 IAM 角色。由于角色在与密钥相同的账户中存在,因此,角色可以访问使用账户的默认 AWS KMS 密钥加密的密钥。