Secrets Manager 密钥访问权限管理概述 - AWS Secrets Manager
AWS 文档中描述的 AWS 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 AWS 服务入门

如果我们为英文版本指南提供翻译,那么如果存在任何冲突,将以英文版本指南为准。在提供翻译时使用机器翻译。

Secrets Manager 密钥访问权限管理概述

AWS 账户拥有所有 AWS 资源,包括您存储在 AWS Secrets Manager 中的密钥。AWS 包含权限策略以创建或访问资源。账户管理员可以将权限策略直接附加到资源(密钥)或需要访问资源的 IAM 身份(用户、组和角色),以控制对 AWS 资源的访问。

注意

管理员 或管理员用户具有管理员权限。这通常意味着,他们有权对服务的所有资源执行所有操作。有关更多信息,请参阅IAM 用户指南 中的 IAM 最佳实践

Secrets Manager 的账户管理员可以执行一些管理任务,包括将管理员权限委派给账户中的其他 IAM 用户或角色。为此,您可以将 IAM 权限策略附加到 IAM 用户、组或角色。默认情况下,用户根本没有任何权限,这意味着用户具有隐式拒绝。您附加的策略指定用户可以执行的操作以及他们可以对哪些资源执行操作,以使用显式允许覆盖隐式拒绝。策略可附加到账户中的用户、组和角色。如果您为角色授予权限,则该角色可以由组织的其他账户中的用户担任。

Authentication

AWS 将身份验证定义为在您访问的服务中设置代表您的身份的过程。通常,管理员为您分配一个身份,您可以在请求中提供凭证(如用户名和密码)或使用 AWS 访问密钥加密请求以访问该身份。

AWS 支持以下类型的身份:

  • AWS 账户根用户 – 在注册 AWS 时,您为 AWS 账户提供一个电子邮件地址和密码。AWS 使用该信息以作为账户根用户的凭证,并提供所有 AWS 资源的完全访问权限。

    重要

    出于安全考虑,我们建议您仅使用根用户凭证创建管理员用户,这是具有您的 AWS 账户的完全权限的 IAM 用户。然后,您可以使用此管理员用户来创建具有有限的作业或角色特定权限的其他 IAM 用户和角色。有关更多信息,请参阅IAM 用户指南 中的创建单独的 IAM 用户 (IAM 最佳实践)创建管理员用户和组

  • IAM 用户IAM 用户是 AWS 账户中具有特定权限(例如,访问 Secrets Manager 密钥)的身份。您可以使用 IAM 用户名和密码登录到安全 AWS 网页,例如 AWS 管理控制台AWS 开发论坛AWS 支持中心

    除了用户名和密码以外,您还可以为每个用户创建访问密钥,以允许通过某个 AWS 开发工具包命令行工具以编程方式访问 AWS 服务。开发工具包和命令行工具使用访问密钥对 API 请求进行加密签名。如果您不使用 AWS 工具,则必须自行对请求签名。AWS KMS 支持签名版本 4,这是一种用于对入站 API 请求进行身份验证的协议。有关对 API 请求进行身份验证的更多信息,请参阅AWS 一般参考 中的签名版本 4 签名流程

  • IAM 角色 – 您可以在账户中创建具有特定权限的 IAM 角色。与 IAM 用户类似,IAM 角色不与特定人员关联。通过使用 IAM 角色,您可以获取临时访问密钥以通过编程方式访问 AWS 服务和资源。AWS 角色在以下情况下是非常有用的:

    • 联合身份用户访问 – 您可以不创建 IAM 用户,而是使用来自 AWS Directory Service、您的企业用户目录或 Web 身份提供商 (IdP) 的既有用户身份。他们被称为联合身份用户身份提供商将 IAM 角色与联合用户相关联。有关联合身份用户的更多信息,请参阅IAM 用户指南 中的联合身份用户和角色

    • 跨账户访问 – 可以在您的 AWS 账户中使用 IAM 角色,以便为另一个 AWS 账户授予权限以访问您的账户资源。如需示例,请参阅 教程: 使用IAM角色代表访问AWS账户IAM用户指南.

    • AWS 服务访问权限 – 可以在您的账户中使用 IAM 角色,以便为 AWS 服务授予权限以访问您的账户资源。例如,您可以创建一个角色,使其允许 Amazon Redshift 代表您访问 S3 存储桶,然后将存储在 S3 存储桶中的数据加载到 Amazon Redshift 集群中。有关更多信息,请参阅IAM 用户指南中的创建向 AWS 服务委派权限的角色

    • 在 EC2 实例上运行的应用程序 – 并非将访问密钥存储在 EC2 实例上以供在实例上运行并发送 AWS API 请求的应用程序使用,您可以使用 IAM 角色为这些应用程序提供临时访问密钥。要将 IAM 角色分配给 EC2 实例,您可以创建实例配置文件,然后在启动实例时附加该配置文件。实例配置文件包含 IAM 角色,并允许在 EC2 实例上运行的应用程序获得临时访问密钥。有关更多信息,请参阅IAM 用户指南中的对 Amazon EC2 上的应用程序使用角色

