現代AI平台早已不是單一登錄頁面背後的單一應用。用戶可能從一個中央門戶開始，打開一個受治理的數據集，在數據所在的集群中啟動一個筆記本環境，再調用一個會訪問另一集群服務的助手。整個流程看似統一，但每一步都跨越了控制平面和數據平面的邊界。這正是傳統單點登錄（SSO）力不從心的地方。
SSO只在入口處驗證用戶身份。對於管理跨多集群的聯邦數據或AI平台的團隊而言，仍需要一種可靠方式，將用戶上下文傳遞到分布式執行環境中，同時不能將原始令牌直接暴露給每個應用、削弱撤銷機制，或迫使每個集群重複實現身份提供商的邏輯。
這一挑戰對AI和數據平台尤為重要，因為數據和計算通常會靠近其產生、儲存或被治理的位置。工作負載可能運行在區域集群、獨立的雲賬戶、本地環境或專用執行平面中。而用戶仍期望在筆記本、目錄、查詢工具、儀錶盤和AI助手之間獲得統一的平台體驗。
本文介紹一種中央身份網關模式，用於在這些聯邦數據平面間傳遞用戶身份。中央網關擁有平台會話的所有權，數據平面網關通過共享API驗證該會話，並將其轉換為下游應用可信任的本地身份上下文。該模式使用標準的OpenID Connect（OIDC）協議、共享會話儲存、無狀態的數據平面網關，以及一個各服務都能信任的小型身份驗證API。
在英偉達
內部，這一方法使橫跨AWS和OCI上Kubernetes集群的內部開發者平台重複登錄事件減少了55%。更重要的是，它為統一的平台外殼、一致的登出體驗、更低的上游身份提供商負載，以及能夠以委託用戶身份跨數據平面執行操作的AI助手，奠定了可復用的基礎。
SSO的終點與數據平面身份的起點
具體實施細節會因組織而異，但核心設計思路廣泛適用於運行聯邦Kubernetes環境、多雲數據平台、機器學習工作檯、內部開發者門戶，或包含多個已認證工具的AI應用棧的平台團隊。SSO為用戶提供了一個入口。
聯邦數據平台仍需要一種方式，將身份傳遞到實際執行工作的各個平面。一個集群中的筆記本、另一集群中的目錄API，以及第三個集群中調用查詢引擎的助手，都需要相同的答案：這個用戶是誰，他們在這裡被允許做什麼？
如果沒有共享的身份傳遞模型，會出現以下幾個問題：
控制平面的身份認證不會自動轉化為可信的數據平面身份
原始令牌轉發會擴大憑證暴露面，也讓人更難判斷誰能在何處使用哪個令牌
每個數據平面網關可能以不同方式與身份提供商集成，導致聲明不一致、刷新行為各異、審計記錄參差不齊
登出和撤銷可能無法在所有集群或執行平面中及時同步
新應用繼承的是身份接入的繁瑣邏輯，而不是消費一個標準的平台契約
對用戶來說，症狀可能表現為反覆的登錄提示。對平台工程師而言，更深層的問題是分布式令牌傳遞：在控制平面創建的身份，必須在每個數據平面上被轉化為可信、有範圍限定、可審計的上下文。
這種模式在應用數量較少時是可行的，但隨著平台擴展會產生結構性問題：
會話被限定在創建它的位置。一個網關簽發的令牌對另一個網關來說是未知的，因此用戶需要針對每個服務而非整個平台進行認證
登出是局部的。退出一個工具的登錄狀態，可能會讓其他地方的會話仍處於活躍狀態，既造成用戶困惑，也帶來安全風險
令牌刷新缺乏協調。每個網關都獨立地與上游身份提供商協商刷新周期，增加負載並造成會話狀態分歧
身份上下文不一致。下游服務往往以不同方式解析令牌，或重複實現認證邏輯
新服務繼承舊的複雜性。添加新工具通常意味著要重新構建同樣的認證集成
對平台用戶而言，症狀是反覆的登錄提示和不一致的行為。對平台工程師而言，更深層的問題是：會話所有權分散在多個組件中，而這些組件本應只負責執行訪問控制，而非擁有身份狀態。
兩種身份模式的比較
在聯邦平台中構建身份體系有兩種常見方式。
第一種模式是分布式會話所有權。每個服務網關擁有自己的登錄流程、會話儲存、令牌刷新邏輯和登出行為。這使每個集群保持獨立，但也意味著身份狀態無法在平台內順暢流動。
第二種模式是集中式會話所有權。一個專用的身份網關擁有登錄、會話狀態、刷新和登出的全部控制權。區域網關依然存在，但它們將會話驗證工作委託給中央身份網關，自身專注於請求執行。
表1：分布式與集中式會話所有權在登錄、登出、令牌刷新、身份傳遞和運維擴展方面的比較。
集中式會話所有權並非每個應用都必需。當用戶在一個工作流中跨多個工具、集群或區域移動，並期望這些工具表現得像單一平台時，這種模式才會體現出價值。
中央身份網關模式
中央身份網關承擔三項職責：
會話創建：處理OIDC授權碼流程，創建平台級會話
按請求進行身份驗證：為任何網關或可信服務回答"這是誰"的問題
會話生命周期管理：協調平台內的令牌刷新和登出
區域認證網關依然存在，它們仍負責執行集群級策略、保護本地服務、向請求注入身份資訊。改變的是會話儲存在哪裡。
中央身份網關不再將會話儲存在每個區域網關內部，而是將每個已認證的會話寫入共享儲存（如Redis）。會話由不透明的會話ID作為鍵，並與一個限定在平台域名下的安全HTTP-only瀏覽器Cookie相關聯。
每次請求時，區域網關會調用一個身份驗證端點，例如/gateway/userinfo。中央身份網關檢查會話儲存並返回可信的身份聲明。區域網關隨後在轉發請求前注入一組標準化的身份頭資訊。
應用不再需要解析令牌、刷新憑證，或直接與身份提供商集成，而是通過一致的接口獲取身份資訊。
請求流程
該模式包含三個主要流程：登錄、驗證和登出。
登錄
當用戶在沒有有效平台會話的情況下訪問時，區域網關會將瀏覽器重定向到中央身份網關。中央網關針對組織的身份提供商執行OIDC授權碼流程，在服務端交換授權碼，將生成的會話以設定的存活時間存入Redis，並設置HTTP-only會話Cookie。
該會話Cookie將成為用戶在整個會話期間的平台憑證。
按請求驗證
在後續請求中，區域網關將會話Cookie發送到/gateway/userinfo。中央身份網關執行會話查找，並返回諸如用戶ID、郵箱、組、角色和會話元數據等身份聲明。
區域網關利用這些聲明注入可信的身份頭資訊，下游服務讀取這些頭資訊，並在需要時應用本地授權邏輯。
這使請求路徑保持輕量。普通請求不需要OIDC交換或直接調用身份提供商，只需要一次會話查找和一次可信的網關間驗證調用。
令牌刷新與登出
當訪問令牌接近過期時，中央身份網關會使用儲存的刷新令牌進行刷新，並更新會話記錄。由於刷新後的狀態被寫入共享儲存，每個區域網關都能觀察到相同的會話狀態。
對於登出，中央身份網關會刪除會話記錄。在下一次請求時，每個區域網關都會發現會話無效，從而拒絕訪問或將用戶重定向到登錄頁面。登出因此變得即時且覆蓋整個平台。
開發者可復用的部分
英偉達實現方案背後的具體基礎設施是內部的，但這一架構模式是可移植的。外部平台團隊可以復用以下要素：
平台的單一會話所有者
最小化的驗證端點，例如/gateway/userinfo
委託驗證工作的無狀態區域網關
帶有明確存活時間的共享會話儲存
面向下游服務的標準化身份聲明或頭資訊
能使共享會話失效的單一登出路徑
一次遷移一個網關或服務的遷移模型
該模式不需要專有中間件，可以用標準OIDC庫、Redis或其他低延遲會話儲存，以及常見Kubernetes入口控制器或服務網格環境中提供的網關集成來實現。
安全與可靠性防護
集中化會話所有權簡化了平台架構，但也使身份網關成為關鍵服務。採用這一模式的團隊應從一開始就為故障場景、信任邊界和可審計性進行設計。
在區域網關與中央身份網關之間使用安全的服務間認證。雙向TLS、工作負載身份或簽名的內部令牌，都可以防止不受信任的調用方使用驗證端點。
在注入可信頭資訊之前，先剝離入站的身份頭資訊。應用應只信任網關層添加的頭資訊，而不是客戶端請求提供的頭資訊。
會話記錄中只儲存平台所需的內容。應用短生命周期的訪問令牌、明確的會話存活時間、刷新令牌保護、傳輸加密，以及對會話儲存的適當訪問控制。
明確定義故障行為。某些平台應採取失敗關閉策略，在身份網關或會話儲存不可用時拒絕所有請求；另一些平台則可能需要短生命周期的緩存驗證以提高韌性。這一決策應當明確並與平台的風險模型保持一致。
記錄驗證、刷新和登出事件。集中化使生成可靠的審計軌跡變得更容易，能夠清晰顯示誰訪問了哪些服務，以及其會話何時發生變化。
降低上游身份系統的負載
集中式會話所有權一個不太明顯的好處是能降低對上游身份基礎設施的負載。
在分布式模型中，每個區域網關可能獨立調用身份提供商、令牌密鑰儲存和授權策略引擎。當用戶在三個工具之間切換時，平台可能要執行三次獨立的令牌交換、三條獨立的刷新路徑和三次策略評估。
有了中央身份網關，身份提供商每次登錄只會被調用一次。區域網關針對共享會話進行驗證，而不是重複執行OIDC流程。令牌刷新由一個服務統一協調，緩存的授權上下文可以在過期前被重複使用。
隨著集群和工具數量的增長，上游身份負載的擴展速度將更接近活躍用戶數量，而非用戶-工具-集群組合的數量。在將眾多工具嵌入單一工作流的平台中，這一差異變得尤為重要。
賦能統一的AI與數據工作流
集中式身份還能支撐更高層次的平台能力。
統一的平台外殼可以在單一登錄之後嵌入多個工具和助手。每個嵌入式應用仍通過網關層驗證請求，但用戶體驗到的是單一的已認證平台。
AI助手同樣受益於這一模型。平台助手通常需要代表用戶查詢數據、檢索元數據、調用工具並匯總結果。藉助集中式會話驗證，助手可以通過平台會話解析用戶身份，並將可信的身份上下文傳遞給後端工具。
這意味著助手不需要廣泛的服務憑證或針對每個工具的獨立登錄流程，其操作可以繼承用戶的RBAC權限範圍，使系統更易於推理和審計。
應用這一模式
要在自己的平台中應用這一架構，首先應梳理當前會話在何處被創建。識別哪些網關運行OIDC流程、哪些服務直接解析令牌、下游應用信任哪些頭資訊，以及當前登出是如何工作的。
然後明確中央契約：
哪個服務擁有會話創建的所有權？
/gateway/userinfo將返回哪些聲明？
哪個網關層被允許注入身份頭資訊？
平台會話應存續多久？
刷新和登出將如何被審計？
如果會話儲存不可用會發生什麼？
契約明確後，採取漸進式遷移。先從一個區域網關或一組相關服務入手，用對中央身份網關的調用取代本地會話驗證，同時保持面向應用的身份接口穩定，以避免下游服務大規模重寫。
第一次遷移成功後，再逐步加入更多網關和工具。目標不是取消每一個本地執行點，而是讓每一個執行點都從同一個會話真相來源讀取資訊。
一個關鍵問題
分布式會話狀態是一種悄然積累的架構債務。它最初往往表現為反覆的登錄提示，但更大的代價是重複的認證邏輯、不一致的登出行為、不必要的身份提供商負載，以及碎片化的用戶上下文。
中央身份網關通過將會話所有權與請求執行分離來解決根本問題。一個服務擁有登錄、刷新、驗證和登出的全部控制權，區域網關則在讀取共享會話記錄的基礎上，在本地執行訪問控制。
在英偉達，這一模式將重複登錄事件減少了55%，並為統一的開發者門戶和具備委託用戶身份能力的AI助手奠定了基礎。同樣的方法也可以幫助其他構建聯邦Kubernetes、數據和AI環境的平台團隊。
要評估這一模式是否適合你的平台，可以先問自己一個問題：如今會話狀態儲存在哪裡？有多少服務正在做出它們本不該做的身份判斷？如果答案顯示出比預期更多的分布式會話狀態，那麼遷移路徑其實很直接：選定一個網關，用中央驗證調用取代本地會話驗證，在擴展的同時保持平台其餘部分的穩定。
開始行動
準備好實現類似的身份感知網關架構了嗎？可以從OAuth2 Proxy本地環境入手，探索OIDC登錄、Cookie處理和基於Redis的會話管理。接下來，參考Istio外部授權示例來定義認證網關接口，並通過OPA Envoy Istio示例添加Rego策略評估。若需要涵蓋JWT和API密鑰驗證、元數據增強、策略決策以及可信上游頭資訊的集成參考方案，可以了解Authorino。
這些項目共同為實現本文所述的身份、網關和策略層提供了實用的起點。
Q&A
Q1：中央身份網關模式主要解決什麼問題？
A：它解決的是聯邦Kubernetes和AI平台中用戶身份跨集群、跨數據平面傳遞的問題，避免了重複登錄、令牌暴露和各集群重複實現身份提供商邏輯等困擾。
Q2：這種架構給英偉達帶來了什麼實際效果？
A：在英偉達內部，該模式使橫跨AWS和OCI上Kubernetes集群的開發者平台重複登錄事件減少了55%，同時為統一平台外殼、一致登出、降低身份提供商負載以及具備委託身份能力的AI助手打下了基礎。
Q3：採用這種模式需要注意哪些安全問題？
A：需要在區域網關與中央身份網關之間使用安全的服務間認證，剝離入站身份頭資訊，只在會話中儲存必要資訊，明確定義故障時的處理方式，並記錄驗證、刷新和登出事件以便審計。
