克服 S3 中的 1000 个存储桶限制/使用接入点答案

【问题标题】：Overcome 1000 bucket limit in S3 / use access points克服 S3 中的 1000 个存储桶限制/使用接入点
【发布时间】：2020-01-21 02:19:07
【问题描述】：

每个客户我有 1 个 s3 存储桶。客户是外部实体，他们不与其他任何人共享数据。我写入 S3，客户从 S3 读取。根据这个架构，我只能扩展到 1000 个存储桶，因为每个账户有 s3 存储桶的限制。我希望使用 AP 为每个客户创建 1 个 AP 并将数据放入一个存储桶中。然后客户可以使用 AP 从存储桶中读取文件。

Bucket000001/prefix01 . -> customeraccount1

Bucket000001/prefix02 . -> customeraccount2 ...

S3 访问点要求您在访问点和存储桶级别为 IAM 用户设置策略。如果我有 1000 多个 IAM 用户，我是否需要为存储桶中的每个用户设置策略？这将导致一项巨大的政策。存储桶中有最大策略大小，所以我可能无法做到这一点。这是接入点可以提供帮助的正确用例吗？

【问题讨论】：

什么样的用户？
请编辑您的问题，告诉我们更多关于您的实际目标的信息。 “S3 接入点”不太可能是满足您要求的合适解决方案，但在建议最佳方法之前，我们需要了解更多信息。首先，请让我们知道您所说的“用户”是什么意思——他们是 IAM 用户还是应用程序用户？当您说“共享存储桶”时，您真的是指“提供对存储桶内子目录的访问权限”吗？您能否为我们提供一个用户实际使用存储桶的示例？
@JohnRotenstein 希望编辑回答您的问题
@TuanVA User 是可以从 S3 读取数据的客户账户。

标签： amazon-web-services amazon-s3

【解决方案1】：

推荐的方法是：

请勿将 IAM 用户分配给您的客户。这些类型的 AWS 凭证只能由您的内部员工和您自己的应用程序使用。
您应该提供一个 Web 应用程序（或 API），客户可以在其中针对您自己的用户数据库进行身份验证（或者您可以使用 Amazon Cognito 来管理身份验证）。
通过身份验证后，应用程序应授予对 Web 界面以访问 Amazon S3 的访问权限，或者应用程序应提供临时凭证以访问 Amazon S3（更多详细信息见下文)。
不要为每个客户使用一个存储桶。这是不可扩展的。相反，将所有客户数据存储在一个存储桶中，每个用户都有自己的文件夹。您可以在 Amazon S3 中存储的数据量没有限制。这也使您更容易管理和维护，因为更容易跨所有内容执行功能，而不必进入单独的存储桶。（如果您希望按客户位置（地区）或客户类型对存储桶进行细分，则可能是一个例外。但不要为每位客户使用一个存储桶。没有理由这样做。）
授予对 Amazon S3 的访问权限时，在文件夹级别分配权限以确保客户只能看到自己的数据。

选项 1：通过 Web 应用程序访问

如果您的客户通过 Web 应用程序访问 Amazon S3，那么您可以对该应用程序进行编码以在文件夹级别强制实施安全性。例如，当他们请求文件列表时，仅显示其文件夹中的文件。

这种安全性可以完全在您自己的代码中进行管理。

选项 2：通过临时凭据访问

如果您的客户使用编程访问（例如使用 AWS CLI 或在其系统上运行的自定义应用程序），那么：

客户应对您的应用程序进行身份验证（如何完成此操作将因您对用户进行身份验证的方式而异）
通过身份验证后，应用程序应使用AWS Security Token Service (STS) 生成临时凭据。在生成凭证时，授予对 Amazon S3 的访问权限，但在 ARN 中指定客户的文件夹（例如 arn:aws:s3:::storage-bucket/customer1/*），以便他们只能访问他们的文件夹中的内容。
将这些临时凭证返回给客户。然后，他们可以使用这些凭证直接对 Amazon S3 进行 API 调用（例如，从 AWS Command-Line Interface (CLI) 或自定义应用程序）。它们将被限制在自己的文件夹中。

这种方法通常用于移动应用程序。移动应用程序针对后端进行身份验证，接收临时凭证，然后使用这些凭证直接与 S3 交互。因此，后端应用程序仅用于身份验证。

YouTube 上的示例：

【讨论】：

在使用 STS 时需要授予/撤销客户访问权限时，是否需要触摸存储桶策略？
没有。存储桶策略通常仅在授予公共访问权限或基于某些条件（例如 IP 地址）的访问权限时使用。在上述场景中，可以在应用通过 STS 或 Cognito 创建临时凭证时指定权限。您应该没有理由使用存储桶策略。
"不要为每个客户使用一个存储桶。这是不可扩展的。相反，将所有客户数据存储在一个存储桶中，每个用户都有自己的文件夹。您的数据量没有限制可以存储在 Amazon S3 中。”我见过很多人为此绊倒（包括我自己）。我仍然无法真正找到“为什么”AWS 选择了这个限制？如果我们可以在 S3 中拥有无限数据，为什么不能无限存储桶呢？令人担忧的是，底层基础设施可能无法处理它。即使对于客户来说，他们的数据与竞争对手共享存储桶的观点也不理想。
我还认为使用 IAM 用户像 OP 一样直观。特别是在创建它们时，您可以创建编程访问密钥。我只是偶然发现了 doco 中的 5000 IAM 用户限制。我再一次找不到为什么会做出这个限制？我们的每台服务器都有自己的永久密钥来使用 AWS api。 IAM 用户在构建时被放入具有用户名限制 ARN 的用户组。如果没有 5000 个限制，IAM 用户可以完美地做到这一点。
我读到“我应该只使用 cognito”（不知道为什么除了 5000 IAM 用户限制之外），但花了三天时间试图获得相同的结果，但最终不得不放弃。在论坛上阅读类似的挫败感 (reddit.com/r/aws/comments/m77p5g/…)。似乎更适合通过 OAuth/Google 进行身份验证的人类用户，而不是服务器。令人费解。

【解决方案2】：

我们有办法实现您的目标。

使用 IAM 组授予对文件夹的访问权限。创建组，将用户添加到组，并为组分配角色以访问文件夹。
另一种方法是使用存储桶策略（条件中的${aws:username}）授予对用户特定文件夹的访问权限。参考这个链接https://aws.amazon.com/blogs/security/writing-iam-policies-grant-access-to-user-specific-folders-in-an-amazon-s3-bucket/

【讨论】：