在使用一个身份登录后,您可以使用访问控制和授权设置可执行的任务(通过您的身份)。

访问控制和授权

您可以使用具有凭证的有效身份对请求进行身份验证,但也需要权限才可发出 Secrets Manager API 请求来创建、管理或使用 Secrets Manager 资源。例如,您必须具有相应的权限以创建密钥,管理密钥,检索密钥以及执行其他任务。以下几节介绍了管理 Secrets Manager 的权限。

Secrets Manager Policies 合并资源和行动

本节介绍了 Secrets Manager 概念如何映射到 IAM 等效概念。

Policies

与在几乎所有 AWS 服务中一样,Secrets Manager 创建并附加权限策略以授予权限。策略具有两种基本类型:

  • 基于身份的策略 – 直接附加到用户、组或角色。该策略为附加的身份指定允许的任务。附加的用户自动且隐式地成为策略的Principal。您可以指定身份可以执行的 Actions 以及身份可以对其执行操作的 Resources。这些策略允许您执行以下操作:

    • 授予多个资源的访问权限以与身份共享。

    • 控制不存在的资源(如各种 Create* 操作)对 API 的访问。

    • 向资源授予对 IAM 组的访问权限。

  • 基于资源的政策 – 直接附加到资源—在这种情况下,一个秘密。策略指定密钥的访问权限以及用户对密钥执行的操作。附加的密钥自动且隐式地成为策略的Resource。您可以指定访问密钥的Principals以及委托人可以执行的Actions。这些策略允许您执行以下操作:

    • 为多个委托人 (用户或角色) 授予单个密钥的访问权限。请注意,您无法在基于资源的策略中将 IAM 组指定为委托人。仅用户和角色可以是委托人。

    • 通过在策略语句的 Principal 元素中指定账户 ID 来授予对其他 AWS 账户中的用户或角色的访问权限。如果您需要密钥的“跨账户”访问权限,这可能是使用基于资源的策略的主要原因之一。

您应使用哪种类型? 虽然它们的功能确实存在很多重叠,但在某些情况下,一种类型明显优于另一个类型,并且它们都应在您的安全策略中占有一席之地。当两种策略类型都可以使用时,选择可在人员进入和离开您的组织时简化策略维护的类型。

重要

在一个账户中的 IAM 委托人访问另一个账户中的密钥时,必须使用自定义 AWS KMS 客户主密钥 (CMK) 对该密钥进行加密。使用账户的默认 Secrets Manager CMK 加密的密钥只能由该账户中的委托人进行解密。来自其他账户的委托人必须被授予对密钥和自定义 AWS KMS CMK 的权限。

作为替代方案,您可以为用户授予跨账户访问权限,并在与密钥相同的账户中担任 IAM 角色。由于角色在与密钥相同的账户中存在,因此,角色可以访问使用账户的默认 AWS KMS 密钥加密的密钥。

Resources

在 Secrets Manager 中,您可以控制对密钥 的访问。

每个密钥都具有相关联的唯一 Amazon 资源名称 (ARN)。您可以在 IAM 权限策略的 Resource 元素中指定 ARN 以控制对密钥的访问。密钥的 ARN 具有以下格式:

arn:aws-cn:secretsmanager:<region>:<account-id>:secret:optional-path/secret-name-6-random-characters
了解资源所有权

AWS 账户拥有您在该账户中创建的资源,而无论创建资源的人员是谁。具体来说,资源所有者是根用户、IAM 用户或 IAM 角色的 AWS 账户,他们具有对资源创建请求进行身份验证的凭证。以下示例说明了它的工作原理:

  • 如果您以根用户账户身份登录以创建密钥,AWS 账户将成为资源的所有者。

  • 如果您在账户中创建 IAM 用户并为用户授予创建密钥的权限,则用户可以创建密钥。不过,用户的 AWS 账户拥有密钥。

  • 如果您在账户中创建具有创建密钥的权限的 IAM 角色,则可以代入该角色的任何人都可以创建密钥。角色的 AWS 账户(而不是担任角色的用户)拥有密钥。

操作

