如何在联邦式 Kubernetes 与 AI 平台间传递用户身份
现代 AI 平台早已不是单一登录界面后的单个应用。用户可能从中央门户开始，打开受治理的数据集，启动托管该数据 Notebook，并调用在另一个集群中调用服务的助手。工作流看起来是统一的，但身份在每个步骤都会跨越控制面和数据面边界。这正是传统单点登录（SSO）不再足够的原因。
SSO 在入口处证明用户身份。在多集群间管理联邦数据或 AI 平台的基础设施团队，仍需要一个可靠的方式来将用户上下文传递到分布式执行环境，同时避免向每个应用分发原始令牌（削弱吊销能力）、或要求每个集群重新实现身份提供商逻辑。
这一挑战对 AI 和数据平台尤为重要，因为数据和计算往往靠近其产生、存储或治理的位置。工作负载可能运行在区域集群、独立的云账号、本地环境或专用执行面中。用户仍期望在所有组件（Notebook、目录、查询工具、仪表板、AI 助手）中获得一致的平台体验。
本文介绍了一种中央身份网关模式，用于在这些联邦数据面之间传播用户身份。中央网关持有平台会话。数据面网关通过共享 API 验证该会话，并将其转换为下游应用可信任的本地身份上下文。该模式使用标准的 OpenID Connect (OIDC)、共享会话存储、无状态数据面网关，以及服务可信任的小型身份验证 API。
在 NVIDIA，这种方法使跨越 AWS 和 OCI 中 Kubernetes 集群的内部开发者平台重复登录事件减少了 55%。更重要的是，它构建了可复用的基础，支持统一平台外壳、一致登出、更低的上游身份提供商负载，以及能够在数据面间以委托用户身份操作的 AI 助手。
SSO 的终点与数据面身份的起点
实现细节因组织而异，但核心设计广泛适用于运行联邦 Kubernetes 环境、多云数据平台、机器学习工作台的平台的团队，以及拥有多种认证工具的内部开发者门户或 AI 应用栈。SSO 为用户提供了单一入口点。
联邦数据平台仍然需要一种方式，把用户身份传递到实际执行工作负载的各个平面。一个集群里的 Notebook、另一个集群的 catalog API、第三个集群里调用查询引擎的 AI 助手，都需要回答同样的问题：用户是谁？在这里能做什么？
如果没有统一的身份传递模型，会出现以下问题：
- 控制平面的认证结果不会自动成为可信的数据平面身份
- 直接转发原始 token 会扩大凭据暴露面，也更难判断谁能在哪里使用哪个 token
- 每个数据平面网关与身份提供方的集成方式可能不同，导致 claims、刷新行为和审计记录不一致
- 登出和吊销可能无法快速传播到每个集群或执行平面
- 新应用只能自己继承一套身份基础设施，而不是直接使用标准的平台契约
对用户来说，最直观的体现是反复被要求登录。而对平台工程师来说，更深层的问题在于分布式 token 传递：在控制平面创建的身份，必须在每个数据平面被转换为可信、受限、可审计的上下文。
该模式在小规模应用时可行，但随着平台扩张会带来结构性问题：
- 会话范围局限于创建地点。一个网关签发的令牌对另一个网关不可见，用户因此按服务而非按平台认证
- 登出操作是局部的。退出某个工具后，其他工具的会话可能仍活跃，既造成用户困惑，也带来安全风险
- 令牌刷新缺乏协调。各网关独立与上游身份提供商协商刷新周期，不仅增加负载，还会导致会话状态出现分歧
- 身份上下文不一致。下游服务往往以不同方式解析令牌，或重复实现认证逻辑
- 新服务继承既有复杂度。新增工具通常意味着重新构建同样的认证集成
对平台用户而言，症状是反复弹出登录提示和行为不一致；对平台工程师而言，更深层的问题是会话归属分散在各组件中，而这些组件本应只负责访问控制，不应持有身份状态。
两种身份模式的比较
在联邦化平台中，常见的身份组织方式有两种。
第一种是分布式会话归属。每个服务网关各自维护登录流程、会话存储、令牌刷新逻辑和登出行为。这种方式保留了各集群的独立性，但也意味着身份状态无法在整个平台中顺畅流转。
第二种是集中式会话归属。一个专属的身份网关统一负责登录、会话状态、刷新和登出。区域网关仍然保留，但将会话验证委托给中央身份网关，自身专注于请求执行。
| 设计选型 | 分布式会话所有权 | 集中式会话所有权 |
|---|---|---|
| 登录体验 | 用户每个工具或网关需单独登录 | 用户每次平台会话只需登录一次 |
| 登出行为 | 局限于某个服务或集群内 | 通过单一会话记录实现全平台登出 |
| Token 刷新 | 各网关独立重复执行 | 由中央网关统一协调 |
| 上游 IdP 负载 | 随用户、工具和集群数量线性扩展 | 主要随活跃用户数扩展 |
| 下游身份传递 | 往往存在重复或不一致 | 通过可信 headers 或 claims 标准化 |
| 运维模式 | 初期简单，规模化后复杂 | 需中央服务，但对新工具更简单 |
表 1. 跨登录、登出、Token 刷新、身份传播及运营扩展的分布式与集中式会话所有权对比。
并非所有应用都需要集中式会话所有权。当用户以单一工作流在不同工具、集群或区域间移动，并希望这些工具表现得像一个统一平台时，集中式会话所有权才体现出价值。
集中式身份网关模式
中央身份网关承担三项职责：
- 会话创建：处理 OIDC 授权码流程，建立全平台统一的会话
- 请求级身份验证：为任何网关或受信任服务解答“这个用户是谁”
- 会话生命周期管理：在全平台范围内协调令牌刷新与登出
各区域认证网关保持不变。它们仍然执行各集群的策略、保护本地服务，并将身份注入请求。变化的只是会话的存放位置。
中央身份网关不再将会话存储在各区域网关内部，而是把每个已认证的会话写入共享存储（如 Redis）。会话以不透明的会话 ID 为键，并与一个安全的、作用域为平台域名的 HTTP-only 浏览器 Cookie 关联。
每次请求时，区域网关会调用类似 /gateway/userinfo 的身份验证端点。中央身份网关检查会话存储后返回可信的身份声明，再由区域网关在转发请求前注入标准化的一组身份头信息。
应用无需再解析令牌、刷新凭证或直接对接身份提供商，只需通过统一接口消费身份即可。
请求流程
该模式包含三种主要流程：登录、验证和登出。
登录
当用户到达且没有有效的平台会话时，区域网关会将浏览器重定向到中央身份网关。中央网关针对组织的身份提供商执行 OIDC 授权码流程，在服务端交换授权码，将生成的会话存入 Redis（设置指定的 TTL），并设置一个 HTTP-only 会话 Cookie。
该会话 Cookie 成为用户在整个会话期间使用的平台凭证。
逐请求验证
在后续请求中，区域网关将会话 Cookie 发送至 /gateway/userinfo。中央身份网关执行会话查找，并返回包括用户 ID、邮箱、群组、角色和会话元数据在内的身份声明。
区域网关利用这些声明注入可信的身份头信息。下游服务读取这些头信息，并在需要时应用本地授权逻辑。
这使得请求路径保持轻量。普通请求无需进行 OIDC 交换或直接调用身份提供商，仅需一次会话查找和一次可信的网关对网关验证调用即可。
Token 刷新与登出
当访问令牌即将过期时，中心身份网关会使用存储的刷新令牌对其执行刷新操作，并更新会话记录。由于刷新后的状态会写入共享存储，每个区域网关都能看到相同的会话状态。
在登出场景中，中心身份网关会删除会话记录。下次请求到来时，所有区域网关都会检测到会话无效，从而拒绝访问或将用户重定向到登录页。这使得登出操作立即生效，覆盖整个平台。
开发者可复用的内容
NVIDIA 实现背后的具体基础设施是内部的，但这种架构模式是可移植的。外部平台团队可以复用以下组件：
- 一个统一的平台会话所有者
- 一个最小化的验证端点，例如 /gateway/userinfo
- 委托验证责任的无状态区域网关
- 带有显式 TTL 的共享会话存储
- 面向下游服务的标准化身份声明或头部
- 一个能失效共享会话的统一登出路径
- 一次迁移一个网关或服务的渐进式迁移模型
该模式不依赖于专有中间件。可以使用标准的 OIDC 库、Redis 或其他低延迟会话存储，以及在常见 Kubernetes Ingress 或服务网格环境中可用的网关集成来实现。
安全与可靠性护栏
集中会话所有权简化了平台架构，但也使身份网关成为关键服务。采用此模式的团队应从一开始就针对故障容忍、信任边界和可审计性进行设计。
在区域网关与中心身份网关之间使用安全的服务间认证。双向 TLS、工作负载身份或签名内部令牌可以防止不受信任的调用方滥用验证端点。
在注入可信头部之前，先剥离入站身份头部。应用程序应仅信任由网关层添加的头部，而非客户端请求中提供的头部。
会话记录中只存储平台所需的内容。实施短访问令牌生命周期、显式会话 TTL、刷新令牌保护、传输加密，并对会话存储施加适当的访问控制。
要明确地定义故障时的行为。有些平台应当默认拒绝（fail closed），即身份网关或会话存储不可用时拒绝所有请求；另一些平台则可能需要短期的缓存验证来保证可用性。这个决策应当是显式的，并与平台的风险模型保持一致。
记录验证、刷新和登出事件。集中化日志让生成可靠的审计追踪变得更容易，可以清晰展示谁在什么时间访问了哪些服务、会话何时发生变化。
减轻上游身份系统的负载
集中管理会话还有一个不太显眼的好处：减轻上游身份基础设施的压力。
在分布式模型下，每个区域网关都会独立调用身份提供方、令牌密钥存储和授权策略引擎。用户在三个工具之间切换时，平台可能要做三次独立的令牌交换、三条独立的刷新路径和三次策略评估。
而在集中式身份网关的架构下，身份提供方每次登录只需调用一次。区域网关直接对共享会话进行验证，不再重复走 OIDC 流程。令牌刷新由单一服务统一协调，缓存的授权上下文在过期前可以反复使用。
随着集群和工具数量增长，上游身份负载的增长更接近活跃用户数，而不是"用户 × 工具 × 集群"的组合数。在一个工作流中嵌入大量工具的平台里，这种差别会变得非常重要。
支撑统一的 AI 与数据工作流
集中式身份体系还能支撑更高层面的平台能力。
统一的平台外壳可以在一次登录下嵌入多个工具和 AI 助手。每个内嵌应用仍通过网关层验证请求，但用户感受到的是一整个已完成认证的平台。
AI 助手同样受益于这一模型。平台助手通常需要代替用户查询数据、获取元数据、调用工具并汇总结果。有了集中式会话验证，助手可以通过平台会话解析用户身份，并把可信的身份上下文传递给后端工具。
这意味着助手不需要宽泛的服务凭证，也不需要针对每个工具单独登录。它的操作可以直接继承用户的 RBAC 权限范围，让系统更容易推理，也更容易审计。
落地这一模式
要在自己的平台上应用这一架构，首先需要盘点当前的会话创建位置：识别哪些网关负责运行 OIDC 流程、哪些服务直接解析 Token、下游应用信任哪些请求头，以及退出登录的现有机制。 接着，明确中心化的身份协议：- 哪个服务负责会话创建？
- /gateway/userinfo 端点应返回哪些声明？
- 允许哪些网关层注入身份头？
- 平台会话的生命周期应设为多长？
- 如何审计刷新和退出登录操作？
- 若会话存储不可用，应如何处理？
One question
分布式会话状态是一种悄然累积的架构债务。它最初往往表现为重复弹出登录提示，但更大的代价在于认证逻辑重复、退出登录不一致、身份提供商承受不必要的负载，以及用户上下文碎片化。
中心化身份网关通过将会话所有权与请求执行分离来解决根本问题：一个服务统一负责登录、刷新、校验和退出，区域网关则在本地执行访问控制，同时读取共享的会话记录。
在 NVIDIA，该模式将重复登录事件减少了 55%，并为统一的开发者门户及携带委托用户身份的 AI 助手奠定了基础。该方法同样可帮助其他构建联邦式 Kubernetes、数据和 AI 环境的平台团队。
评估该模式是否适用于你的平台，可以从一个问题开始：当前的会话状态存储在哪里？有多少服务在进行本不需要的身份决策？如果答案表明分布式会话状态超出预期，迁移路径就很简单：选定一个网关，用中心化校验调用替换本地会话校验，同时在扩展过程中保持平台其余部分稳定。
Getting started
准备实现类似的身份感知网关架构吗？先从 OAuth2 Proxy 本地环境 入手，体验 OIDC 登录、Cookie 处理和基于 Redis 的会话管理。接着参考 Istio 外部授权示例 定义 Auth Gateway 接口，并通过 OPA Envoy Istio 示例 添加 Rego 策略评估能力。如需一份涵盖 JWT 和 API Key 校验、元数据增强、策略决策以及可信上游头的集成参考实现，请探索 Authorino。
这些项目共同为本文所述的身份、网关和策略层落地提供了实用的起点。