适用于 Amazon Glue 的基于身份的策略示例 - Amazon Glue
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 中国的 Amazon Web Services 服务入门 (PDF)

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

适用于 Amazon Glue 的基于身份的策略示例

默认情况下,用户和角色没有创建或修改 Amazon Glue 资源的权限。他们也无法使用 Amazon Web Services Management Console、Amazon Command Line Interface (Amazon CLI) 或 Amazon API 执行任务。要授予用户对所需资源执行操作的权限,IAM 管理员可以创建 IAM policy。然后,管理员可以向角色添加 IAM policy,并且用户可以代入角色。

要了解如何使用这些示例 JSON 策略文档创建基于 IAM 身份的策略,请参阅《IAM 用户指南》中的创建 IAM policy

有关 Amazon Glue 定义的操作和资源类型的详细信息,包括每种资源类型的 ARN 格式,请参阅服务授权参考中的 Amazon Glue 的操作、资源和条件键

注意

本节中提供的示例均使用 us-west-2 区域。您可以将其替换为要使用的 Amazon 区域。

策略最佳实操

基于身份的策略确定某个人是否可以创建、访问或删除您账户中的 Amazon Glue 资源。这些操作可能会使 Amazon Web Services 账户产生成本。创建或编辑基于身份的策略时,请遵循以下准则和建议:

  • Amazon 托管式策略及转向最低权限许可入门——要开始向用户和工作负载授予权限,请使用 Amazon 托管式策略来为许多常见使用场景授予权限。您可以在 Amazon Web Services 账户中找到这些策略。建议通过定义特定于您的使用场景的 Amazon 客户管理型策略来进一步减少权限。有关更多信息,请参阅《IAM 用户指南》中的 Amazon 托管式策略工作职能的 Amazon 托管式策略

  • 应用最低权限 – 在使用 IAM policy 设置权限时,请仅授予执行任务所需的权限。为此,您可以定义在特定条件下可以对特定资源执行的操作,也称为最低权限许可。有关使用 IAM 应用权限的更多信息,请参阅《IAM 用户指南》中的 IAM 中的策略和权限

  • 使用 IAM policy 中的条件进一步限制访问权限 – 您可以向策略添加条件来限制对操作和资源的访问。例如,您可以编写策略条件来指定必须使用 SSL 发送所有请求。如果通过特定 Amazon Web Service(例如 Amazon CloudFormation)使用服务操作,您还可以使用条件来授予对服务操作的访问权限。有关更多信息,请参阅《IAM 用户指南》中的 IAM JSON 策略元素:条件

  • 使用 IAM Access Analyzer 验证您的 IAM policy,以确保权限的安全性和功能性 – IAM Access Analyzer 会验证新策略和现有策略,以确保策略符合 IAM policy 语言 (JSON) 和 IAM 最佳实践。IAM Access Analyzer 提供 100 多项策略检查和可操作的建议,有助于制定安全且功能性强的策略。有关更多信息,请参阅《IAM 用户指南》中的 IAM Access Analyzer 策略验证

  • 需要多重身份验证 (MFA) – 如果您所处的场景要求您的 Amazon Web Services 账户 中有 IAM 用户或根用户,请启用 MFA 来提高安全性。要在调用 API 操作时需要 MFA,请将 MFA 条件添加到策略中。有关更多信息,请参阅《IAM 用户指南》中的配置受 MFA 保护的 API 访问

有关 IAM 中的最佳实践的更多信息,请参阅《IAM 用户指南》中的 IAM 中的安全最佳实践

资源级权限仅应用于特定的 Amazon Glue 对象

您只能定义 Amazon Glue 中特定对象的精细控制。因此,您必须编写客户端的 IAM policy,以便允许 Resource 语句的 Amazon Resource Name(ARN)的 API 操作与不允许使用 API 的操作不混合。

例如,以下 IAM policy 允许 GetClassifierGetJobRun 的 API 操作。它将 Resource 定义为 *,因为 Amazon Glue 不允许分类符和作业运行的 ARN。由于允许将 ARN 用于 GetDatabaseGetTable 等特定 API 操作,因此,可以在策略的第二部分中指定 ARN。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "glue:GetClassifier*", "glue:GetJobRun*" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "glue:Get*" ], "Resource": [ "arn:aws:glue:us-east-1:123456789012:catalog", "arn:aws:glue:us-east-1:123456789012:database/default", "arn:aws:glue:us-east-1:123456789012:table/default/e*1*", "arn:aws:glue:us-east-1:123456789012:connection/connection2" ] } ] }