Secrets Manager 提供一组操作(API 调用和 CLI 命令)来处理密钥。通过这些操作,您可以执行一些操作,例如创建、列出、访问、修改或删除密钥。这些操作对应于可用于授予或拒绝该操作的访问权限的策略操作。在大多数情况下,API 操作与您可以在策略中分配的操作之间存在一一对应关系。要控制对操作的访问,请在 IAM 策略的 Action 元素中指定相应的操作。有关在策略中使用的允许的 Secrets Manager 操作列表,请参阅可以在 IAM 策略或 AWS Secrets Manager 密钥策略中使用的操作、资源和上下文键

  • 在基于身份 的权限策略 Statement 中将 Action 元素和 Resource 元素组合使用时,您可以同时控制执行的操作和资源。这些限制适用于附加了策略的用户、组或角色。

  • 当您将 Action 元素和 Principal 元素 资源基于权限的政策 Statement,然后控制可执行的操作—以及执行这些操作的用户、组或角色(负责人)。这些限制适用于附加了策略的密钥。

如果要授予权限以创建新的密钥,请使用附加到用户、组或角色的基于身份的策略。当您希望以类似方式一起管理多个密钥时,此方法也会非常有帮助。

如果要授予权限以访问现有的密钥,您可以使用附加到密钥的基于资源的策略。

使用策略管理对资源的访问

A 权限策略 描述 世界卫 可以执行 哪些行动哪些资源. 下一节介绍了用于创建权限策略的可用选项,并简要介绍了组成策略的元素以及可以为 Secrets Manager 创建的两种策略。

注意

本节讨论了在 Secrets Manager 上下文中使用 IAM,但没有提供有关 IAM 服务的详细信息。有关完整的 IAM 文档,请参阅 IAM 用户指南。有关 IAM 策略语法和介绍的信息,请参阅 AWSIAM 中的 IAM 用户指南 策略参考

您应该了解可以将基于密钥或基于身份的权限策略用于 Secrets Manager。Secrets Manager 将所有应用的策略组合在一起,并将它们作为一个大型策略进行处理。该基本规则结构控制交互:

显式拒绝 >> 显式允许 >> 隐式拒绝 (默认)

请求对 AWS 资源执行 AWS 操作时,应用以下规则:

  • 如果任何具有明显的“拒绝”的策略中的任何声明都匹配请求操作和资源: 显式拒绝会覆盖其他所有内容,并阻止指定资源上的指定操作。

  • 如果没有明确的“拒绝”,则显示“允许”的声明与请求操作和资源相匹配: 应用明确允许,在该声明中授予对该声明中资源的操作。

  • 如果没有具有显式“拒绝”的语句和具有显式“允许”的语句与请求操作和资源匹配:默认情况下,AWS 隐式地 拒绝请求。

您应该了解,可以使用显式允许覆盖隐式 拒绝。无法覆盖显式 拒绝。

在多个策略适用时的有效权限
策略 A 策略 B 有效的权限
允许 无提示 允许访问
允许 允许 允许访问
允许 拒绝 访问被拒绝
无提示 无提示 访问被拒绝
无提示 允许 允许访问
无提示 拒绝 访问被拒绝
拒绝 无提示 访问被拒绝
拒绝 允许 访问被拒绝
拒绝 拒绝 访问被拒绝

策略 A 和策略 B 可以为任意类型:附加到用户或角色的基于身份的 IAM 策略或附加到密钥的基于资源的策略。您可以提取前两个策略的有效权限以包含其他策略的效果(结果)并将其视为新的策略 A,然后将第三个策略的结果添加为策略 B,对于每个适用的额外策略重复该过程。

AWS 托管策略

AWS 提供由 AWS 创建和管理的单独 IAM 策略,以满足很多常见使用案例的要求。这些托管策略 为常见的使用案例授予所需的权限,以便您可以避免调查所需的权限。有关更多信息,请参阅 IAM 用户指南 中的 AWS 托管策略

Secrets Manager 具有特定的 AWS 托管策略,您可以将其附加到您的账户中的用户:

  • SecretsManagerReadWrite – 可以将该策略附加到 IAM 用户和角色以管理 Secrets Manager。该策略为 Secrets Manager 服务授予完全权限,并为其他服务(例如 AWS KMS、Amazon CloudFront、AWS Serverless Application Repository 和 AWS Lambda)授予有限的权限。

    您可以在 AWS 管理控制台中查看此策略。

    重要

    出于安全考虑,该托管策略 包含配置轮换所需的 IAM 权限。您必须单独显式地授予权限。通常,您会将 IAMFullAccess 托管策略附加到 Secrets Manager 管理员,使其可以配置轮换。

