安全扩展 Pinterest 的大数据访问控制 (译文-来自:Pinterest)

背景

企业收集许多不同类型的数据。每个数据集都需要安全存储，并授予最少的访问权限，以确保它们得到适当使用，并且在必要时可以轻松找到和处置。随着业务的增长，这些数据集的种类及其处理要求的复杂性也在增加。因此，访问控制机制也需要不断扩展以应对不断增长的多样化。Pinterest 决定投资更新的技术框架来实施更细粒度的访问控制(FGAC) 框架。结果是一个多租户数据工程平台，允许用户和服务仅访问他们工作所需的数据。在这篇文章中，我们重点讨论如何增强和扩展Monarch，Pinterest的基于Hadoop的批处理系统，具有FGAC功能。

FGAC设计原则

Pinterest 在 S3 中存储了大量非瞬态数据。我们最初限制对 S3 中数据的访问的方法使用专用服务实例，其中不同的实例集群被授予对特定数据集的访问权限。当个人 Pinterest 数据用户需要访问特定数据时，他们被授予对每个集群的访问权限。我们从一个 Monarch 集群开始，其工作人员可以访问现有的 S3 数据。当我们构建需要不同访问控制的新数据集时，我们创建了新集群并授予它们对新数据集的访问权限。

Pinterest 数据工程团队为我们的数据用户提供了广泛的数据处理工具：Hive MetaStore、Trino、Spark、Flink、Querybook 和 Jupyter 等。每次创建新的受限数据集时，我们发现自己不仅需要创建新的 Monarch 集群，还需要在数据工程平台上创建新的集群，以确保 Pinterest 数据用户拥有处理这些新数据集所需的所有工具。创建如此大量的集群增加了硬件和维护成本，并且需要花费大量时间进行配置。跨多个集群的硬件碎片会降低整体资源利用效率，因为每个集群都配备了多余的资源来处理零星的使用激增，并且需要一组基本的支持服务。

在构建替代解决方案时，我们将重点从以主机为中心的系统转移到专注于每个用户的访问控制的系统。我们之前授予用户对 EC2 计算实例的访问权限，并通过分配的 IAM 角色授予这些实例对数据的访问权限，而我们试图直接授予不同用户对特定数据的访问权限，并使用其身份在一组通用服务集群上运行其作业。通过以单个用户身份执行作业和访问数据，我们可以狭窄地授予每个用户对不同数据资源的访问权限，而无需创建大型共享权限超集或分散集群。

我们首先考虑如何扩展 AWS 安全框架的初始实施来实现这一目标，但遇到了一些限制：

• 每个 AWS 账户的 IAM 角色数量限制小于需要访问数据的用户数量，并且最初 Pinterest 将其许多分析数据集中在少量账户中，因此为每个用户创建一个自定义角色是不可行的在 AWS 限制内。此外，以这种方式创建的大量 IAM 角色将难以管理。
• AssumeRole API 允许用户按需承担单个 IAM 角色的权限。但我们需要能够向用户授予许多不同的访问权限排列，这很快就会变得难以管理。例如，如果我们有三个离散数据集（A、B 和 C），每个数据集都在各自的存储桶中，则某些用户只需要访问 A，而其他用户则需要 A 和 B，等等。因此，我们需要涵盖A、A+B、A+B+C、A+C、B、B+C、C，但不授予每个用户对所有内容的访问权限。这需要构建和维护大量 IAM 角色以及一个让正确的用户在需要时担任正确角色的系统。

我们与 AWS 的技术联系人讨论了我们的项目，并集思广益，寻找授予 S3 中数据访问权限的替代方法。我们最终集中在两个选项上，均使用现有的 AWS 访问控制技术：

1. 通过 AssumeRole调用动态生成安全令牌服务 (STS)令牌：代理服务可以调用 API，提供会话托管策略列表，该策略可用于按需组装自定义的动态权限集
2. AWS 请求签名：代理服务可以授权客户端层发出的特定请求

