Amazon S3 执行以下上下文评估 - 说明

Question

来自http://docs.aws.amazon.com/AmazonS3/latest/dev/access-control-auth-workflow-bucket-operation.html?shortFooter=true

有人可以澄清context evaluation：

示例 3：父 AWS 账户也是存储桶所有者的 IAM 用户请求的存储桶操作

在示例中，请求由 AWS 账户 1111-1111-1111 中的 IAM 用户 Jill 发送，该账户也拥有存储桶。

Amazon S3 执行以下上下文评估：

由于请求来自 IAM 用户，因此在用户上下文中，Amazon S3 会评估属于父 AWS 账户的所有策略，以确定 Jill 是否有权执行该操作。

在此示例中，用户所属的父 AWS 账户 1111-1111-1111 也是存储桶所有者。因此，除了用户策略之外，Amazon S3 还在同一上下文中评估存储桶策略和存储桶 ACL，因为它们属于同一个账户。

由于 Amazon S3 将存储桶策略和存储桶 ACL 评估为用户上下文的一部分，因此它不会评估存储桶上下文。

例如 - 在 IAM 用户创建存储桶的情况下会发生什么？

Answer 1

为了说明上下文的概念，考虑这个场景：

• 我的 AWS 账户拥有一个存储桶
• 您的 AWS 账户创建一个 IAM 用户
• 我们同意您的用户需要访问我帐户的存储桶

我们如何允许这样做？

我的帐户仅允许您的用户访问我的存储桶是不够的。

您的账户仅授权您的 IAM 用户访问我的存储桶也是不够的。

这两件事都必须被授予。

请求到达时，经过两层授权检查：

• 用户上下文：此用户的帐户是否允许他或她提出此请求？如果否，则拒绝访问；否则，下一步。
• 存储桶上下文：存储桶所有者帐户是否允许此用户提出此请求？如果否，则拒绝访问；否则，授予访问权限。

系统需要双方同意才能访问。

但是...在您引用的示例中，在评估用户上下文时需要学习所有内容，因为同一个帐户控制/拥有用户和存储桶。评估存储桶上下文是多余的，因此在这种情况下不会这样做。

“用户上下文”是用户帐户上下文，“桶上下文”是桶帐户上下文。

---

或者，也许您的问题实际上比这更简单。

如果 IAM 用户创建了 Bucket，会发生什么？

谁创建存储桶并不重要。存储桶归创建它的 AWS 账户所有，无论是根用户还是该账户的 IAM 用户。用户从不拥有存储桶，一旦创建了存储桶，哪个特定用户创建了存储桶就不再重要了。

创建资源的 AWS 账户拥有该资源。例如，如果您在 AWS 账户中创建 IAM 用户并授予该用户创建存储桶的权限，则该用户可以创建存储桶。但用户不拥有桶；用户所属的 AWS 账户拥有存储桶。用户将需要资源所有者的额外权限才能执行任何其他存储桶操作。

http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingBucket.html#create-bucket-intro