为设置服务角色 AWS Clean Rooms - AWS Clean Rooms

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

为设置服务角色 AWS Clean Rooms

以下各节描述了执行每项任务所需的角色。

创建管理员用户

要使用 AWS Clean Rooms,您需要为自己创建一个管理员用户,并将该管理员用户添加到管理员组中。

要创建管理员用户,请选择以下选项之一。

选择一种方法来管理您的管理员 目的 方式 您也可以
在 IAM Identity Center 中

(建议)

使用短期凭证访问 AWS。

这符合安全最佳实操。有关最佳实践的信息,请参阅《IAM 用户指南》中的 IAM 中的安全最佳实践

有关说明,请参阅《AWS IAM Identity Center 用户指南》中的入门 通过在《AWS Command Line Interface 用户指南》 AWS IAM Identity Center中配置 AWS CLI 要使用的来配置编程访问权限。
在 IAM 中

(不推荐使用)

使用长期凭证访问 AWS。 按照《IAM 用户指南》中的创建用于紧急访问的 IAM 用户中的说明进行操作。 按照《IAM 用户指南》中的管理 IAM 用户的访问密钥,配置编程式访问。

为协作成员创建 IAM 角色

成员是指作为协作参与者的 AWS 客户。

为协作成员创建 IAM 角色
  1. 请按照《AWS Identity and Access Management 用户指南》创建向 IAM 用户委派权限的角色步骤中的说明进行操作。

  2. 创建策略步骤中,选择策略编辑器中的 JSON 选项卡,然后根据授予协作成员的能力添加策略。

    AWS Clean Rooms 根据常见用例提供以下托管策略。

    有关提供的不同托管策略的信息 AWS Clean RoomsAWS 的托管策略 AWS Clean Rooms,请参阅

创建服务角色以从 Amazon S3 读取数据

AWS Clean Rooms 使用服务角色从 Amazon S3 读取数据。

有两种方法可以创建此服务角色。

  • 如果您拥有创建服务角色所必需的 IAM 权限,请使用 AWS Clean Rooms 控制台创建服务角色。

  • 如果您没有iam:CreateRoleiam:CreatePolicyiam:AttachRolePolicy权限或想要手动创建 IAM 角色,请执行以下任一操作:

    • 使用以下步骤使用自定义信任策略创建服务角色。

    • 要求管理员使用以下步骤创建服务角色。

注意

只有在您没有使用 AWS Clean Rooms 控制台创建服务角色的必要权限时,您或您的 IAM 管理员才应遵循此过程。