我们选择使用动态生成的 STS 代币构建解决方案，因为我们知道这可以相对无缝地集成到大多数（如果不是全部）平台上。我们的方法允许我们通过与其他系统相同的预定义托管策略授予访问权限，并且可以通过替换现有的默认 AWS 凭证提供程序和 STS 令牌来插入我们拥有的每个系统。这些托管策略由各个数据集的保管人定义和维护，使我们能够通过委派将授权决策扩展到专家。作为我们架构的核心部分，我们创建了一个专用服务（凭证自动售货服务，或 CVS）来安全地执行 AssumeRole 调用，该调用可以将用户映射到权限和托管策略。我们的数据平台随后可以与 CVS 集成，以便通过 FGAC 相关功能来增强它们。我们将在下一节中提供有关 CVS 的更多详细信息。

凭证自动售卖服务

在开发以 CVS 为中心的新访问控制框架时，我们遵循以下设计原则：

• 访问控制必须被授予对用户或服务帐户的访问权限，而不是特定的集群实例，以确保在不需要额外硬件的情况下扩展访问控制。即席查询以运行查询的用户身份执行，计划的进程和服务在其自己的服务帐户下运行；一切都有一个我们可以验证和授权的身份。无论使用什么服务或实例，授权过程和结果都是相同的。
• 我们希望重新使用现有的轻量级目录访问协议 (LDAP) 作为安全、快速、分布式存储库，与我们所有现有的身份验证和授权系统集成。我们通过创建 LDAP 组来实现这一目标。我们添加 LDAP 用户帐户以将每个用户映射到一个或多个角色/权限。服务和计划的工作流分配有 LDAP 服务帐户，这些帐户添加到相同的 LDAP 组。
• 始终通过 S3 托管策略允许或拒绝对 S3 资源的访问。因此，我们通过 FGAC 授予的权限也可以授予不支持 FGAC 的系统，从而提供遗留和外部服务支持。它确保任何形式的 S3 数据访问都受到保护。

• 身份验证（以及用户身份）是通过令牌执行的。这些是在身份验证过程中创建的加密签名工件，用于跨服务器安全地传输用户或服务“主体”身份。令牌具有内置的到期日期。我们使用的代币类型包括

  ：访问令牌：

  — AWS STS，授予对 S3 等 AWS 服务的访问权限。

  二. 身份验证令牌：

  — OAuth 令牌用于网页或控制台中的人类用户身份验证。

  — Hadoop/Hive 委托令牌(DT) 用于在 Hadoop、Hive 和 Hadoop 分布式文件系统 (HDFS) 之间安全地传递用户身份。

图 1：凭证自动售卖服务的工作原理

图 1 演示了如何使用 CVS 处理两个不同的用户以授予对 S3 中不同数据集的访问权限。

1. 每个用户的身份都通过安全且可验证的机制（例如身份验证令牌）传递到 CVS
2. CVS 对发出请求的用户进行身份验证。支持多种身份验证协议，包括 mTLS、oAuth 和 Kerberos。
3. CVS 开始使用相同的基本 IAM 角色组装每个 STS 令牌。该 IAM 角色本身可以访问所有数据存储桶。但是，如果没有至少附加一个修改策略，则永远不会返回此 IAM 角色。

4. 获取用户的 LDAP 组。这些 LDAP 组将角色分配给用户。CVS 将这些角色映射到一个或多个 S3 托管策略，这些策略授予对不同 S3 端点上的特定操作（例如列出、读取、写入）的访问权限。

   A。用户 1 是两个 FGAC LDAP 组的成员

   ：LDAP 组 A 映射到 IAM 托管策略 1

   — 此策略授予对 s3://bucket-1 的访问权限

   。LDAP 组 B 映射到 IAM 托管策略 2 和 3

   — 策略 2 授予对 s3://bucket-2 的访问权限

   — 策略 3 授予对 s3://bucket-3 的访问

   权限 用户 2 是两个 FGAC LDAP 组的成员

   ：LDAP 组 A 映射到 IAM 托管策略 1（就像对第一个用户所做的那样）

   — 此策略授予对 s3://bucket-1 的访问权限

   。LDAP 组 C 映射到 IAM 托管策略 4

   — 此策略授予对 s3://bucket-4 的访问权限