Secrets Manager 团队维护 AWS 托管策略,这可能是使用 AWS 托管策略的一个重要优势。如果轮换过程扩展以包含需要额外权限的新功能,Secrets Manager 此时将在托管策略中添加这些权限。轮换函数自动获得新权限,以便它们继续正常运行,而不会发生中断。

指定策略语句元素

下一节从 IAM 的角度简要说明了 Secrets Manager 权限策略。有关 IAM 策略语法的更多详细信息,请参阅 AWSIAM 中的 IAM 用户指南 策略参考

Secrets Manager 定义了一组 API 操作,以通过某种方式与密钥进行交互或处理密钥。要为这些操作授予权限,Secrets Manager 定义一组可以在策略中指定的相应操作。例如,Secrets Manager 定义一个操作以处理密钥,例如 CreateSecretGetSecretValueListSecretsRotateSecret

策略文档必须有一个 Version 元素。我们建议您始终使用最新版本,以确保您可以使用所有可用功能。截至到撰写本文为止,唯一的可用版本为 2012-10-17 (最新版本)。

此外,密钥策略文档还必须具有一个在数组中包含一个或多个语句的 Statement 元素。每个语句最多包含六个元素:

  • Sid –(可选)您可以将 Sid 作为语句标识符,这是标识语句的任意字符串。字符串不能包含空格。

  • Effect –(必需)可以使用该关键字指定策略语句是允许还是拒绝对资源执行的操作。如果没有显式允许访问资源,则隐式 拒绝访问。您也可显式拒绝对资源的访问。这样做可确保用户无法对指定资源执行指定操作,即使其他策略授予了访问权也是如此。您应该了解多个语句可能会发生重叠,一个语句中的显式拒绝将覆盖任何其他显式允许的语句。默认情况下,显式允许语句覆盖存在的隐式拒绝。

  • Action –(必需)可以使用该关键字标识要允许或拒绝的操作。这些操作通常但不总是与可用操作一对一对应。例如,根据指定的 Effectsecretsmanager:PutSecretValue 允许或拒绝执行 Secrets Manager PutSecretValue 操作的用户权限。

  • Resource –(必需)在附加到用户、组或角色的基于身份的策略中,您可以使用该关键字为适用的策略语句指定资源的 Amazon 资源名称 (ARN)。如果您不希望语句限制对特定资源的访问,则可以使用“*”,生成的语句将仅限制操作。在附加到密钥的基于资源的策略中,资源必须始终 为“*”。

  • Principal –(仅在基于资源的策略中是必需的)对于直接附加到密钥的基于资源的策略,您可以指定要获得权限的用户、角色、账户、服务或其他实体。此元素在基于身份的策略中无效。在基于身份的策略中,附加了策略的用户或角色自动且隐式地成为委托人。

  • Condition –(可选)使用此关键字指定必须满足才能“匹配”语句和应用 Effect 的其他条件。有关详细信息,请参阅 IAM JSON政策要素: Condition

基于身份的策略

您可以向 IAM 身份挂载策略。例如,您可以执行以下操作:

  • 将权限策略附加到您的账户中的用户或组 – 要为用户授予权限以创建密钥,您可以将权限策略直接附加到用户或用户所属的组(建议)。

  • 将权限策略附加到角色 – 您可以将权限策略附加到 IAM 角色,以便为担任该角色的任何人授予密钥的访问权限。这包括以下场景中的用户:

    • 联合身份用户 – 您可以为通过 IAM 以外的身份系统进行身份验证的用户授予权限。例如,您可以将 IAM 角色与使用 Amazon Cognito 登录的移动应用程序用户相关联。角色为应用程序授予具有角色权限策略中的权限的临时凭证。这些权限可以包含密钥访问权限。有关更多信息,请参阅 Amazon Cognito 开发者指南 中的什么是Amazon Cognito

    • 在 EC2 实例上运行的应用程序 – 您可以将 IAM 角色附加到 Amazon EC2 实例,以便为在实例上运行的应用程序授予权限。在实例中的应用程序调用 AWS API 时,该应用程序可以从实例元数据中获取 AWS 临时凭证。这些临时凭证与角色相关联,并受角色权限策略的限制。这些权限可以包含密钥访问权限。

    • 跨账户访问 – 账户 A 中的管理员可以创建角色,以便为不同的账户 B 中的用户授予权限。例如:

      1. 账户 A 管理员创建一个 IAM 角色,并将一个权限策略附加到该角色。该策略授予账户 A 中的密钥的访问权限,并指定用户对密钥执行的操作。

      2. 账户 A 管理员将一个信任策略附加到角色,以便在 Principal 元素中指定账户 B 的账户 ID 以指定谁担任该角色。

      3. 然后,账户 B 管理员可以将权限委派给账户 B 中的任何用户,以使他们能够担任账户 A 角色。这样做允许账户 B 中的用户访问第一个账户中的密钥。

