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

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

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

更常见的例子可能包括：

• 开发、测试和生产环境之间的数据分离
• 销售内容不可供广大观众访问
• 不同国家立法内容不能在其他地区内看到或访问
• 项目相关内容，其中“领导数据”仅提供给有限的人群等

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

在本地解决方案的情况下，这是一项例行任务。文件系统的管理员只需设置一些规则，使用所选择的工具，然后将人员映射到用户组，用户组映射到可访问的文件夹或挂载点的列表中。在此过程中，访问级别被定义为只读或读写访问。

现在来看看链接_1的平台，很明显可以期望人们对内容访问限制有类似的要求。然而，解决这个问题的解决方案现在必须是不同的。文件不再在Unix服务器上，而是在云中（可能不仅对整个组织可见，甚至对整个世界可见），内容也不再存储在文件夹中，而是存在链接_2中。

下面描述了一个解决此问题的替代方法。它建立在我为一个具体项目设计这样的解决方案时的实际经验之上。

简单但非常手动的方法

一种解决此问题的方法是没有任何自动化，相对简单和简单：

• 为每个不同的人群创建一个新的存储桶。
• 分配存储桶的访问权限，以便只有这个特定的群体可以访问S3存储桶。

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

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

如果有一些具有跨职能职责的人群或仅需要同时访问多个域的内容的人群，可能会出现问题。例如：

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

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

随着这个列表变得越来越复杂，组织中将需要更复杂的访问权限编排来授予这些不同组织不同S3存储桶的不同访问权限。可能需要额外的工具，甚至可能需要一个专门的资源（管理员）来维护访问权限列表，并在请求任何更改时进行更新（尤其是如果组织规模很大的情况下，更改将非常频繁）。

那么，如何以更有组织和自动化的方式实现相同的目标呢？

引入存储桶标签

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

其中一种实现这一目标的方法是使用S3存储桶上的标签。建议在任何情况下都使用标签（即使仅用于更容易的计费分类）。然而，标签可以随时在将来更改为任何存储桶。

如果整个逻辑都基于存储桶标签构建，并且其后面的部分依赖于标签值的配置，那么动态属性就得到了保证，因为可以通过更新标签值重新定义存储桶的用途。

使用什么类型的标签来使其工作？

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

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

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

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

• ////

通过更改值，您可以重新定义标签的用途（将其分配给测试环境生态系统、开发环境、生产环境等）

这将使同一个存储桶可以供多个不同的用户使用。存储桶不显式支持文件夹，但它们支持“标签”。这些标签最终起到子文件夹的作用，因为用户需要通过一系列标签来访问其数据（就像使用子文件夹一样）。

创建动态策略并在其中映射存储桶标签

在某种可用的形式中定义了标签后，下一步是构建使用这些标签的S3存储桶策略。

如果策略使用了标签名称，您正在创建一种称为“动态策略”的东西。这基本上意味着策略将根据策略中引用的与标签值不同的存储桶的不同行为。

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

在政策本身中，您将希望对存储桶应用具体的访问权限，并确定这些权限的访问级别（读、写）。逻辑将读取存储桶上的标签，并在存储桶上构建文件夹结构（根据标签创建标签）。根据标签的具体值，将创建子文件夹，并沿线分配所需的访问权限。

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

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

自动化新实体的入职

在定义了动态策略并将其分配给现有存储桶之后，用户可以开始使用相同的存储桶，而不必担心来自不同组的用户无法访问位于无法访问的文件夹结构下的内容（存储在同一个存储桶中）。

对于一些具有更广泛访问权限的用户组，访问数据将变得更加容易，因为所有数据都存储在同一个存储桶中。

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

这可以非常简单，只需创建一个可以通过命令行参数成功入职新实体到平台的脚本。它甚至可以是一系列的CLI脚本，按特定顺序执行，例如：

• create_new_bucket(,,,, ..)
• create_new_tag(,,)
• update_existing_tag(,,)
• create_user_group(,,)
• etc.

你明白了。 😃

专业提示 👨‍💻

如果你愿意，这里有一个专业提示，可以很容易地应用在上述的基础上。

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

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

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

这样，只需一个动态策略就可以执行新用户组的入职。而且，由于它是动态的，同样的策略可以重复用于入职许多不同的用户组（预计遵循相同模板但不一定使用相同服务）。

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