使用自定义信任策略创建服务角色以从 Amazon S3 读取数据
  1. 使用自定义信任策略创建角色。有关更多信息,请参阅《AWS Identity and Access Management 用户指南》中的 “使用自定义信任策略创建角色(控制台)” 过程。

  2. 根据使用自定义信任策略创建角色(控制台)步骤使用以下自定义信任策略。

    注意

    如果您想帮助确保该角色仅在特定的协作成员资格环境中使用,则可以进一步缩小信任策略的范围。有关更多信息,请参阅 防止跨服务混淆代理

    JSON
    { "Version": "2012-10-17", "Statement": [ { "Sid": "RoleTrustPolicyForCleanRoomsService", "Effect": "Allow", "Principal": { "Service": "cleanrooms.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }
  3. 根据使用自定义信任策略创建角色(控制台)步骤使用以下权限策略。

    注意

    以下示例策略支持读取 AWS Glue 元数据及其相应的 Amazon S3 数据所需的权限。但是,根据您设置 Amazon S3 数据的方式,您可能需要修改此政策。例如,如果您为 Amazon S3 数据设置了自定义 KMS 密钥,则可能需要使用额外 AWS Key Management Service (AWS KMS) 权限修改此政策。

    您的 AWS Glue 资源和底层 Amazon S3 资源必须与 AWS Clean Rooms 协作 AWS 区域 相同。

    JSON
    { "Version": "2012-10-17", "Statement": [ { "Sid": "NecessaryGluePermissions", "Effect": "Allow", "Action": [ "glue:GetDatabase", "glue:GetDatabases", "glue:GetTable", "glue:GetTables", "glue:GetPartition", "glue:GetPartitions", "glue:BatchGetPartition" ], "Resource": [ "arn:aws:glue:us-east-1:111122223333:database/databaseName", "arn:aws:glue:us-east-1:111122223333:table/databaseName/tableName", "arn:aws:glue:us-east-1:111122223333:catalog" ] }, { "Effect": "Allow", "Action": [ "glue:GetSchema", "glue:GetSchemaVersion" ], "Resource": [ "*" ] }, { "Sid": "NecessaryS3BucketPermissions", "Effect": "Allow", "Action": [ "s3:GetBucketLocation", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::bucket" ], "Condition": { "StringEquals": { "s3:ResourceAccount": [ "444455556666" ] } } }, { "Sid": "NecessaryS3ObjectPermissions", "Effect": "Allow", "Action": [ "s3:GetObject" ], "Resource": [ "arn:aws:s3:::bucket/prefix/*" ], "Condition": { "StringEquals": { "s3:ResourceAccount": [ "444455556666" ] } } } ] }
    注意

    该策略引用了两种不同的策略 AWS 账户 IDs 来支持由不同各方管理数据目录元数据和实际数据存储的 AWS Clean Rooms 协作:

    • 111122223333-这是拥有 AWS Glue 数据目录资源(数据库、表和目录)的帐户。第一条语句授予访问该账户 AWS Glue 目录中的表架构、分区信息和元数据的权限。

    • 444455556666- 这个账户拥有包含实际数据文件的 Amazon S3 存储桶。根据s3:ResourceAccount条件,Amazon S3 权限(声明 3 和声明 4)仅限于该账户拥有的存储桶。

    此配置支持常见的企业数据架构,其中一个团队管理数据目录和架构定义,而另一个团队则拥有底层的数据存储基础架构。该s3:ResourceAccount条件通过确保 Amazon S3 操作仅适用于指定账户拥有的存储桶,从而提供了额外的安全层。

  4. 将每个 placeholder 替换为您自己的信息。

  5. 继续按照使用自定义信任策略创建角色(控制台)步骤创建角色。

创建服务角色以读取来自亚马逊 Athena 的数据

AWS Clean Rooms 使用服务角色从 Amazon Athena 读取数据。

使用自定义信任策略创建服务角色以从 Athena 读取数据
  1. 使用自定义信任策略创建角色。有关更多信息,请参阅《AWS Identity and Access Management 用户指南》中的 “使用自定义信任策略创建角色(控制台)” 过程。

  2. 根据使用自定义信任策略创建角色(控制台)步骤使用以下自定义信任策略。

    注意

    如果您想帮助确保该角色仅在特定的协作成员资格环境中使用,则可以进一步缩小信任策略的范围。有关更多信息,请参阅 防止跨服务混淆代理

    JSON
    { "Version": "2012-10-17", "Statement": [ { "Sid": "RoleTrustPolicyForCleanRoomsService", "Effect": "Allow", "Principal": { "Service": "cleanrooms.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }
  3. 根据使用自定义信任策略创建角色(控制台)步骤使用以下权限策略。

    注意

    以下示例策略支持读取 AWS Glue 元数据及其相应的 Athena 数据所需的权限。但是,根据您设置 Amazon S3 数据的方式,您可能需要修改此政策。例如,如果您已经为自己的 Amazon S3 数据设置了自定义 KMS 密钥,则可能需要修改此政策,使其具有额外的 AWS KMS 权限。

    您的 AWS Glue 资源和底层 Athena 资源必须与协作 AWS 区域 相同。 AWS Clean Rooms

    JSON
    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "athena:GetDataCatalog", "athena:GetWorkGroup", "athena:GetTableMetadata", "athena:GetQueryExecution", "athena:GetQueryResults", "athena:StartQueryExecution" ], "Resource": [ "arn:aws:athena:us-east-1:111122223333:workgroup/workgroup", "arn:aws:athena:us-east-1:111122223333:datacatalog/AwsDataCatalog" ] }, { "Effect": "Allow", "Action": [ "glue:GetDatabase", "glue:GetTable", "glue:GetPartitions" ], "Resource": [ "arn:aws:glue:us-east-1:111122223333:catalog", "arn:aws:glue:us-east-1:111122223333:database/database name", "arn:aws:glue:us-east-1:111122223333:table/database name/table name" ] }, { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:GetBucketLocation", "s3:AbortMultipartUpload", "s3:ListBucket", "s3:PutObject", "s3:ListMultipartUploadParts" ], "Resource": [ "arn:aws:s3:::bucket", "arn:aws:s3:::bucket/*" ] }, { "Effect": "Allow", "Action": "lakeformation:GetDataAccess", "Resource": "*" }, { "Effect": "Allow", "Action": [ "kms:GenerateDataKey", "kms:Decrypt" ], "Resource": "arn:aws:kms:us-east-1:111122223333:key/*" } ] }
  4. 将每个 placeholder 替换为您自己的信息。

  5. 继续按照使用自定义信任策略创建角色(控制台)步骤创建角色。

设置 Lake Formation 权限

如果您查询受 Lake Formation 权限保护的资源,则服务角色必须对存储视图的 AWS Glue 数据库具有选择 table/view 和描述访问权限以及描述权限。

有关更多信息,请参阅:

创建服务角色以从 Snowflake 读取数据

AWS Clean Rooms 使用服务角色检索您的凭据,让 Snowflake 从该来源读取您的数据。

可以使用两种方法创建此服务角色:

  • 如果您拥有创建服务角色所必需的 IAM 权限,请使用 AWS Clean Rooms 控制台创建服务角色。

  • 如果您没有iam:CreateRoleiam:CreatePolicyiam:AttachRolePolicy权限或想要手动创建 IAM 角色,请执行以下任一操作:

    • 使用以下步骤使用自定义信任策略创建服务角色。

    • 要求管理员使用以下步骤创建服务角色。

注意

只有在您没有使用 AWS Clean Rooms 控制台创建服务角色的必要权限时,您或您的 IAM 管理员才应遵循此过程。

使用自定义信任策略创建服务角色以从 Snowflake 读取数据
  1. 使用自定义信任策略创建角色。有关更多信息,请参阅《AWS Identity and Access Management 用户指南》中的 “使用自定义信任策略创建角色(控制台)” 过程。

  2. 根据使用自定义信任策略创建角色(控制台)步骤使用以下自定义信任策略。

    注意

    如果您想帮助确保该角色仅在特定的协作成员资格环境中使用,则可以进一步缩小信任策略的范围。有关更多信息,请参阅 防止跨服务混淆代理

    JSON
    { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowIfSourceArnMatches", "Effect": "Allow", "Principal": { "Service": "cleanrooms.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "ForAnyValue:ArnEquals": { "aws:SourceArn": [ "arn:aws:cleanrooms:us-east-1:111122223333:membership/membershipId", "arn:aws:cleanrooms:us-east-1:444455556666:membership/queryRunnerMembershipId" ] } } } ] }
    注意

    此信任策略引用了两种不同的策略 AWS 账户 IDs 来支持将查询执行责任分配给多方的 AWS Clean Rooms 协作:

    • 111122223333-该账户包含参与协作的成员资格。该成员可能拥有数据表、分析规则或其他需要角色访问权限的协作资源。

    • 444455556666-此帐户包含负责运行查询的成员资格(“查询运行器”)。此成员资格执行受保护的查询,并且需要担任此角色才能访问必要的计算和数据资源。

    此配置支持一方提供数据或分析模板而另一方运行实际查询的场景。通过相同的执行角色,这两个角色都需要不同但互补的权限。该aws:SourceArn条件可确保只有源自这两个特定成员资格的 AWS Clean Rooms 操作才能担任该角色,从而在支持分布式作业执行和结果管理工作流程的同时维护安全性。

  3. 根据使用自定义信任策略创建角色(控制台)过程使用以下权限策略之一。

    使用客户拥有的 KMS 密钥加密的机密的权限策略

    JSON
    { "Version": "2012-10-17", "Statement": [ { "Action": "secretsmanager:GetSecretValue", "Resource": "arn:aws:secretsmanager:us-east-1:111122223333:secret:secretIdentifier", "Effect": "Allow" }, { "Sid": "AllowDecryptViaSecretsManagerForKey", "Action": "kms:Decrypt", "Resource": "arn:aws:kms:us-east-1:444455556666:key/keyIdentifier", "Effect": "Allow", "Condition": { "StringEquals": { "kms:ViaService": "secretsmanager.us-east-1.amazonaws.com", "kms:EncryptionContext:SecretARN": "arn:aws:secretsmanager:us-east-1:111122223333:secret:secretIdentifier" } } } ] }
    注意

    该政策引用了两种不同的策略 AWS 账户 IDs 来支持跨账户密钥管理方案:

    • 111122223333- 这是拥有和存储秘密的账户。第一条语句授予从该账户检索机密值的权限。

    • 444455556666-这是拥有用于加密密钥的 AWS KMS 密钥的账户。第二条语句授予使用该账户的密钥解密密密 AWS KMS 钥的权限。

    此配置在企业环境中很常见,其中:

    • 在一个账户(账户 1)中集中管理密钥

    • 加密密钥由单独的安全账户或共享服务账户(账户 2)管理

    • 账户 2 中的 AWS KMS 密钥策略还必须允许账户 1 中的服务使用该密钥进行 encryption/decryption 操作

    kms:EncryptionContext:SecretARN条件可确保 AWS KMS 密钥只能用于解密此特定机密,从而为跨账户访问提供额外的安全保护。

    使用加密的机密的权限策略 AWS 托管式密钥

    JSON
    { "Version": "2012-10-17", "Statement": [ { "Action": "secretsmanager:GetSecretValue", "Resource": "arn:aws:secretsmanager:us-east-1:111122223333:secret:secretIdentifier", "Effect": "Allow" } ] }
  4. 将每个 placeholder 替换为您自己的信息。

  5. 继续按照使用自定义信任策略创建角色(控制台)步骤创建角色。

创建用于从 S3 存储桶读取代码的服务角色(PySpark 分析模板角色)

AWS Clean Rooms 使用 PySpark 分析模板时,使用服务角色从协作成员的指定 S3 存储桶中读取代码。

创建服务角色以从 S3 存储桶读取代码
  1. 使用自定义信任策略创建角色。有关更多信息,请参阅《AWS Identity and Access Management 用户指南》中的 “使用自定义信任策略创建角色(控制台)” 过程。

  2. 根据使用自定义信任策略创建角色(控制台)步骤使用以下自定义信任策略。

    JSON
    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "cleanrooms.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "ForAnyValue:ArnEquals": { "aws:SourceArn": [ "arn:aws:cleanrooms:us-east-1:111122223333:membership/jobRunnerMembershipId", "arn:aws:cleanrooms:us-east-1:444455556666:membership/analysisTemplateOwnerMembershipId" ] } } } ] }
    注意

    此信任策略引用了两种不同的策略 AWS 账户 IDs 来支持多方 AWS Clean Rooms 协作场景:

    • 111122223333-该账户包含负责运行查询的成员资格(“作业运行者”)。该成员资格执行分析作业,需要担任此角色才能访问必要的资源。

    • 444455556666-这是拥有分析模板及其关联成员资格(“分析模板所有者”)的账户。此成员资格定义了可以运行哪些查询,还需要担任此角色来管理和执行分析。

    这种配置在多方参与同一个 AWS Clean Rooms 协作的协作中很常见,每方都有自己的 AWS 账户 成员资格。查询执行者和分析模板所有者都需要访问共享资源。该aws:SourceArn条件可确保只有源于这两个特定成员身份的 AWS Clean Rooms 操作才能担任该角色,从而为多方协作提供精确的访问控制。

  3. 根据使用自定义信任策略创建角色(控制台)步骤使用以下权限策略。

    注意

    以下示例策略支持从 Amazon S3 读取您的代码所需的权限。但是,您可能需要修改此策略,具体取决于您设置 S3 数据的方式。

    您的 Amazon S3 资源必须与 AWS Clean Rooms 协作资源 AWS 区域 相同。

    JSON
    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:GetObjectVersion" ], "Resource": ["arn:aws:s3:::s3Path"], "Condition":{ "StringEquals":{ "s3:ResourceAccount":[ "s3BucketOwnerAccountId" ] } } } ] }
  4. 用你自己的信息替换每一个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

  5. 继续按照使用自定义信任策略创建角色(控制台)步骤创建角色。

创建服务角色以写入 PySpark 作业结果

AWS Clean Rooms 使用服务角色将 PySpark 任务的结果写入指定的 S3 存储桶。

创建用于写入 PySpark 作业结果的服务角色
  1. 使用自定义信任策略创建角色。有关更多信息,请参阅《AWS Identity and Access Management 用户指南》中的 “使用自定义信任策略创建角色(控制台)” 过程。

  2. 根据使用自定义信任策略创建角色(控制台)步骤使用以下自定义信任策略。

    JSON
    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "cleanrooms.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "ForAnyValue:ArnEquals": { "aws:SourceArn": [ "arn:aws:cleanrooms:us-east-1:111122223333:membership/jobRunnerMembershipId", "arn:aws:cleanrooms:us-east-1:444455556666:membership/rrMembershipId" ] } } } ] }
    注意

    该信任策略引用了两种不同的策略 AWS 账户 IDs 来支持具有不同运营角色的 AWS Clean Rooms 协作:

    • 111122223333-该账户包含负责运行分析作业的成员资格(“作业运行者”)。此成员资格负责执行计算工作负载,并且需要担任此角色才能访问处理资源。

    • 444455556666-该账户包含具有结果接收者 (RR) 责任的成员资格。该成员资格有权接收和访问分析作业的输出,并且需要角色访问权限才能将结果写入指定位置。

    这种配置支持一方运行计算分析,而另一方接收并管理结果的 AWS Clean Rooms 场景。通过相同的执行角色,这两个角色都需要不同但互补的权限。该aws:SourceArn条件可确保只有源自这两个特定成员资格的 AWS Clean Rooms 操作才能担任该角色,从而在支持分布式作业执行和结果管理工作流程的同时维护安全性。

  3. 根据使用自定义信任策略创建角色(控制台)步骤使用以下权限策略。

    注意

    以下示例策略支持写入 Amazon S3 所需的权限。但是,您可能需要修改此策略,具体取决于您设置 S3 的方式。

    您的 Amazon S3 资源必须与 AWS Clean Rooms 协作资源 AWS 区域 相同。

    JSON
    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:PutObject" ], "Resource": "arn:aws:s3:::bucket/optionalPrefix/*", "Condition":{ "StringEquals":{ "s3:ResourceAccount":[ "s3BucketOwnerAccountId" ] } } }, { "Effect": "Allow", "Action": [ "s3:GetBucketLocation", "s3:ListBucket" ], "Resource": "arn:aws:s3:::bucket", "Condition":{ "StringEquals":{ "s3:ResourceAccount":[ "s3BucketOwnerAccountId" ] } } } ] }
  4. 用你自己的信息替换每一个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。

  5. 继续按照使用自定义信任策略创建角色(控制台)步骤创建角色。

创建服务角色来接收结果

注意

如果您是只能接收结果的成员(在控制台中,您的成员能力为仅接收结果),请按照以下步骤操作。

如果您是既能查询也能接收结果的成员(在控制台中,您的成员能力既是查询又是接收结果),则可以跳过此步骤。

对于只能接收结果的协作成员, AWS Clean Rooms 使用服务角色将协作中查询数据的结果写入指定的 S3 存储桶。

可以使用两种方法创建此服务角色:

  • 如果您拥有创建服务角色所必需的 IAM 权限,请使用 AWS Clean Rooms 控制台创建服务角色。

  • 如果您没有iam:CreateRoleiam:CreatePolicyiam:AttachRolePolicy权限或想要手动创建 IAM 角色,请执行以下任一操作:

    • 使用以下步骤使用自定义信任策略创建服务角色。

    • 要求管理员使用以下步骤创建服务角色。

注意

只有在您没有使用 AWS Clean Rooms 控制台创建服务角色的必要权限时,您或您的 IAM 管理员才应遵循此过程。

使用自定义信任策略创建用于接收结果的服务角色
  1. 使用自定义信任策略创建角色。有关更多信息,请参阅《AWS Identity and Access Management 用户指南》中的 “使用自定义信任策略创建角色(控制台)” 过程。

  2. 根据使用自定义信任策略创建角色(控制台)步骤使用以下自定义信任策略。

    JSON
    { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowIfExternalIdMatches", "Effect": "Allow", "Principal": { "Service": "cleanrooms.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "ArnLike": { "sts:ExternalId": "arn:aws:*:region:*:dbuser:*/a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa*" } } }, { "Sid": "AllowIfSourceArnMatches", "Effect": "Allow", "Principal": { "Service": "cleanrooms.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "ForAnyValue:ArnEquals": { "aws:SourceArn": [ "arn:aws:cleanrooms:us-east-1:555555555555:membership/a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa" ] } } } ] }
  3. 根据使用自定义信任策略创建角色(控制台)步骤使用以下权限策略。

    注意

    以下示例策略支持读取 AWS Glue 元数据及其相应的 Amazon S3 数据所需的权限。但是,您可能需要修改此策略,具体取决于您设置 S3 数据的方式。

    您的 AWS Glue 资源和底层 Amazon S3 资源必须与 AWS Clean Rooms 协作 AWS 区域 相同。

    JSON
    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetBucketLocation", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::bucket_name" ], "Condition": { "StringEquals": { "aws:ResourceAccount":"accountId" } } }, { "Effect": "Allow", "Action": [ "s3:PutObject" ], "Resource": [ "arn:aws:s3:::bucket_name/optional_key_prefix/*" ], "Condition": { "StringEquals": { "aws:ResourceAccount":"accountId" } } } ] }
  4. 用你自己的信息替换每一个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 存储桶的属性选项卡上找到。

  5. 继续按照使用自定义信任策略创建角色(控制台)步骤创建角色。