如何在 AWS S3 存储桶中自动化访问权限编排

多年前，当带有大型文件系统的本地 Unix 服务器流行时，公司正在构建广泛的文件夹管理规则和策略，以管理不同人员对不同文件夹的访问权限。

通常，一个组织的平台服务于具有完全不同的兴趣、机密级别限制或内容定义的不同用户组。 对于全球组织，这甚至可能意味着根据位置分离内容，基本上是在属于不同国家的用户之间分离内容。

其他典型示例可能包括：

• 开发、测试和生产环境之间的数据分离
• 销售内容无法为广大受众所访问
• 无法从其他地区看到或访问的特定国家/地区的立法内容
• 与项目相关的内容，其中“领导力数据”仅提供给有限的人群等。

这样的例子可能有无穷无尽的清单。 关键是总是需要在平台提供访问权限的所有用户之间协调对文件和数据的访问权限。

对于本地解决方案，这是一项例行任务。 文件系统的管理员只是设置了一些规则，使用了一个选择的工具，然后人们被映射到用户组，用户组被映射到他们应该能够访问的文件夹列表或挂载点。 在此过程中，访问级别被定义为只读或读写访问。

现在看看 AWS 云平台，很明显期望人们对内容访问限制有类似的要求。 但是现在，这个问题的解决方案必须有所不同。 文件不再存在于 Unix 服务器上，而是存在于云中（不仅整个组织甚至整个世界都可能访问），并且内容不再存储在文件夹中，而是存储在 S3 存储桶中。

下面描述的是解决此问题的替代方法。 它建立在我为具体项目设计此类解决方案时的真实经验之上。

简单但非常手动的方法

在没有任何自动化的情况下解决此问题的一种方法相对简单明了：

• 为每个不同的人群创建一个新桶。
• 分配对存储桶的访问权限，以便只有该特定组才能访问 S3 存储桶。

如果要求采用非常简单和快速的解决方案，这当然是可能的。 但是，需要注意一些限制。

默认情况下，一个 AWS 账户下最多只能创建 100 个 S3 存储桶。 通过向 AWS 票证提交服务限制增加，可以将此限制扩展到 1000。 如果这些限制不是您的特定实施案例所担心的，那么您可以让每个不同的域用户在单独的 S3 存储桶上操作，然后收工。

如果某些人具有跨职能职责，或者只是某些人需要同时访问更多域的内容，则可能会出现问题。 例如：

• 数据分析师评估几个不同领域、地区等的数据内容。
• 测试团队共享服务于不同开发团队的服务。
• 报告用户需要在同一区域内的不同国家之上建立仪表板分析。

正如您可能想象的那样，这个列表可以再次像您想象的那样增长，并且组织的需求可以产生各种用例。

此列表变得越复杂，将需要更复杂的访问权限编排来授予所有这些不同的组对组织中不同 S3 存储桶的不同访问权限。 将需要额外的工具，甚至可能需要专门的资源（管理员）来维护访问权限列表并在任何更改请求时更新它们（这将非常频繁，特别是如果组织很大）。

那么，如何以更有条理和自动化的方式实现同​​样的事情呢？

为桶引入标签

如果每个域的存储桶方法不起作用，任何其他解决方案最终都会为更多用户组共享存储桶。 在这种情况下，有必要在某些易于动态更改或更新的区域构建分配访问权限的整个逻辑。

实现这一目标的方法之一是在 S3 存储桶上使用标签。 建议在任何情况下都使用这些标签（如果只是为了更轻松地进行计费分类）。 但是，将来可以随时更改任何存储桶的标签。

如果整个逻辑是基于桶标签构建的，而后面的其余部分是依赖于标签值的配置，那么动态属性是有保证的，因为只需更新标签值就可以重新定义桶的用途。

使用什么样的标签来完成这项工作？

这取决于您的具体用例。 例如：

• 可能需要将每个环境类型的存储桶分开。 因此，在这种情况下，其中一个标签名称应类似于“ENV”，并可能具有“DEV”、“TEST”、“PROD”等值。
• 也许您想根据国家/地区将团队分开。 在这种情况下，另一个标签将是“COUNTRY”并为某个国家/地区名称赋值。
• 或者您可能希望根据用户所属的职能部门将用户分开，例如业务分析师、数据仓库用户、数据科学家等。因此您创建一个名为“USER_TYPE”和相应值的标签。
• 另一种选择可能是您希望为他们需要使用的特定用户组明确定义一个固定的文件夹结构（以免创建他们自己的文件夹混乱并随着时间的推移迷失在那里）。 您可以使用标签再次执行此操作，您可以在其中指定几个工作目录，例如：“data/import”、“data/processed”、“data/error”等。

