对于新项目,建议您使用新的适用于 Apache Flink Studio 的托管服务,而不是使用 Kinesis Data Analytics for SQL 应用程序。Managed Service for Apache Flink Studio 不仅操作简单,还具有高级分析功能,使您能够在几分钟内构建复杂的流处理应用程序。
本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
管理 资源的访问权限概述
警告
对于新项目,建议您使用全新适用于 Apache Flink Studio 的托管服务,而不是适用于 SQL 应用程序的托管服务。Managed Service for Apache Flink Studio 不仅操作简单,还具有高级分析功能,使您能够在几分钟内构建复杂的流处理应用程序。
要提供访问权限,请为您的用户、组或角色添加权限:
-
中的用户和群组 AWS IAM Identity Center:
创建权限集合。按照《AWS IAM Identity Center 用户指南》中创建权限集的说明进行操作。
-
通过身份提供商在 IAM 中托管的用户:
创建适用于身份联合验证的角色。按照《IAM 用户指南》中为第三方身份提供商创建角色(联合身份验证)的说明进行操作。
-
IAM 用户:
-
创建您的用户可以担任的角色。按照《IAM 用户指南》中为 IAM 用户创建角色的说明进行操作。
-
(不推荐使用)将策略直接附加到用户或将用户添加到用户组。按照《IAM 用户指南》中向用户添加权限(控制台)中的说明进行操作。
-
注意
账户管理员(或管理员用户)是具有管理员权限的用户。有关更多信息,请参阅《IAM 用户指南》中的 IAM 最佳实操。
资源和操作
在 中,主要资源是应用程序。在策略中,您可以使用 Amazon 资源名称(ARN)标识策略应用到的资源。
这些资源具有关联的唯一 Amazon 资源名称 (ARN),如下表所示。
资源类型 | ARN 格式 |
---|---|
应用程序 |
|
提供一组操作用来处理资源。有关可用操作的列表,请参阅 操作。
了解资源所有权
AWS 账户 拥有在账户中创建的资源,无论谁创建了这些资源。具体而言,资源所有者是 AWS 账户 对资源创建请求进行身份验证的委托人实体(即根账户、用户或 IAM 角色)。以下示例说明了它的工作原理:
-
如果您使用您的 AWS 账户 根账户证书创建应用程序,则您 AWS 账户 就是该资源的所有者。(在 中,资源是应用程序。)
-
如果您在中创建用户 AWS 账户 并向该用户授予创建应用程序的权限,则该用户可以创建应用程序。但是,用户所属的您 AWS 账户拥有应用程序资源。强烈建议您向角色而不是用户授予权限。
-
如果您在中创建 AWS 账户 具有创建应用程序权限的 IAM 角色,则任何能够担任该角色的人都可以创建应用程序。用户 AWS 账户所属的您拥有应用程序资源。
管理对资源的访问
权限策略规定谁可以访问哪些内容。下一节介绍创建权限策略时的可用选项。
注意
本节讨论如何在 范围内使用 IAM。这里不提供有关 IAM 服务的详细信息。有关完整的 IAM 文档,请参阅《IAM 用户指南》中的什么是 IAM?。有关 IAM policy 语法和说明的信息,请参阅 IAM 用户指南中的 IAM JSON 策略参考。
附加到 IAM 身份的策略称作基于身份的策略 (IAM policy)。附加到资源的策略称作基于资源的策略。 仅支持基于身份的策略 (IAM policy)。
基于身份的策略(IAM 策略)
您可以向 IAM 身份附加策略。例如,您可以执行以下操作:
-
将权限策略附加到您账户中的用户或组 - 要向用户授予创建 资源 (例如应用程序) 的权限,您可以将权限策略附加到用户或用户所属的组。
-
向角色附加权限策略(授予跨账户权限) – 您可以向 IAM 角色附加基于身份的权限策略,以授予跨账户的权限。例如,账户 A 中的管理员可以创建一个角色来向其他账户 AWS 账户 (例如账户 B)或 Amazon 服务授予跨账户权限,如下所示:
-
账户 A 管理员可以创建一个 IAM 角色,然后向该角色附加授予其访问账户 A 中资源的权限策略。
-
账户 A 管理员可以向角色挂载信任策略,将账户 B 标识为能够担任该角色的委托人。
-
之后,账户 B 管理员可以委托权限,指派账户 B 中的任何用户代入该角色。这样,账户 B 中的用户就可以在账户 A 中创建或访问资源了。如果您需要授予 Amazon 服务权限来代入该角色,则信任策略中的委托人也可以是 Amazon 服务委托人。
有关使用 IAM 委托权限的更多信息,请参阅 IAM 用户指南中的访问权限管理。
-
下面是为 kinesisanalytics:CreateApplication
操作授予权限的示例策略,需要具有该权限才能创建 应用程序。
注意
这是介绍性示例策略。当您将策略附加到用户时,用户将能够使用 AWS CLI 或 AWS SDK 创建应用程序。但用户需要更多权限才能配置输入和输出。此外,使用控制台时,用户需要更多权限。后续章节将提供更多相关信息。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "Stmt1473028104000", "Effect": "Allow", "Action": [ "kinesisanalytics:CreateApplication" ], "Resource": [ "*" ] } ] }
有关对 使用基于身份的策略的更多信息,请参阅 为 使用基于身份的策略(IAM 策略) 。有关用户、组、角色和权限的更多信息,请参阅《IAM 用户指南》https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html中的身份(用户、组和角色)。
基于资源的策略
其他服务(如 Amazon S3)还支持基于资源的权限策略。例如,您可以将基于资源的策略附加到 S3 存储桶以管理对该存储桶的访问权限。 不支持基于资源的策略。
指定策略元素:操作、效果和主体
对于每种 资源,该服务都定义了一组 API 操作。为授予这些 API 操作的权限, 定义了一组您可以在策略中指定的操作。某些 API 操作可能需要多个操作的权限才能执行 API 操作。有关资源和 API 操作的更多信息,请参阅 资源和操作 和 操作。
以下是最基本的策略元素:
-
资源 – 您使用 Amazon 资源名称(ARN)来标识策略应用到的资源。有关更多信息,请参阅 资源和操作。
-
操作 – 您可以使用操作关键字标识要允许或拒绝的资源操作。例如,您可以使用
create
允许用户创建应用程序。 -
效果 – 用于指定用户请求特定操作时的效果(可以是允许或拒绝)。如果没有显式授予(允许)对资源的访问权限,则隐式拒绝访问。您也可显式拒绝对资源的访问,这样可确保用户无法访问该资源,即使有其他策略授予了访问权限的情况下也是如此。
-
主体 – 在基于身份的策略 (IAM policy) 中,附加了策略的用户是隐式主体。对于基于资源的策略,您可以指定要接收权限的用户、账户、服务或其他实体(仅适用于基于资源的策略)。 不支持基于资源的策略。
有关 IAM policy 语法和介绍的更多信息,请参阅 IAM 用户指南中的 IAM JSON 策略参考。
有关显示所有 API 操作及其适用于的资源的表,请参阅 API 权限:操作、权限和资源参考。
在策略中指定条件
当您授予权限时,可使用访问策略语言来指定规定策略何时生效的条件。例如,您可能希望策略仅在特定日期后应用。有关使用策略语言指定条件的更多信息,请参阅《IAM 用户指南》中的条件。
要表示条件,您可以使用预定义的条件键。没有特定于 的条件键。但是,您可以根据需要使用 AWS范围内的条件键。有关 AWS范围密钥的完整列表,请参阅 IAM 用户指南中的条件可用密钥。