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