有关使用 IAM 委派权限的更多信息,请参阅 https://docs.amazonaws.cn/IAM/latest/UserGuide/access.html 中的IAM 用户指南访问权限管理

以下示例策略可以附加到用户、组或角色。该策略允许受影响的用户或角色在您的账户中仅对名称以路径“TestEnv/”开头的密钥执行 DescribeSecretGetSecretValue 操作。该策略还将用户或角色限制为仅检索附加了 AWSCURRENT 暂存标签的密钥版本。更换 <region> $and <account_id> 以下示例中的占位符具有您的实际值。

{ "Version": "2012-10-17", "Statement": [ { "Sid" : "Stmt1DescribeSecret", "Effect": "Allow", "Action": [ "secretsmanager:DescribeSecret" ], "Resource": "arn:aws:secretsmanager:<region>:<account_id>:secret:TestEnv/*" }, { "Sid" : "Stmt2GetSecretValue", "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue" ], "Resource": "arn:aws:secretsmanager:<region>:<account_id>:secret:TestEnv/*", "Condition" : { "ForAnyValue:StringLike" : { "secretsmanager:VersionStage" : "AWSCURRENT" } } } ] }

因为密钥版本可以附加多个暂存标签,所以您需要使用 IAM 策略语言的“集合运算符”在策略中比较它们。在前面的示例中,ForAnyValue:StringLike 声明如果附加到正在评估的密钥版本的任一暂存标签与字符串“AWSCURRENT”匹配,则该语句匹配并应用 Effect 字符串。

有关更多基于身份的策略示例,请参阅 为 Secrets Manager 使用基于身份的策略(IAM 策略)。有关用户、组、角色和权限的更多信息,请参阅 IAM 用户指南 中的身份(用户、组和角色)。

基于资源的策略

每个 Secrets Manager 密钥可以附加一个基于资源的权限策略(密钥策略)。作为将基于身份的策略用于 IAM 角色的替代方案,您可以使用密钥策略授予跨账户权限。例如,您可以通过以下方法为账户 B 中的用户授予权限以访问账户 A 中的密钥:在密钥策略中添加权限并将账户 B 中的用户指定为 Principal,而不是创建 IAM 角色。

以下示例介绍了具有一个语句的 Secrets Manager 密钥策略。该语句允许账户 123456789012 的管理员向该账户中的用户和角色委派权限。该策略限制管理员可以向名为“prod/ServerA-a1b2c3”的单个密钥的 secretsmanager:GetSecretValue 操作委派的权限。该条件确保用户只能检索密钥的当前版本。

{ "Version" : "2012-10-17", "Statement" : [ { "Effect": "Allow", "Principal": {"AWS": "arn:aws:iam::123456789012:root" }, "Action": "secretsmanager:GetSecretValue", "Resource": "arn:aws:secretsmanager:<region>:<account_id>:secret:prod/ServerA-a1b2c3", "Condition": { "ForAnyValue:StringEquals": { "secretsmanager:VersionStage" : "AWSCURRENT" } } } ] }
重要

在一个账户中的 IAM 委托人访问另一个账户中的密钥时,必须使用自定义 AWS KMS CMK 对密钥进行加密。使用账户的默认 Secrets Manager CMK 加密的密钥只能由该账户中的委托人进行解密。来自其他账户的委托人必须被授予对密钥和自定义 AWS KMS CMK 的权限。

作为替代方案,您可以向用户授予跨账户访问权限,以在密钥所在的同一账户中担任 IAM 角色。由于角色在与密钥相同的账户中存在,因此,角色可以访问使用账户的默认 AWS KMS 密钥加密的密钥。

因为密钥版本可以附加多个暂存标签,所以您需要使用 IAM 策略语言的“集合运算符”在策略中比较它们。在上一个示例中,ForAnyValue:StringLike 声明如果附加到正在评估的版本的任一标签与“AWSCURRENT”匹配,则该语句匹配并应用 Effect

有关更多使用 Secrets Manager 的基于资源的策略示例,请参阅使用 Secrets Manager 的基于资源的策略。有关使用基于资源的策略而非 IAM 角色 (基于身份的策略) 的其他信息,请参阅 IAM 用户指南 中的 IAM 角色与基于资源的策略有何不同