有关允许 ARN 的 Amazon Glue 对象的列表,请参阅资源 ARN

使用 Amazon Glue 控制台

要访问 Amazon Glue 控制台,您必须拥有一组最低的权限。这些权限必须允许您列出和查看有关您的 Amazon Web Services 账户 中的 Amazon Glue 资源的详细信息。如果创建比必需的最低权限更为严格的基于身份的策略,对于附加了该策略的实体(用户或角色),控制台将无法按预期正常运行。

对于只需要调用 Amazon CLI 或 Amazon API 的用户,您无需为其提供最低控制台权限。相反,只允许访问与其尝试执行的 API 操作相匹配的操作。

为确保用户和角色仍可使用 Amazon Glue 控制台,请同时将 Amazon Glue ConsoleAccessReadOnly Amazon 托管策略添加到实体。有关更多信息,请参阅《IAM 用户指南》中的为用户添加权限

某个用户要能够使用 Amazon Glue 控制台,必须拥有一组允许其使用其 Amazon 账户的 Amazon Glue 资源的最低权限。除这些 Amazon Glue 权限以外,控制台还需要来自以下服务的权限:

  • 用于显示日志的 Amazon CloudWatch Logs 权限。

  • 用于列出并传递角色的 Amazon Identity and Access Management(IAM)权限。

  • 用于处理堆栈的 Amazon CloudFormation 权限。

  • 用于列出 VPC、子网、安全组、实例和其他对象的 Amazon Elastic Compute Cloud(Amazon EC2)权限。

  • 用于列出存储桶和对象以及检索和保存脚本的 Amazon Simple Storage Service(Amazon S3)权限。

  • 用于使用集群的 Amazon Redshift 权限。

  • 用于列出实例的 Amazon Relational Database Service(Amazon RDS)权限。

有关用户查看和使用 Amazon Glue 控制台所需的权限的更多信息,请参阅 步骤 3:将策略附加到访问 Amazon Glue 的用户或组

如果创建比必需的最低权限更为严格的 IAM policy,对于附加了该 IAM policy 的用户,控制台将无法按预期正常运行。为确保这些用户仍可使用 Amazon Glue 控制台,同时如 适用于 Amazon Glue 的 Amazon 托管(预定义)策略 中所述附加 AWSGlueConsoleFullAccess 托管策略。

允许用户查看他们自己的权限

该示例说明了您如何创建策略,以允许 IAM 用户查看附加到其用户身份的内联和托管策略。此策略包括在控制台上完成此操作或者以编程方式使用 Amazon CLI 或 Amazon API 所需的权限。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "ViewOwnUserInfo", "Effect": "Allow", "Action": [ "iam:GetUserPolicy", "iam:ListGroupsForUser", "iam:ListAttachedUserPolicies", "iam:ListUserPolicies", "iam:GetUser" ], "Resource": ["arn:aws:iam::*:user/${aws:username}"] }, { "Sid": "NavigateInConsole", "Effect": "Allow", "Action": [ "iam:GetGroupPolicy", "iam:GetPolicyVersion", "iam:GetPolicy", "iam:ListAttachedGroupPolicies", "iam:ListGroupPolicies", "iam:ListPolicyVersions", "iam:ListPolicies", "iam:ListUsers" ], "Resource": "*" } ] }

授予对表的只读权限

以下策略授予对数据库 db1 中的 books 表的只读权限。有关资源的 Amazon Resource Name(ARN)的更多信息,请参阅 数据目录 ARN

{ "Version": "2012-10-17", "Statement": [ { "Sid": "GetTablesActionOnBooks", "Effect": "Allow", "Action": [ "glue:GetTables", "glue:GetTable" ], "Resource": [ "arn:aws:glue:us-west-2:123456789012:catalog", "arn:aws:glue:us-west-2:123456789012:database/db1", "arn:aws:glue:us-west-2:123456789012:table/db1/books" ] } ] }

此策略授予对名为 db1 的数据库中的名为 books 的表的只读权限。要授予对表的 Get 权限,同时需要对目录和数据库资源授予这一权限。

以下策略授予在数据库 db1 中创建表 tb1 所需的最低权限:

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "glue:CreateTable" ], "Resource": [ "arn:aws:glue:us-west-2:123456789012:table/db1/tbl1", "arn:aws:glue:us-west-2:123456789012:database/db1", "arn:aws:glue:us-west-2:123456789012:catalog" ] } ] }

