现代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：需要在区域网关与中央身份网关之间使用安全的服务间认证，剥离入站身份头信息，只在会话中存储必要信息，明确定义故障时的处理方式，并记录验证、刷新和登出事件以便审计。