5. 每个 STS 令牌只能访问附加到该令牌的托管策略中枚举的存储桶。

   A。令牌中的有效权限是基本角色中声明的权限与附加托管策略中枚举的权限的交集

   。我们避免在策略中使用 DENY。ALLOW 可以堆叠以向新存储桶添加权限。但单个 DENY 会覆盖对该 URI 的所有其他 ALLOW 访问堆栈。

如果提供的验证身份无效或者用户不是任何 FGAC 认可的 LDAP 组的成员，CVS 将返回错误响应。CVS 永远不会返回未附加托管策略的基本 IAM 角色，因此任何响应都无法访问所有 FGAC 控制的数据。

在下一节中，我们将详细介绍如何将 CVS 集成到 Hadoop 中，以便为我们的大数据平台提供 FGAC 功能。

Pinterest FGAC Hadoop 平台

图 2：原始 Pinterest Hadoop 平台

图 2 提供了 Pinterest 现有 Hadoop 架构 Monarch 的高级概述。正如之前的博客文章中所述，Monarch 由 30 多个Hadoop YARN集群组成，具有 17k 多个节点，完全构建在AWS EC2之上。Monarch 是处理繁重的交互式查询和离线、预先安排的批处理作业的主要引擎，因此是 Pinterest 数据基础设施的关键部分，每天处理 PB 级和数十万个作业。它与许多其他系统协同工作来处理这些作业和查询。简而言之，职位通过以下两种方式之一进入 Monarch：

• 即席查询通过QueryBook提交，QueryBook 是 Pinterest 开发的一种基于 GUI 的协作开源大数据管理工具。QueryBook 使用 OAuth 来验证用户身份。然后，它将查询传递给 Apache Livy，后者实际上负责创建 SparkSQL 作业并将其提交到目标 Hadoop 集群。Livy 跟踪提交的作业，将其状态和控制台输出传递回 QueryBook。
• 批处理作业通过 Pinterest基于 Airflow 的作业调度系统提交。工作流程在代码存储库签入过程中接受一组强制性审查，以确保正确的访问级别。一旦作业由 Spinner 管理，它就会使用作业提交服务来处理 Hadoop 作业提交和状态检查逻辑。

在这两种情况下，提交的 SparkSQL 作业与 Hive Metastore 一起启动 Hadoop Spark 应用程序，该应用程序确定并实施每个作业的查询计划。一旦运行，所有 Hadoop 作业（Spark/Scala、PySpark、SparkSQL、MapReduce）都会通过Hadoop 文件系统 API 的S3A 实现来读取和写入 S3 数据。

CVS 构成了我们通过 FGAC 功能扩展 Monarch 的方法的基石。由于 CVS 处理用户和服务帐户到数据权限的映射以及访问令牌的实际出售，我们在组装最终系统时面临以下主要挑战：

• 身份验证：跨异构服务集合安全、透明地管理用户身份
• 以安全可靠的方式确保用户多租户
• 将 CVS 分配的凭证合并到现有的 S3 数据访问框架中

为了解决这些问题，我们扩展了现有组件的附加功能，同时还构建了新的服务来在必要时填补空白。图 3 展示了最终的 FGAC 大数据整体架构。接下来，我们将提供有关这些新的和扩展的系统组件的详细信息，以及我们如何使用它们来应对挑战。

图 3：Pinterest FGAC Hadoop 平台

验证

提交交互式查询时，QueryBook 继续使用 OAuth 进行用户身份验证。然后，QueryBook 将 OAuth 令牌沿堆栈传递给 Livy，以安全地传递用户身份。

所有适用于我们的 FGAC 平台的预定工作流程现在都必须与服务帐户链接。服务帐户是不允许交互式登录而是由服务模拟的 LDAP 帐户。与用户帐户一样，服务帐户是授予其访问角色的各种 LDAP 组的成员。服务帐户机制将工作流程与员工身份解耦，因为员工通常只能在有限的时间内访问受限资源。Spinner 提取服务帐户名称并将其传递给作业提交服务 (JSS) 以启动 Monarch 应用程序。

