背景：雲端工作負載如何證明自己的身分
在大型資料平台中，運算工作負載通常同時存在於多套身分系統。Netflix 的 Apache Spark 工作在 Amazon EMR 上執行，而內部服務則使用 Metatron 這套私有公開基礎設施（PKI），透過短效 X.509 憑證進行相互 TLS 驗證。當 Spark 工作需要存取內部服務時，必須先讓服務相信：這項工作不僅持有某個 AWS 身分，也確實對應到 Netflix 內部指定的資料專案。
AWS 的 IAM execution role 負責辨識受管工作負載，但 IAM 角色本身並不能直接表達「這是某個 Data Project 的工作」。Metatron 憑證則能代表內部身分，卻缺少將該身分安全地連結到 AWS 執行角色的方法。若要求工作負載事先注入金鑰，憑證管理會變得複雜，也容易形成長期秘密集中與散布的風險。
Netflix 據 InfoQ 報導，Big Data Platform Engineer Dhruv Pratap 曾公開說明其工作負載證明（workload attestation）設計。核心目標不是讓兩套身分系統各自保留，而是在每次啟動與續期時，建立一個可驗證的證明，證明 AWS 角色持有者與內部 Data Project 身分之間的對應關係。
核心概念：以兩份獨立證據建立身分交集
Netflix 的做法是讓控制平面（control plane）與 Identity service 合作。每一個 Data Project 都對應一個專屬的 IAM execution role。由於 Data Projects 的數量預期會達到數萬個，Netflix 沒有把這些角色全部集中在同一個 AWS 帳戶，而是以確定性的方式，將角色分散配置到多個專用 AWS 帳戶中，避免單一帳戶成為規模與權限管理的瓶頸。
當工作被提交時，控制平面先驗證請求，解析出該 Data Project 應使用的 IAM role，並建立一份帶有簽章的工作負載 metadata。這份 metadata 會指定這次預期執行的特定工作負載。控制平面是唯一被授權建立這類聲明的服務，因此內部控制流程不會因任意工作自行宣稱身分而失去可信度。
接著，Spark driver 使用其 execution role 關聯的憑證，向 AWS Security Token Service（AWS STS）的 GetCallerIdentity 端點建立預簽署請求。Identity service 取得並檢視這個請求，從 AWS 端辨識出是哪個 IAM role 簽署了請求。這形成第一份證據：工作負載能夠證明自己持有預期 AWS 角色的憑證。
控制平面產生的簽章 metadata 則形成第二份證據：內部控制流程已指定這項工作應屬於哪個 Data Project 身分。Identity service 會比較 AWS 回應與控制平面的簽章資料；當兩者的 AWS 角色、工作負載身分與 Data Project 對應關係一致時，Identity service 才簽發 Metatron 的 X.509 憑證。憑證可用於內部服務之間的相互 TLS 驗證。
運作方式：先完成一次證明，再安全分發給 Spark 執行器
Netflix 將初始身分建立與後續續期分開處理。初始流程完成後，Spark driver 會在短效憑證到期前定期重新進行工作負載證明。重新證明不是形式上的重複動作，而是確保長時間執行的工作負載仍能維持身分主張與 AWS 角色之間的有效連結。
這項設計也處理了 Spark 的 executor fan-out，也就是一個 driver 可能啟動數千個 executor 的問題。若每個 executor 都各自向 Identity service 發出證明請求，流量會直接隨 executor 數量增加。Netflix 讓 driver 先完成一次證明，再透過已驗證且加密的 Spark RPC，將憑證分發給各個 executor。
因此，證明流量不會隨 executor 數量按比例膨脹。不過，這也代表 driver 成為額外的憑證分發信任邊界。driver 若遭入侵，可能危及分發給 executor 的內部憑證；所以其保護、網路隔離與 RPC 驗證仍然重要。這個架構並不是消除所有信任關係，而是把大量 executor 的重複證明集中到較少的控制與傳輸路徑。
實務意義：降低手動憑證注入，同時保留可追溯的雲端證據
工作負載證明讓 Netflix 不必在啟動腳本或環境變數中手動注入內部服務憑證。受管運算環境仍由 AWS 提供身分與執行角色，而內部服務則繼續採用 Metatron 的短效憑證。兩套系統各自保持原本的職責，同時透過一次受控的交接，將 AWS 身分轉換成內部工作負載身分。
這種方式也讓 Data Project 能夠作為資料存取的所有權與身分邊界。資料平台的隔離不只體現在 IAM 角色，也反映在內部憑證及其簽發流程。工作是否被允許存取某個資料專案，因而不再只依賴工作負載自我宣告，而需要同時通過 AWS 端可驗證的角色證據，以及控制平面簽章的工作 metadata。
從安全性來看，AWS STS 回應提供的是「持有預期 IAM role 憑證」的證明，控制平面簽章則提供「這是預期工作負載」的證明。兩者交集才足以觸發 Metatron 憑證簽發。Netflix 表示，這種模式也能應用於其他受管運算環境：工作負載在雲端取得身分，但組織內部仍需要建立獨立且可驗證的身分。
影響與限制：身分橋接不是身分系統的全面整合
這項機制的限制，首先是它仍依賴多個控制元件的正確協作。控制平面必須確保 metadata 與實際提交的 Data Project、IAM role 和工作負載相符；Identity service 則必須安全地取得 AWS STS 回應，並嚴格比對兩份證據。任何簽章金鑰保管、請求重放防護或比對邏輯上的問題，都可能影響憑證是否被正確簽發。
此外，短效憑證並不代表只需在啟動時處理一次。Netflix 特別將初始 bootstrap 與 renewal 分離，讓 driver 在憑證到期前反覆重新證明。executor 不會各自獨立續期，而是依賴 driver 透過加密 RPC 更新其使用的憑證。這種集中式續期降低了流量與協調成本，卻也讓 driver 的可用性和安全性更直接影響整個 Spark 工作的身分有效性。
整體而言，Netflix 的工作負載證明提供了一種在混合雲端與內部 PKI 之間建立連接的實務模式。它不是把 AWS IAM 與 Metatron 合併成單一系統，而是利用 AWS 可驗證的執行身分，加上內部控制平面的簽章 metadata，產生短效的內部工作負載憑證。對需要同時管理大型資料專案、受管運算角色與內部微服務身分的組織而言，這種設計的核心價值在於：讓身分交接可驗證、憑證壽命有限，並避免依賴人工注入共享秘密。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。