AWS Identity and Access Management
用户指南
AWS 文档中描述的 AWS 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 Amazon AWS 入门

AssumeRole、AssumeRoleWithSAML 和 AssumeRoleWithWebIdentity 的权限

所代入的角色的权限策略决定由 AssumeRoleAssumeRoleWithSAMLAssumeRoleWithWebIdentity 返回的临时安全凭证的权限。您可在创建或更新该角色时定义这些权限。

(可选) 可以选择将单独的策略作为 AssumeRoleAssumeRoleWithSAMLAssumeRoleWithWebIdentity API 调用的参数进行传递。您可以使用所传递的策略缩小分配给临时安全凭证的权限的范围,也就是说,只允许该角色权限策略所允许的权限的子集。您无法使用所传递的策略授予该角色权限策略不允许的权限;它只是一个筛选条件。如果不将策略作为 AssumeRoleAssumeRoleWithSAMLAssumeRoleWithWebIdentity API 调用的参数进行传递,则附加至临时安全凭证的权限与所代入的角色的角色权限策略中定义的权限相同。

使用由 AssumeRoleAssumeRoleWithSAMLAssumeRoleWithWebIdentity 返回的临时安全凭证发出 AWS 请求时,AWS 通过评估以下所有策略来决定是允许还是拒绝访问:

  • 如之前讨论的,代入的角色的角色权限策略和作为参数传递给 API 的策略的组合。

  • 附加至临时安全凭证正在访问的资源的任意基于资源的策略 (如 Amazon S3 存储桶策略)。

AWS 使用所有这些策略做出“允许”或“拒绝”授权的决定以遵循 IAM 策略评估逻辑

在做出“允许”或“拒绝”授权决定时,AWS 不会对附加至做出 AssumeRole 原始调用的 IAM 用户或凭证的策略进行评估,了解这一点非常重要。用户将临时放弃其原始权限,以支持代入的角色所分配的权限。对于 AssumeRoleWithSAMLAssumeRoleWithWebIdentity API,不会有任何策略受到评估,因为这些 API 的发起人不是 AWS 身份。

示例:使用 AssumeRole 分配权限

您可以将 AssumeRole API 操作与不同类型的策略结合使用。下面是几个示例。

角色权限策略

在本示例中,调用 AssumeRole API 时不包含可选的 Policy 参数。分配给由 AssumeRole 调用返回的临时安全凭证的权限 (即分配给代入角色的用户 的权限) 由所代入角色的权限策略决定。下面的示例是一条角色权限策略,它向代入角色的用户授予以下权限:列出名为 productionapp 的 S3 存储桶中包含的所有对象,并允许获取、上传和删除该存储桶中的对象。

例 角色权限策略

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:ListBucket", "Resource": "arn:aws-cn:s3:::productionapp" }, { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:DeleteObject" ], "Resource": "arn:aws-cn:s3:::productionapp/*" } ] }

作为参数传递的策略

假设您需要允许某用户代入上例中的角色,但希望代入角色的用户只具有获取和上传的权限,而不具有删除 productionapp S3 存储桶中对象的权限。达到这一目的的一种方式是创建一个新角色,并在该角色的权限策略中指定所需的权限。另一种途径是调用 AssumeRole API 并在该 API 调用中包含可选的 Policy 参数。例如,假设将以下策略作为该 API 调用的参数传递。担任角色的用户将只具备执行以下操作的权限:

  • 列出 productionapp 存储桶中的所有对象。

  • 获取 productionapp 存储桶中的对象或向其中上传对象。

请注意,以下策略中未指定 s3:DeleteObject 权限 (该权限已被筛选出),因此,代入角色的用户未获得 s3:DeleteObject 权限。将策略作为 AssumeRole API 调用的参数传递时,代入角色的用户的有效权限只包含该角色的权限策略所传递的策略中均已授予的权限。

例 通过 AssumeRole API 调用传递的策略

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:ListBucket", "Resource": "arn:aws-cn:s3:::productionapp" }, { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject" ], "Resource": "arn:aws-cn:s3:::productionapp/*" } ] }

基于资源的策略

某些 AWS 资源支持基于资源的策略,这些策略提供另一种机制用于定义影响临时安全凭证的权限。仅几种资源 (如 Amazon S3 存储桶、Amazon SNS 主题和 Amazon SQS 队列) 支持基于资源的策略。下面的示例是前例的扩展,其中使用了一个名为 productionapp 的 S3 存储桶。以下策略被附加到该存储桶。

将下面的策略附加至 productionapp 存储段后,所有 用户的删除该存储桶中对象的权限均会遭拒 (请留意该策略中的 Principal 元素)。这包括所有代入角色的用户 (即使角色权限策略授予了 DeleteObject 权限)。显式 Deny 声明总是优先于显式 Allow 声明。

例 存储桶策略

{ "Version": "2012-10-17", "Statement": { "Principal": {"AWS": "*"}, "Effect": "Deny", "Action": "s3:DeleteObject", "Resource": "arn:aws-cn:s3:::productionapp/*" } }

有关 AWS 如何对多个策略进行合并和评估的更多信息,请参阅IAM JSON 策略评估逻辑