本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
为设置服务角色 AWS Clean Rooms
以下各节描述了执行每项任务所需的角色。
主题
为协作成员创建 IAM 角色
成员是参与协作的 AWS 客户。
为协作成员创建 IAM 角色
-
请按照《AWS Identity and Access Management 用户指南》的创建向 IAM 用户委派权限的角色步骤中的说明进行操作。
-
在创建策略步骤中,选择策略编辑器中的 JSON 选项卡,然后根据授予协作成员的能力添加策略。
AWS Clean Rooms 根据常见用例提供以下托管策略。
如果要... 然后使用... 查看资源和元数据 AWS 管理策略:AWSCleanRoomsReadOnlyAccess Query AWS 管理策略:AWSCleanRoomsFullAccess 查询和运行作业 AWS 管理策略:AWSCleanRoomsFullAccess 查询和接收结果 AWS 管理策略:AWSCleanRoomsFullAccess 管理协作资源但不查询 AWS 管理策略:AWSCleanRoomsFullAccessNoQuerying 有关提供的不同托管策略的信息 AWS Clean RoomsAWS 的托管策略 AWS Clean Rooms,请参阅
创建服务角色以从 Amazon S3 读取数据
AWS Clean Rooms 使用服务角色从 Amazon S3 读取数据。
有两种方法可以创建此服务角色。
-
如果您拥有创建服务角色所必需的 IAM 权限,请使用 AWS Clean Rooms 控制台创建服务角色。
-
如果您没有
iam:CreateRoleiam:CreatePolicy、iam:AttachRolePolicy权限或想手动创建 IAM 角色,请执行以下任一操作:-
使用以下过程使用自定义信任策略创建服务角色。
-
要求管理员使用以下步骤创建服务角色。
-
注意
只有当您没有使用 AWS Clean Rooms 控制台创建服务角色所需的权限时,您或您的 IAM 管理员才应遵循此程序。
创建服务角色以使用自定义信任策略从 Amazon S3 读取数据
-
使用自定义信任策略创建角色。有关更多信息,请参阅《AWS Identity and Access Management 用户指南》中的使用自定义信任策略(控制台)创建角色过程。
-
根据使用自定义信任策略创建角色(控制台)步骤使用以下自定义信任策略。
注意
如果您想帮助确保该角色仅在特定协作成员的背景下使用,则可以进一步缩小信任政策的范围。有关更多信息,请参阅 Cross-service 困惑的副手预防。
-
根据使用自定义信任策略创建角色(控制台)步骤使用以下权限策略。
注意
以下示例策略支持读取 AWS Glue 元数据及其相应的 Amazon S3 数据所需的权限。但是,您可能需要修改此策略,具体取决于您设置 Amazon S3 数据的方式。例如,如果您为 Amazon S3 数据设置了自定义 KMS 密钥,则可能需要使用额外 AWS Key Management Service (AWS KMS) 权限修改此政策。
您的 AWS Glue 资源和基础 Amazon S3 资源必须与 AWS Clean Rooms 协 AWS 区域 作相同。
注意
该政策引用了两个不同的 AWS 账户 ID 来支持由不同方管理数据目录元数据和实际数据存储的 AWS Clean Rooms 协作:
-
111122223333 -这是拥有 AWS Glue 数据目录资源(数据库、表和目录)的账户。第一条语句授予访问该账户 AWS Glue 目录中的表架构、分区信息和元数据的权限。
-
444455556666 -该账户拥有包含实际数据文件的 Amazon S3 存储桶。根据
s3:ResourceAccount条件,Amazon S3 权限(声明 3 和 4)仅限于该账户拥有的存储桶。
此配置支持常见的企业数据架构,其中一个团队管理数据目录和架构定义,而另一个团队拥有底层数据存储基础架构。该
s3:ResourceAccount条件通过确保 Amazon S3 操作仅适用于指定账户拥有的存储桶来提供额外的安全层。 -
-
将每个
placeholder替换为您自己的信息。 -
继续按照使用自定义信任策略创建角色(控制台)步骤创建角色。
创建服务角色以从 Amazon Athena 读取数据
AWS Clean Rooms 使用服务角色从亚马逊 Athena 读取数据。
创建服务角色以使用自定义信任策略从 Athena 读取数据
-
使用自定义信任策略创建角色。有关更多信息,请参阅《AWS Identity and Access Management 用户指南》中的使用自定义信任策略(控制台)创建角色过程。
-
根据使用自定义信任策略创建角色(控制台)步骤使用以下自定义信任策略。
注意
如果您想帮助确保该角色仅在特定协作成员的背景下使用,则可以进一步缩小信任政策的范围。有关更多信息,请参阅 Cross-service 困惑的副手预防。
-
根据使用自定义信任策略创建角色(控制台)步骤使用以下权限策略。
注意
以下示例策略支持读取 AWS Glue 元数据及其相应的 Athena 数据所需的权限。但是,您可能需要修改此策略,具体取决于您设置 Amazon S3 数据的方式。例如,如果您已经为您的 Amazon S3 数据设置了自定义 KMS 密钥,则可能需要使用额外的 AWS KMS 权限修改此政策。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "athena:GetWorkGroup", "athena:GetTableMetadata", "athena:GetDataCatalog", "athena:StartQueryExecution", "athena:GetQueryExecution", "athena:GetQueryResults" ], "Resource": [ "arn:aws:athena:region:accountId:workgroup/workgroup", "arn:aws:athena:region:accountId:datacatalog/federatedCatalogName" ] }, { "Effect": "Allow", "Action": [ "glue:GetDatabase", "glue:GetTable", "glue:GetCatalog" ], "Resource": [ "arn:aws:glue:region:accountId:catalog", "arn:aws:glue:region:accountId:catalog/federatedCatalogName", "arn:aws:glue:region:accountId:database/federatedCatalogName/databaseName", "arn:aws:glue:region:accountId:table/federatedCatalogName/databaseName/tableName" ] }, { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:GetBucketLocation", "s3:AbortMultipartUpload", "s3:ListBucket", "s3:PutObject", "s3:ListMultipartUploadParts" ], "Resource": [ "arn:aws:s3:::athenaResultsBucket", "arn:aws:s3:::athenaResultsBucket/*" ], "Condition": { "StringEquals": { "aws:ResourceAccount": "accountId" } } }, { "Effect": "Allow", "Action": "lakeformation:GetDataAccess", "Resource": "*" } ] } -
将每个
placeholder替换为您自己的信息。 -
继续按照使用自定义信任策略创建角色(控制台)步骤创建角色。
设置 Lake Formation 权限
如果您查询受 Lake Formation 权限保护的资源,则服务角色必须具有 table/view /catalog 的 “选择和描述” 访问权限以及对 AWS Glue 数据库的 “描述” 权限。
有关更多信息,请参阅:
-
使用 Athena 查询 AWS Lake Formation在《亚马逊 Athena 用户指南》中注册的数据
-
《AWS Lake Formation 开发者指南》中的 Lake Formation 权限入门
创建服务角色来从 Snowflake 读取数据
AWS Clean Rooms 使用服务角色检索您的证书,以便 Snowflake 从该来源读取您的数据。
可以使用两种方法创建此服务角色:
-
如果您拥有创建服务角色所必需的 IAM 权限,请使用 AWS Clean Rooms 控制台创建服务角色。
-
如果您没有
iam:CreateRoleiam:CreatePolicy、iam:AttachRolePolicy权限或想手动创建 IAM 角色,请执行以下任一操作:-
使用以下过程使用自定义信任策略创建服务角色。
-
要求管理员使用以下步骤创建服务角色。
-
注意
只有当您没有使用 AWS Clean Rooms 控制台创建服务角色所需的权限时,您或您的 IAM 管理员才应遵循此程序。
创建服务角色以使用自定义信任策略从 Snowflake 读取数据
-
使用自定义信任策略创建角色。有关更多信息,请参阅《AWS Identity and Access Management 用户指南》中的使用自定义信任策略(控制台)创建角色过程。
-
根据使用自定义信任策略创建角色(控制台)步骤使用以下自定义信任策略。
注意
如果您想帮助确保该角色仅在特定协作成员的背景下使用,则可以进一步缩小信任政策的范围。有关更多信息,请参阅 Cross-service 困惑的副手预防。
注意
此信任策略引用了两个不同的 AWS 账户 ID 来支持协作,在这种 AWS Clean Rooms 协作中,查询执行责任分散在多个方:
-
111122223333 -该账户包含参与协作的会员。该成员资格可能拥有数据表、分析规则或其他需要角色访问权限的协作资源。
-
444455556666 -该账户包含负责运行查询的成员资格(“查询运行器”)。该成员资格执行受保护的查询,需要代入此角色才能访问必要的计算和数据资源。
此配置支持一方提供数据或分析模板而另一方运行实际查询的场景。这两个角色通过相同的执行角色需要不同但互补的权限。该
aws:SourceArn条件确保只有源自这两个特定成员身份的 AWS Clean Rooms 操作才能担任该角色,从而在支持分布式任务执行和结果管理工作流程的同时维护安全。 -
-
根据使用自定义信任策略创建角色(控制台)程序,使用以下权限策略之一。
使用客户拥有的 KMS 密钥加密的机密的权限政策
注意
此政策引用了两个不同 AWS 账户 的 ID 来支持跨账户密钥管理方案:
-
111122223333 -这是拥有和存储密钥的账户。第一条语句授予从该账户检索机密值的权限。
-
444455556666 -该账户拥有用于加密 AWS KMS 密钥的密钥。第二条语句授予使用该账户的密钥解密密 AWS KMS 钥的权限。
这种配置在企业环境中很常见,其中:
-
密钥集中管理在一个账户(账户 1)中
-
加密密钥由单独的安全或共享服务帐户(账户 2)管理
-
账户 2 中的 AWS KMS 密钥政策还必须允许账户 1 中的服务使用该密钥进行 encryption/decryption 操作
该
kms:EncryptionContext:SecretARN条件确保密 AWS KMS 钥只能用于解密此特定机密,从而为跨账户访问提供额外的安全层。使用加密的机密的权限策略 AWS 托管式密钥
-
-
将每个
placeholder替换为您自己的信息。 -
继续按照使用自定义信任策略创建角色(控制台)步骤创建角色。
创建服务角色以从 S3 存储桶读取代码(PySpark 分析模板角色)
AWS Clean Rooms 使用 PySpark 分析模板时,使用服务角色从协作成员的指定 S3 存储桶读取代码。
创建服务角色以从 S3 存储桶读取代码
-
使用自定义信任策略创建角色。有关更多信息,请参阅《AWS Identity and Access Management 用户指南》中的使用自定义信任策略(控制台)创建角色过程。
-
根据使用自定义信任策略创建角色(控制台)步骤使用以下自定义信任策略。
注意
此信任策略引用了两个不同 AWS 账户 的 ID 来支持多方 AWS Clean Rooms 协作方案:
-
111122223333 -该账户包含负责运行查询的成员资格(“作业运行器”)。该成员资格执行分析作业,需要承担此角色才能访问必要的资源。
-
444455556666 -这是拥有分析模板及其关联成员资格的账户(“分析模板所有者”)。该成员资格定义了可以运行哪些查询,还需要承担此角色来管理和执行分析。
这种配置在多方参与同一个 AWS Clean Rooms 协作的协作中很常见,每方都有自己的 AWS 账户 成员资格。查询执行者和分析模板所有者都需要访问共享资源。该
aws:SourceArn条件确保只有源自这两个特定成员资格的 AWS Clean Rooms 操作才能担任该角色,从而为多方协作提供精确的访问控制。 -
-
根据使用自定义信任策略创建角色(控制台)步骤使用以下权限策略。
注意
以下示例策略支持从 Amazon S3 读取代码所需的权限。但是,您可能需要修改此策略,具体取决于您设置 S3 数据的方式。
您的 Amazon S3 资源必须与 AWS Clean Rooms 协 AWS 区域 作相同。
-
将它们
placeholder替换为你自己的信息:-
s3Path— 您的代码的 S3 存储桶位置。 -
s3BucketOwnerAccountId— S3 存储桶所有者的 AWS 账户 ID。 -
region- AWS 区域的名称。例如us-east-1。 -
jobRunnerAccountId— 可以运行查询和作业的成员的 AWS 账户 ID。 -
jobRunnerMembershipId— 可以查询和运行任务的成员的会员 ID。可以在协作的详细信息选项卡上找到成员身份 ID。这样可以确保 AWS Clean Rooms 只有当该成员在此次协作中进行分析时,该成员才会扮演角色。 -
analysisTemplateAccountId— 分析模板的 AWS 账户 ID。 -
analysisTemplateOwnerMembershipId— 拥有分析模板的成员的会员 ID。可以在协作的详细信息选项卡上找到成员身份 ID。
-
-
继续按照使用自定义信任策略创建角色(控制台)步骤创建角色。
创建服务角色来写 PySpark 作业结果
AWS Clean Rooms 使用服务角色将 PySpark 任务结果写入指定的 S3 存储桶。
创建服务角色来写 PySpark 作业结果
-
使用自定义信任策略创建角色。有关更多信息,请参阅《AWS Identity and Access Management 用户指南》中的使用自定义信任策略(控制台)创建角色过程。
-
根据使用自定义信任策略创建角色(控制台)步骤使用以下自定义信任策略。
注意
该信任政策引用了两个不同的 AWS 账户 ID 来支持具有不同运营角色的 AWS Clean Rooms 合作:
-
111122223333 -该账户包含负责运行分析作业的成员资格(“作业运行器”)。该成员资格执行计算工作负载,需要承担此角色才能访问处理资源。
-
444455556666 -该账户包含具有结果接收者 (RR) 责任的成员资格。该成员资格有权接收和访问分析作业的输出,并且需要角色访问权限才能将结果写入指定地点。
此配置支持一方运行计算分析,而另一方接收和管理结果 AWS Clean Rooms 的情况。这两个角色通过相同的执行角色需要不同但互补的权限。该
aws:SourceArn条件确保只有源自这两个特定成员资格的 AWS Clean Rooms 操作才能担任该角色,从而在支持分布式任务执行和结果管理工作流程的同时维护安全。 -
-
根据使用自定义信任策略创建角色(控制台)步骤使用以下权限策略。
注意
以下示例策略支持写入 Amazon S3 所需的权限。但是,您可能需要修改此策略,具体取决于您设置 S3 的方式。
您的 Amazon S3 资源必须与 AWS Clean Rooms 协 AWS 区域 作相同。
-
将它们
placeholder替换为你自己的信息:-
region- AWS 区域的名称。例如us-east-1。 -
jobRunnerAccountId— S3 存储桶所在的 AWS 账户 ID。 -
jobRunnerMembershipId— 可以查询和运行任务的成员的会员 ID。可以在协作的详细信息选项卡上找到成员身份 ID。这样可以确保 AWS Clean Rooms 只有当该成员在此次协作中进行分析时,该成员才会扮演角色。 -
rrAccountId— S3 存储桶所在的 AWS 账户 ID。 -
rrMembershipId— 可以接收结果的会员的会员ID。可以在协作的详细信息选项卡上找到成员身份 ID。这样可以确保 AWS Clean Rooms 只有当该成员在此次协作中进行分析时,该成员才会扮演角色。 -
bucket— S3 存储桶的名称和位置。 -
optionalPrefix— 如果您想将结果保存在特定的 S3 前缀下,则为可选前缀。 -
s3BucketOwnerAccountId— S3 存储桶所有者的 AWS 账户 ID。
-
-
继续按照使用自定义信任策略创建角色(控制台)步骤创建角色。
创建服务角色来接收结果
注意
如果您是只能接收结果的成员(在控制台中,您的成员能力为仅接收结果),请按照以下步骤操作。
如果您是既能查询也能接收结果的成员(在控制台中,您的成员能力既是查询又是接收结果),则可以跳过此步骤。
对于只能接收结果的协作成员, AWS Clean Rooms 使用服务角色将协作中查询数据的结果写入指定的 S3 存储桶。
可以使用两种方法创建此服务角色:
-
如果您拥有创建服务角色所必需的 IAM 权限,请使用 AWS Clean Rooms 控制台创建服务角色。
-
如果您没有
iam:CreateRoleiam:CreatePolicy、iam:AttachRolePolicy权限或想手动创建 IAM 角色,请执行以下任一操作:-
使用以下过程使用自定义信任策略创建服务角色。
-
要求管理员使用以下步骤创建服务角色。
-
注意
只有当您没有使用 AWS Clean Rooms 控制台创建服务角色所需的权限时,您或您的 IAM 管理员才应遵循此程序。
创建服务角色以使用自定义信任策略接收结果
-
使用自定义信任策略创建角色。有关更多信息,请参阅《AWS Identity and Access Management 用户指南》中的使用自定义信任策略(控制台)创建角色过程。
-
根据使用自定义信任策略创建角色(控制台)步骤使用以下自定义信任策略。
-
根据使用自定义信任策略创建角色(控制台)步骤使用以下权限策略。
注意
以下示例策略支持读取 AWS Glue 元数据及其相应的 Amazon S3 数据所需的权限。但是,您可能需要修改此策略,具体取决于您设置 S3 数据的方式。
您的 AWS Glue 资源和基础 Amazon S3 资源必须与 AWS Clean Rooms 协 AWS 区域 作相同。
-
将它们
placeholder替换为你自己的信息:-
region- AWS 区域的名称。例如us-east-1。 -
a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa— 可以查询的成员的会员 ID。可以在协作的详细信息选项卡上找到成员身份 ID。这样可以确保 AWS Clean Rooms 只有当该成员在此次协作中进行分析时,该成员才会扮演角色。 -
arn:aws:cleanrooms:us-east-1:555555555555:membership/a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa— 可以查询的成员的单一会员 ARN。可以在协作的详细信息选项卡上找到成员身份 ARN。这样可以确保 AWS Clean Rooms 只有当该成员在此次协作中进行分析时才担任该角色。 -
bucket_name— S3 存储桶的亚马逊资源名称 (ARN)。Amazon 资源名称 (ARN) 可在 Amazon S3 存储桶的属性选项卡上找到。 -
accountId— S3 存储桶所在的 AWS 账户 ID。bucket_name/optional_key_prefix— 亚马逊 S3 中结果目的地的亚马逊资源名称 (ARN)。Amazon 资源名称 (ARN) 可在 Amazon S3 存储桶的属性选项卡上找到。
-
-
继续按照使用自定义信任策略创建角色(控制台)步骤创建角色。