安全擴充 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