我们使用Kerberos 协议对 QueryBook 和 Spinner 下游的所有系统进行安全用户身份验证。在研究其他替代方案时，我们发现 Kerberos 最适合我们的需求且可扩展。然而，这确实需要扩展我们的许多现有系统以与 Kerberos 集成，并构建/设置新服务来支持 Kerberos 部署。

与 Kerberos 集成

我们部署了密钥分发中心 (KDC) 作为 Kerberos 的基本基础。当客户端使用 KDC 进行身份验证时，KDC 将颁发票证授予票证 (TGT)，客户端可以使用该票证向其他 Kerberos 客户端验证自己的身份。TGT 将过期，长期运行的服务必须定期向 KDC 进行身份验证。为了促进此过程，服务通常使用密钥表本地存储的文件以维护其 KDC 凭据。需要密钥表的服务、实例和身份的数量太大，无法手动维护，因此需要创建自定义密钥表管理服务。每个服务上的客户端都会进行 mTLS 调用，从密钥表管理服务获取密钥表，该服务根据需要创建并提供密钥表。密钥表构成潜在的安全风险，我们已缓解如下：

• 仅限服务人员访问具有密钥表文件的节点
• mTLS 配置限制 Keytab 管理服务响应的节点以及它们可以获取的 keytab
• 所有经过 Kerberos 身份验证的端点都仅限于 Monarch 服务的封闭网络。外部调用者使用Apache Knox等代理服务将 Monarch 外部的 OAuth 转换为 Monarch 内部的 Kerberos 身份验证，因此 Keytab 在 Monarch 之外几乎没有什么用处。

我们将 Livy、JSS 以及所有其他互操作组件（例如 Hadoop 和 Hive Metastore）与 KDC 集成，以便可以在多个服务之间透明地交换用户身份。虽然其中一些服务（如 JSS）需要自定义扩展，但其他服务通过配置支持 Kerberos。我们发现 Hadoop 是一个特例。它是一组复杂的互连服务，虽然它广泛利用 Kerberos 作为其安全模式功能的一部分，但启用它意味着克服一系列挑战：

• 用户不会直接向我们的 Hadoop 集群提交作业。虽然 JSS 和 Livy 都在自己的 Kerberos 身份下运行，但我们将 Hadoop 配置为允许它们模拟其他 Kerberos 用户以代表其他用户和服务帐户提交作业。
• 每个 Hadoop 服务必须能够访问自己的 keytab 文件。
• 用户作业和 Hadoop 服务现在都必须在自己的 Unix 帐户下运行。对于用户作业，这需要：
• 将我们的集群与 LDAP 集成以在 Hadoop 工作节点上创建用户和服务帐户
• 配置 Hadoop 将提交作业的 Kerberos 身份转换为匹配的 UNIX 帐户
• 确保 Hadoop 数据节点在特权端口上运行
• YARN 框架在启动工作任务时使用LinuxContainerExecutor。该执行器确保工作任务进程以提交作业的用户身份运行，并限制用户只能访问工作人员上自己的本地文件和目录。
• Kerberos 对完全限定的主机和服务名称很挑剔，这需要大量的调试和跟踪才能正确配置。
• 虽然 Kerberos 允许通过 TCP 和 UDP 进行通信，但我们发现强制使用 TCP 有助于避免内部网络对 UDP 流量的限制。

用户多租户

在安全模式下，Hadoop 提供了多种保护来增强同一集群上运行的多个用户应用程序之间的隔离。这些包括：