理想情况下，您希望定义标签，以便它们可以逻辑组合并使它们在存储桶上形成一个完整的文件夹结构。

例如，您可以组合上述示例中的以下标签，为来自不同国家/地区的不同类型的用户构建专用文件夹结构，并预定义他们将使用的导入文件夹：

• /<ENV>/<USER_TYPE>/<COUNTRY>/<UPLOAD>

只需更改<ENV>值，即可重新定义标签的用途（是否分配给测试环境ecosystem、dev、prod等）

这将使许多不同的用户能够使用同一个桶。 存储桶不明确支持文件夹，但它们支持“标签”。 这些标签最终像子文件夹一样工作，因为用户需要通过一系列标签才能访问他们的数据（就像他们对子文件夹所做的那样）。

创建动态策略并在内部映射存储桶标签

以某种可用形式定义标签后，下一步是构建将使用标签的 S3 存储桶策略。

如果策略使用标签名称，则您正在创建称为“动态策略”的东西。 这基本上意味着您的策略对于具有策略在表单或占位符中引用的不同标签值的存储桶会有不同的行为。

此步骤显然涉及动态策略的一些自定义编码，但您可以使用 Amazon AWS 策略编辑器工具简化此步骤，它将指导您完成整个过程。

在策略本身中，您需要编写应用于存储桶的具体访问权限以及此类权限的访问级别（读、写）。 该逻辑将读取存储桶上的标签并将在存储桶上构建文件夹结构（根据标签创建标签）。 根据标签的具体值，将创建子文件夹，并沿线分配所需的访问权限。

这种动态策略的好处是您可以只创建一个动态策略，然后将完全相同的动态策略分配给许多存储桶。 对于具有不同标签值的存储桶，此策略的行为会有所不同，但它始终符合您对具有此类标签值的存储桶的期望。

这是一种以有组织、集中的方式为大量存储桶管理访问权限分配的真正有效方法，其中期望每个存储桶都遵循一些预先商定的模板结构，并将由您的用户在其中使用整个组织。

自动化新实体的入职

在定义动态策略并将它们分配给现有存储桶后，用户可以开始使用相同的存储桶，而不会出现来自不同组的用户无法访问位于他们没有的文件夹结构下的内容（存储在同一存储桶中）的风险使用权。

此外，对于一些具有更广泛访问权限的用户组，很容易接触到数据，因为它们都存储在同一个存储桶中。

最后一步是让新用户、新桶甚至新标签的入职尽可能简单。 这导致了另一种自定义编码，但是，它不需要过于复杂，假设您的入职流程有一些非常明确的规则，可以用简单、直接的算法逻辑封装（至少您可以通过这种方式证明您的过程有一定的逻辑，并且不是以过于混乱的方式完成的）。

这可以像通过 AWS CLI 命令创建可执行脚本一样简单，其中包含成功将新实体载入平台所需的参数。 它甚至可以是一系列 CLI 脚本，可以按特定顺序执行，例如：

• create_new_bucket(<ENV>,<ENV_VALUE>,<COUNTRY>,<COUNTRY_VALUE>, ..)
• create_new_tag(<bucket_id>,<tag_name>,<tag_value>)
• update_existing_tag(<bucket_id>,<tag_name>,<tag_value>)
• create_user_group(<user_type>,<country>,<env>)
• 等等

你明白了。

专业提示

如果您愿意，可以使用一个 Pro Tip，它可以很容易地应用在上面的上面。

动态策略不仅可以用于分配文件夹位置的访问权限，还可以自动分配存储桶和用户组的服务权限！

所需要做的就是扩展存储桶上的标签列表，然后添加动态策略访问权限，以便为具体的用户组使用特定的服务。

例如，可能有一些用户组也需要访问特定的数据库集群服务器。 这无疑可以通过利用存储桶任务的动态策略来实现，如果对服务的访问是由基于角色的方法驱动的，则更是如此。 只需向动态策略代码添加一个部分，该部分将处理有关数据库集群规范的标签，并将策略访问权限直接分配给特定的数据库集群和用户组。

这样，新用户组的入职将仅通过此单一动态策略执行。 此外，由于它是动态的，因此可以重复使用相同的策略来引导许多不同的用户组（期望遵循相同的模板但不一定是相同的服务）。

您还可以查看这些 AWS S3 命令来管理存储桶和数据。