超越單點登入：保障分散式 AI 平台的身分安全

在現代 AI 平台中，使用者不再只在單一畫面完成登入。從中央入口開啟受管資料集、啟動 Notebook、再呼叫位於其他叢集的服務，整個工作流程看似統一，卻必須在 控制平面（control‑plane）與 資料平面（data‑plane）之間不斷傳遞身分資訊。傳統的 單點登入（SSO） 只能在入口驗證使用者，無法保證身分在分散執行環境中的安全傳遞，因而已不足以支撐多雲或多叢集的 AI 應用。

為何需要身分傳遞模型？

使用者體驗：若每個叢集都要求重新驗證，會出現頻繁的登入提示，降低工作效率。
平台工程：身份資訊必須從控制平面轉換為 受信任、具範圍、可稽核 的本地上下文，才能在資料平面安全使用。
資料與運算位置分散：資料往往與產生或治理的地方緊密相連，計算可能在區域叢集、不同雲帳號、內部部署或專屬執行平面上執行，仍需同一套身分判斷。

中央身分閘道（Identity Gateway）模式

此模式以 OpenID Connect（OIDC） 為標準協議，透過共享的會話儲存（session store）與 無狀態資料平面閘道（stateless data‑plane gateways）實作。核心流程如下：

使用者在中央入口完成 SSO，產生平台會話。
資料平面閘道透過一組 身分驗證 API 向中央閘道查詢會話，取得 本地信任的身分上下文。
下游應用（Notebook、目錄 API、AI 助手等）以此上下文執行授權檢查，無需自行處理原始 token。

此設計避免了將原始 token 洩漏至每個應用，降低了撤銷（revocation）難度，也免除各叢集重寫身分提供者（IdP）邏輯的負擔。

NVIDIA 的實務驗證

在 NVIDIA 內部，將此模式部署於跨 AWS 與 OCI 的多個 Kubernetes 叢集後，重複登入事件減少 55%。更重要的是，平台獲得了：

可重複使用的統一平台外殼（unified platform shell）
一致的登出機制
上游 IdP 負載下降
AI 助手能以 委派使用者身分 跨資料平面執行任務

未來展望與讀者啟示

對於管理 聯邦式 Kubernetes 環境、跨雲資料平台、機器學習工作台或內部開發者入口 的團隊而言，SSO 仍是入口門檻，但必須配合中央身分閘道才能在分散式執行環境中保持安全與一致性。未來，隨著 AI 助手與自動化工作流的普及，身分即服務（Identity‑as‑a‑Service） 的概念將成為平台設計的基石。企業在規劃新一代 AI 平台時，應優先評估身分傳遞的標準化與可擴展性，才能在多雲、多叢集的複雜環境中，提供使用者無縫且安全的體驗。