• 对应用程序保存在 HDFS 上的文件实施访问保护
• Hadoop 组件和 DataNode 之间的数据传输是加密的
• Hadoop Web UI 现在受到限制并且需要 Kerberos 身份验证。客户端上的 SPNEGO 身份验证配置是不可取的，并且需要更广泛的密钥表访问。相反，我们使用Apache Knox作为网关，将内部 OAuth 身份验证转换为 Kerberos 身份验证，以将 Hadoop Web UI 端点与我们的内联网无缝集成
• Monarch EC2 实例被分配给 IAM 角色，并将读取访问权限设置为最低限度的 AWS 资源。尝试将权限升级到根工作线程的用户会发现他们能够访问的 AWS 功能比开始时要少。
• Spark 应用程序基于 AES 的 RPC 加密。

综上所述，我们发现这些措施可以为同一集群上运行的多个应用程序提供可接受的隔离和多租户级别。

S3数据访问

Monarch Hadoop 通过 S3A 文件系统实现访问 S3 数据。对于 FGAC，S3A 文件系统必须使用 CVS 对自身进行身份验证，获取适当的 STS 令牌，并将其传递给 S3 请求。我们通过自定义 AWS 凭证提供程序完成了此操作，如下所示：

• 这个新的提供商使用 CVS 进行身份验证。在内部，Hadoop 使用委托令牌作为扩展 Kerberos 身份验证的机制。自定义凭据提供程序将当前应用程序的委托令牌安全地发送到 CVS 以及 Hadoop 作业的用户身份。
• CVS 通过 Apache Knox 联系 Hadoop NameNode 来验证其收到的委托令牌的有效性，并根据请求的用户身份对其进行验证
• 如果身份验证成功，CVS 将使用授予用户的托管策略组合 STS 令牌并将其返回。
• S3A 文件系统使用用户的 STS 令牌来验证对 S3 文件系统的调用。
• S3 文件系统对 STS 令牌进行身份验证，并根据附加托管策略中的权限集合来授权或拒绝请求的 S3 操作
• 任何阶段的身份验证失败都会导致 403 错误响应。

我们在自定义凭证提供程序和 CVS 服务器上的客户端上利用内存缓存，以将 S3 访问和令牌获取的高频率降低到少量 AssumeRole 调用。缓存会在几分钟后过期，以便快速响应权限更改，但这么短的持续时间足以将下游负载减少几个数量级。这可以避免超出 AWS 速率限制，并减少 CVS 服务器上的延迟和负载。单个 CVS 服务器足以满足大多数需求，并部署额外的实例以实现冗余。

结论和后续步骤

FGAC 系统一直是我们在不断变化的隐私环境中保护数据的努力不可或缺的一部分。从第一个用例到支持来自一组服务集群的数十个独特访问角色，经过三年的扩展，该系统的核心设计保持不变。数据访问控制的粒度不断增加，数据管理员可以轻松授权特定用例，而无需创建昂贵的集群，同时仍然使用我们的全套数据工程工具。虽然 FGAC 的灵活性允许对任何 IAM 资源（而不仅仅是 S3）进行授权管理，但我们目前专注于将我们的核心 FGAC 方法用于构建 Pinterest 的下一代基于 Kubernetes 的大数据平台。

这种雄心和规模的项目只有在 Pinterest 多个团队的合作和努力下才能实现。我们衷心感谢他们所有人以及最初的 FGAC 团队为这一切奠定了基础：Ambud Sharma、Ashish Singh、Bhavin Pathak、Charlie Gu、Connell Donaghy、Dinghang Yu、Jooseong Kim、Rohan Rangray、Sanchay Javeria、Sabrina Kavanaugh 、Vedant Radhakrishnan、Will Tom、Chunyan Wang 和 Yi He。我们还要最深切地感谢我们的 AWS 合作伙伴，特别是 Doug Youd 和 Becky Weiss，并特别感谢该项目的赞助商 David Chaiken、Dave Burgess、Andy Steingruebl、Sophie Roberts、Greg Sakorafis 和 Waleed Ojeil 所投入的时间和精力。团队使这个项目取得成功。

作者:

Soam Acharya | Data Engineering Oversight; Keith Regier | Data Privacy Engineering Manager

出处:https://medium.com/pinterest-engineering/securely-scaling-big-data-access-controls-at-pinterest-bbc3406a1695