本文是一篇利用 AI 创建的技术解析与实现示例。虽然所发布的代码和步骤基于一手资料构建，但未经笔者在实际设备上进行运行验证。根据环境和版本的不同，实际运行结果可能会有所差异。

从官方信息了解如何在联合 Kubernetes 和 AI Platform 之间传递用户身份

在现代 AI 平台和分布式数据基础架构中，要求能够整合跨多个集群或云环境的工作流，而不仅仅是单一登录界面背后的单个应用程序。用户可以通过中央门户网站浏览数据、启动笔记本（Notebook），并使用调用另一个集群上服务的 AI 助手。在此过程中，需要在控制平面和数据平面的边界之间安全、可靠地传递用户的身份（Identity）。 本文基于 NVIDIA Technical Blog 上发布的“How to Carry User Identity Across Federated Kubernetes and AI Platforms”这一一手资料，梳理了分布式 Kubernetes 及 AI 平台中用户身份传播所面临的挑战，以及解决该问题的集中式身份网关模式（Centralized Identity Gateway Pattern）。

从一手资料中了解的背景与挑战

在现代 AI 工作流中，数据和计算资源被部署在靠近其生成、存储和治理的地方。即使工作流分布在多个区域集群、不同的云环境、本地（On-Premises）或专用的执行平面中，用户也期望在笔记本、目录、查询工具、仪表盘和 AI 助手之间获得一致的平台体验。

传统的单点登录（SSO）对于入口处的身份验证虽然有效，但要在数据平面或分布式环境中原封不动地带入上下文，则会显得力不中心。如果将 SSO 令牌（Token）原始转发给所有应用程序，将会扩大凭据的暴露范围，使吊销处理变得复杂，并迫使每个集群各自承担实现身份提供商（IdP）集成的负担。

以下展示了分布式会话所有权模型中产生的结构性问题。

sequenceDiagram
    participant User as ユーザー
    participant GW1 as リージョンGateway A
    participant GW2 as リージョンGateway B
    participant IdP as Identity Provider
    User->>GW1: ツールAへアクセス
    GW1->>IdP: 独立したOIDCリダイレクト・ログイン
    IdP-->>GW1: トークン発行・セッションA作成
    User->>GW2: ツールBへアクセス
    GW2->>IdP: 再度独立したOIDCリダイレクト・ログイン
    IdP-->>GW2: 別途トークン発行・セッションB作成

分布式会话所有权模型的挑战

• 会话割裂: 在颁发令牌的网关之外无法识别该状态，导致每个服务都会发生重新认证，而不是在整个平台范围内进行。

• 注销的局限性: 即使从一个工具中登出，其他地方仍会残留活动会话，从而引发安全风险和混乱。

• 令牌刷新的异步性: 每个网关与上游 IdP 分别进行更新处理，导致负载增加和状态不一致。

• 不一致的身份上下文: 每个下游服务对令牌的解释或认证逻辑出现重复和分散。

• 缺乏可扩展性: 每当添加新工具时，都需要重新进行类似的认证基础架构集成。

两种身份模式的比较

一手资料中，对 federated 平台中的身份结构比较了“分布式会话所有权（Distributed session ownership）”和“集中式会话所有权（Centralized session ownership）”这两种模式。

集中式模式并非所有应用程序所必需，但当用户期望在单个工作流中穿梭于多个工具、集群和区域，并且这些工具作为一个单一平台运行时，它将展现出极高的价值。

集中式身份网关模式的组成要素

一手资料中所阐述的集中式身份网关模式是一种将“会话所有权”与“请求强制执行（Enforcement）”进行分离的架构。

该模式由以下主要组成要素和角色构成：

1. 单一会话所有者（Central Identity Gateway）

负责创建和管理整个平台的会话。处理 OIDC（OpenID Connect）授权码流程，并将获取到的会话以带有生存时间（TTL）的形式存储在诸如 Redis 等共享存储中。

2. 最小化验证端点（/gateway/userinfo）

这是供各个区域的数据平面网关用来查询用户身份的轻量级边车调用（Side-call）API。它避免了原始令牌的传输，统一验证会话的有效性。

3. 无状态区域网关（Stateless Regional Gateways）

部署在各个集群中，将会话验证本身委托给中央网关，同时负责应用本地策略或注入经过验证的、受信任的身份标头。

4. 共享会话存储与浏览器 Cookie

使用限定在平台域内的安全 HTTP 专属（HttpOnly）Cookie 来保存会话 ID，并通过后端 Redis 等机制共享会话状态。

5. 平台范围内的单点注销

通过在中央身份网关侧删除会话记录，使得在下次请求时所有区域网关都能立即检测到无效会话，从而拒绝访问或引导用户重新登录。

请求流程的机制

集中式网关中的基本请求处理流程可分为登录、验证、令牌刷新与注销这三类。

1. 登录流程: 当没有有效平台会话的用户访问区域网关时，将被重定向到中央身份网关。中央网关完成与 IdP 的 OIDC 流程，将会话保存到 Redis 中，并颁发 HTTP-only 的会话 Cookie。

2. 验证流程（Per-request validation）: 在后续请求中，区域网关将会将会话 Cookie 发送至 /gateway/userinfo，中央网关会查找会话并返回用户 ID、电子邮件、群组和角色等声明。区域网关以此为基础，将标准化的身份标头附加到下游服务中。

3. 令牌刷新与注销: 当访问令牌接近过期时，利用中央网关持有的刷新令牌（Refresh Token）进行更新，并同步共享存储上的状态。注销时，中央会话记录将被删除，并在所有网关中立即失效。

安全与可靠性护栏

当架构走向集中化时，身份网关本身将成为一个极其关键的组件，因此一手资料中指出了以下安全与可靠性护栏：

• 服务间认证: 在区域网关与中央身份网关之间利用双向 TLS（mTLS）、工作流标识或带签名的内部令牌，防止来自未经授权的调用方的访问验证端点。

• 标头净化（Sanitizing）: 务必丢弃客户端发送的入站身份标头，仅在网关层注入新生成的受信任标头。

• 保护会话存储: 在会话记录中仅存储平台所需的最小信息，并应用短生命周期的访问令牌、明确的会话 TTL、传输加密以及适当的访问控制。

• 定义故障时的行为: 明确当身份网关或会话存储不可用时的行为（如拒绝所有请求的故障关闭设计，或引入用于提高弹性的短期缓存验证等）。

• 记录审计日志: 统一记录验证、刷新和注销的各个事件，生成关于“谁访问了哪个服务”的可靠审计跟踪。

在平台开发中的应用与优势

文章记载，在 NVIDIA 的内部开发平台（跨 AWS 和 OCI 的 Kubernetes 集群）的实现中，这种方法使重复的登录事件减少了 55%。

通过应用此模式，可以获得以下效果和优势：

• 减轻上游 IdP 的负载: 实现与活跃用户数成正比的可扩展性，而不是与用户、工具和集群的组合数量成正比。

• 集成 AI 与数据工作流: 能够构建集成的平台 Shell 或以委托的用户身份运行的 AI 助手基础架构。当 AI 助手调用后端工具时，能够直接继承用户的 RBAC（基于角色的访问控制）范围。

• 分阶段迁移模型: 无需一次性更改所有系统，而是可以逐个迁移网关或服务。

参考信息

• How to Carry User Identity Across Federated Kubernetes and AI Platforms