通过 GetTables 权限筛选表

假设在数据库 db1 中有三个表,即 customersstoresstore_sales。以下策略向 storesstore_sales 授予 GetTables 权限,但不向 customers 授予此权限。当您使用此策略调用 GetTables 时,结果将只包含两个授权表(不返回 customers 表)。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "GetTablesExample", "Effect": "Allow", "Action": [ "glue:GetTables" ], "Resource": [ "arn:aws:glue:us-west-2:123456789012:catalog", "arn:aws:glue:us-west-2:123456789012:database/db1", "arn:aws:glue:us-west-2:123456789012:table/db1/store_sales", "arn:aws:glue:us-west-2:123456789012:table/db1/stores" ] } ] }

通过使用 store* 匹配以 store 开头的任何表名称,可简化上面的策略。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "GetTablesExample2", "Effect": "Allow", "Action": [ "glue:GetTables" ], "Resource": [ "arn:aws:glue:us-west-2:123456789012:catalog", "arn:aws:glue:us-west-2:123456789012:database/db1", "arn:aws:glue:us-west-2:123456789012:table/db1/store*" ] } ] }

同样,使用 /db1/* 匹配 db1 中的所有表,以下策略将授予对 db1 中所有表的 GetTables 访问权限。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "GetTablesReturnAll", "Effect": "Allow", "Action": [ "glue:GetTables" ], "Resource": [ "arn:aws:glue:us-west-2:123456789012:catalog", "arn:aws:glue:us-west-2:123456789012:database/db1", "arn:aws:glue:us-west-2:123456789012:table/db1/*" ] } ] }

如果未提供表 ARN,调用 GetTables 将成功,但会返回空列表。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "GetTablesEmptyResults", "Effect": "Allow", "Action": [ "glue:GetTables" ], "Resource": [ "arn:aws:glue:us-west-2:123456789012:catalog", "arn:aws:glue:us-west-2:123456789012:database/db1" ] } ] }

如果策略中缺少数据库 ARN,则调用 GetTables 将失败,并出现 AccessDeniedException

{ "Version": "2012-10-17", "Statement": [ { "Sid": "GetTablesAccessDeny", "Effect": "Allow", "Action": [ "glue:GetTables" ], "Resource": [ "arn:aws:glue:us-west-2:123456789012:catalog", "arn:aws:glue:us-west-2:123456789012:table/db1/*" ] } ] }

授予对表和所有分区的完整访问权限

以下策略授予对数据库 db1 中名为 books 的表的所有权限。这包括对表本身、对其存档版本及其所有分区的读取和写入权限。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "FullAccessOnTable", "Effect": "Allow", "Action": [ "glue:CreateTable", "glue:GetTable", "glue:GetTables", "glue:UpdateTable", "glue:DeleteTable", "glue:BatchDeleteTable", "glue:GetTableVersion", "glue:GetTableVersions", "glue:DeleteTableVersion", "glue:BatchDeleteTableVersion", "glue:CreatePartition", "glue:BatchCreatePartition", "glue:GetPartition", "glue:GetPartitions", "glue:BatchGetPartition", "glue:UpdatePartition", "glue:DeletePartition", "glue:BatchDeletePartition" ], "Resource": [ "arn:aws:glue:us-west-2:123456789012:catalog", "arn:aws:glue:us-west-2:123456789012:database/db1", "arn:aws:glue:us-west-2:123456789012:table/db1/books" ] } ] }

在实践中,可以简化上述策略。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "FullAccessOnTable", "Effect": "Allow", "Action": [ "glue:*Table*", "glue:*Partition*" ], "Resource": [ "arn:aws:glue:us-west-2:123456789012:catalog", "arn:aws:glue:us-west-2:123456789012:database/db1", "arn:aws:glue:us-west-2:123456789012:table/db1/books" ] } ] }

请注意,精细访问控制的最小粒度在表级别。这意味着,您不能向用户授予对表中某些分区的访问权限,而不授予对表中其他分区的访问权限,或授予对表中部分列的访问权限,而不授予对其他列的访问权限。用户要么可以访问表的所有内容,要么不能访问表的任何内容。

通过名称前缀和显式拒绝控制访问权限

在本示例中,假设您的 Amazon Glue 数据目录中的数据库和表使用名称前缀来组织。发展阶段的数据库具有名称前缀 dev-,生产阶段的数据库具有名称前缀 prod-。您可以使用以下策略向开发人员授予对具有 dev- 前缀的所有数据库、表、UDF 等的完整访问权限。但是,您会对带有 prod- 前缀的所有内容授予只读访问权限。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "DevAndProdFullAccess", "Effect": "Allow", "Action": [ "glue:*Database*", "glue:*Table*", "glue:*Partition*", "glue:*UserDefinedFunction*", "glue:*Connection*" ], "Resource": [ "arn:aws:glue:us-west-2:123456789012:catalog", "arn:aws:glue:us-west-2:123456789012:database/dev-*", "arn:aws:glue:us-west-2:123456789012:database/prod-*", "arn:aws:glue:us-west-2:123456789012:table/dev-*/*", "arn:aws:glue:us-west-2:123456789012:table/*/dev-*", "arn:aws:glue:us-west-2:123456789012:table/prod-*/*", "arn:aws:glue:us-west-2:123456789012:table/*/prod-*", "arn:aws:glue:us-west-2:123456789012:userDefinedFunction/dev-*/*", "arn:aws:glue:us-west-2:123456789012:userDefinedFunction/*/dev-*", "arn:aws:glue:us-west-2:123456789012:userDefinedFunction/prod-*/*", "arn:aws:glue:us-west-2:123456789012:userDefinedFunction/*/prod-*", "arn:aws:glue:us-west-2:123456789012:connection/dev-*", "arn:aws:glue:us-west-2:123456789012:connection/prod-*" ] }, { "Sid": "ProdWriteDeny", "Effect": "Deny", "Action": [ "glue:*Create*", "glue:*Update*", "glue:*Delete*" ], "Resource": [ "arn:aws:glue:us-west-2:123456789012:database/prod-*", "arn:aws:glue:us-west-2:123456789012:table/prod-*/*", "arn:aws:glue:us-west-2:123456789012:table/*/prod-*", "arn:aws:glue:us-west-2:123456789012:userDefinedFunction/prod-*/*", "arn:aws:glue:us-west-2:123456789012:userDefinedFunction/*/prod-*", "arn:aws:glue:us-west-2:123456789012:connection/prod-*" ] } ] }

上述策略中的第二条语句使用显式 deny。您可以使用显式 deny 覆盖被授予委托人的任何 allow 权限。这样,您就可以锁定关键资源的访问权限,并阻止其他策略意外授予这些资源的访问权限。

在上述示例中,尽管第一条语句授予对 prod- 资源的完整访问权限,第二条语句则显式撤消这些资源的写入访问权限,只保留 prod- 资源的读取访问权限。

使用标签授权

例如,假设您想将对触发器 t2 的访问限制为您账户中名为 Tom 的特定用户。所有其他用户(包括 Sam)都有权访问触发器 t1。触发器 t1t2 具有以下属性。

aws glue get-triggers { "Triggers": [ { "State": "CREATED", "Type": "SCHEDULED", "Name": "t1", "Actions": [ { "JobName": "j1" } ], "Schedule": "cron(0 0/1 * * ? *)" }, { "State": "CREATED", "Type": "SCHEDULED", "Name": "t2", "Actions": [ { "JobName": "j1" } ], "Schedule": "cron(0 0/1 * * ? *)" } ] }

Amazon Glue 管理员已将标签值 Tom (aws:ResourceTag/Name": "Tom") 附加到触发器 t2。Amazon Glue 管理员还为 Tom 提供了一个 IAM policy,其中包含基于标签的条件语句。因此,Tom 只能使用对带标签值 Tom 的资源有效的 Amazon Glue 操作。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "glue:*", "Resource": "*", "Condition": { "StringEquals": { "aws:ResourceTag/Name": "Tom" } } } ] }

当 Tom 尝试访问触发器 t1 时,他收到一条指示访问被拒绝的消息。同时,他可以成功检索触发器 t2

aws glue get-trigger --name t1 An error occurred (AccessDeniedException) when calling the GetTrigger operation: User: Tom is not authorized to perform: glue:GetTrigger on resource: arn:aws:glue:us-east-1:123456789012:trigger/t1 aws glue get-trigger --name t2 { "Trigger": { "State": "CREATED", "Type": "SCHEDULED", "Name": "t2", "Actions": [ { "JobName": "j1" } ], "Schedule": "cron(0 0/1 * * ? *)" } }

Tom 无法使用复数 GetTriggers API 操作列出触发器,因为此操作不支持对标签进行筛选。

为了向 Tom 提供对 GetTriggers 的访问权限,Amazon Glue 管理员创建了一个将权限拆分为两部分的策略。一个部分允许 Tom 使用 GetTriggers API 操作访问所有触发器。另一个部分允许 Tom 访问使用值 Tom 标记的 API 操作。利用此策略,Tom 可以使用 GetTriggersGetTrigger 来访问触发器 t2

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "glue:GetTriggers", "Resource": "*" }, { "Effect": "Allow", "Action": "glue:*", "Resource": "*", "Condition": { "StringEquals": { "aws:ResourceTag/Name": "Tom" } } } ] }

使用标签拒绝访问

另一种资源策略方法是明确拒绝对资源的访问。

重要

显式拒绝策略不适用于复数 API 操作(如 GetTriggers)。

在以下示例策略中,允许所有 Amazon Glue 任务操作。但是,第二条 Effect 语句明确拒绝访问带有 Team 键和 Special 值标记的任务。

当管理员将以下策略附加到身份时,该身份可以访问标记为 Team 键和 Special 值之外的所有任务。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "glue:*", "Resource": "arn:aws:glue:us-east-1:123456789012:job/*" }, { "Effect": "Deny", "Action": "glue:*", "Resource": "arn:aws:glue:us-east-1:123456789012:job/*", "Condition": { "StringEquals": { "aws:ResourceTag/Team": "Special" } } } ] }

将标签与 List 和 Batch API 操作结合使用

编写资源策略的第三种方法是允许使用 List API 操作访问资源以列出标签值的资源。然后,使用相应的 Batch API 操作以允许访问特定资源的详细信息。利用此方法,管理员无需允许访问复数 GetCrawlersGetDevEndpointsGetJobsGetTriggers API 操作。相反,您可以允许使用以下 API 操作列出资源:

  • ListCrawlers

  • ListDevEndpoints

  • ListJobs

  • ListTriggers

此外,您可以允许使用以下 API 操作获取有关各个资源的详细信息:

  • BatchGetCrawlers

  • BatchGetDevEndpoints

  • BatchGetJobs

  • BatchGetTriggers

作为管理员,要使用此方法,您可以执行以下操作:

  1. 将标签添加到您的爬网程序、开发终端节点、作业和触发器。

  2. 拒绝用户对 Get API 操作(例如 GetCrawlersGetDevEndpontsGetJobsGetTriggers)的访问。

  3. 要使用户能够查明他们有权访问的标记资源,请允许用户访问 List API 操作,例如 ListCrawlersListDevEndpontsListJobsListTriggers

  4. 拒绝用户对 Amazon Glue 标记 API(例如 TagResourceUntagResource)的访问。

  5. 允许用户使用 BatchGet API 操作(例如 BatchGetCrawlersBatchGetDevEndpontsBatchGetJobsBatchGetTriggers)访问资源详细信息。

例如,在调用 ListCrawlers 操作时,请提供标签值以匹配用户名。然后,结果是与提供的标签值匹配的爬网程序的列表。向 BatchGetCrawlers 提供名称列表以获取有关每个带给定标签的爬网程序的详细信息。

例如,如果 Tom 应只能检索标记了 Tom 的触发器的详细信息,管理员可将标签添加到 Tom 的触发器,拒绝所有用户对 GetTriggers API 操作的访问,并允许所有用户访问 ListTriggersBatchGetTriggers

以下是 Amazon Glue 管理员向 Tom 授予的资源策略。在此策略的第一个部分中,GetTriggers 拒绝 Amazon Glue API 操作。在此策略的第二个部分中,所有资源允许 ListTriggers。但在第三个部分中,允许使用 BatchGetTriggers 访问标记了 Tom 的那些资源。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "glue:GetTriggers", "Resource": "*" }, { "Effect": "Allow", "Action": [ "glue:ListTriggers" ], "Resource": [ "*" ] }, { "Effect": "Allow", "Action": [ "glue:BatchGetTriggers" ], "Resource": [ "*" ], "Condition": { "StringEquals": { "aws:ResourceTag/Name": "Tom" } } } ] }

通过使用上一个示例中的相同触发器,Tom 可以访问触发器 t2 而不是触发器 t1。以下示例显示了 Tom 尝试使用 BatchGetTriggers 访问 t1t2 时的结果。

aws glue batch-get-triggers --trigger-names t2 { "Triggers": { "State": "CREATED", "Type": "SCHEDULED", "Name": "t2", "Actions": [ { "JobName": "j2" } ], "Schedule": "cron(0 0/1 * * ? *)" } } aws glue batch-get-triggers --trigger-names t1 An error occurred (AccessDeniedException) when calling the BatchGetTriggers operation: No access to any requested resource.

以下示例显示了 Tom 尝试通过同一 BatchGetTriggers 调用访问触发器 t2 和触发器 t3(不存在)时的结果。请注意,由于 Tom 有权访问触发器 t2 且该触发器存在,因此,仅返回 t2。虽然 Tom 有权访问触发器 t3,但触发器 t3 不存在,因此在 "TriggersNotFound": [] 列表的响应中将返回 t3

aws glue batch-get-triggers --trigger-names t2 t3 { "Triggers": { "State": "CREATED", "Type": "SCHEDULED", "Name": "t2", "Actions": [ { "JobName": "j2" } ], "TriggersNotFound": ["t3"], "Schedule": "cron(0 0/1 * * ? *)" } }

使用条件键或上下文键控制设置

授予创建和更新任务的权限时,可以使用条件键或上下文键。以下部分讨论了这些键:

使用条件键控制设置的策略

Amazon Glue 提供了三个 IAM 条件键,分别是 glue:VpcIdsglue:SubnetIdsglue:SecurityGroupIds。授予创建和更新任务的权限时,可以使用 IAM policy 中的条件键。您可以使用此设置确保创建(或更新)的作业或会话不会在所需 VPC 环境之外运行。VPC 设置信息不是 CreateJob 请求中的直接输入,而是从指向 Amazon Glue 连接的任务“连接”字段推断得出。

示例用法

使用所需的 VpcId "vpc-id1234"、SubnetIds 和 SecurityGroupIds 创建名为 "traffic-monitored-connection"(流量监控连接)的 Amazon Glue 网络类型连接。

为 IAM policy 中的 CreateJobUpdateJob 操作指定条件键条件。

{ "Effect": "Allow", "Action": [ "glue:CreateJob", "glue:UpdateJob" ], "Resource": [ "*" ], "Condition": { "ForAnyValue:StringLike": { "glue:VpcIds": [ "vpc-id1234" ] } } }

您可以创建类似的 IAM policy,以禁止在不指定连接信息的情况下创建 Amazon Glue 任务。

限制 VPC 上的会话

要强制创建的会话在指定的 VPC 内运行,您可以通过对 glue:CreateSession 操作添加 Deny 效果来限制角色权限,条件是 glue:vpc-id 不等于 vpc-<123>。例如:

"Effect": "Deny", "Action": [ "glue:CreateSession" ], "Condition": { "StringNotEquals" : {"glue:VpcIds" : ["vpc-123"]} }

您还可以将创建的会话强制在 VPC 内运行,方法是为 Deny 是空的 glue:CreateSession 操作添加 glue:vpc-id 效果。例如:

{ "Effect": "Deny", "Action": [ "glue:CreateSession" ], "Condition": { "Null": {"glue:VpcIds": true} } }, { "Effect": "Allow", "Action": [ "glue:CreateSession" ], "Resource": ["*"] }

控制使用上下文键控制设置的策略

Amazon Glue 为 Amazon Glue 提供给任务和开发人员端点的每个角色会话提供了上下文键 (glue:CredentialIssuingService= glue.amazonaws.com)。这允许您对 Amazon Glue 脚本执行的操作实施安全控制。Amazon Glue 还为每个角色会话提供了另一个上下文键(glue:RoleAssumedBy=glue.amazonaws.com),其中 Amazon Glue 会代表客户调用另一个 Amazon 服务(不是通过任务/开发端点,而是直接通过 Amazon Glue 服务)。

示例用法

在 IAM policy 中指定条件权限,并将其附上 Amazon Glue 任务要使用的角色。这确保了可以基于角色会话是否用于 Amazon Glue 任务运行时环境而允许/拒绝某些操作。

{ "Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::confidential-bucket/*", "Condition": { "StringEquals": { "glue:CredentialIssuingService": "glue.amazonaws.com" } } }

拒绝某个身份创建数据预览会话

该部分包含一个 IAM policy 示例,用于拒绝某个身份创建数据预览会话。将此策略附加到身份,该身份与数据预览会话在运行期间使用的角色是分开的。

{ "Sid": "DatapreviewDeny", "Effect": "Deny", "Action": [ "glue:CreateSession" ], "Resource": [ "arn:aws:glue:*:*:session/glue-studio-datapreview*" ] }