跨联邦 Kubernetes 与 AI 平台的用户身份传播：中央身份网关模式

现代 AI 平台不再是一个登录界面背后的单一应用。用户可能从中央门户开始，打开一个受管控的数据集，启动该数据所在环境中的笔记本，并调用一个会访问另一个集群中服务的助手。工作流感觉是统一的，但身份在每一步都跨越了控制平面和数据平面的边界。这正是传统单点登录（SSO）不再足够的地方。

SSO 在前门验证用户。跨多个集群管理联邦数据或 AI 平台的平台团队仍然需要一种可靠的方式，将用户上下文带入分布式执行环境，而无需将原始令牌交给每个应用、削弱撤销能力，或迫使每个集群重新实现身份提供者逻辑。

这一挑战对 AI 和数据平台尤为重要，因为数据和计算通常保持在它们被产生、存储或管控的地方附近。工作负载可能运行在区域集群、独立的云账户、本地环境或专门的执行平面中。用户仍然期望在笔记本、目录、查询工具、仪表板和 AI 助手之间获得统一的平台体验。

本文描述了一种中央身份网关模式，用于在这些联邦数据平面之间传播用户身份。中央网关拥有平台会话。数据平面网关通过共享 API 验证该会话，并将其转换为下游应用可信的本地身份上下文。该模式使用标准 OpenID Connect（OIDC）、共享会话存储、无状态数据平面网关，以及一个服务可以信任的小型身份验证 API。

在 NVIDIA，这种方法使跨 AWS 和 OCI 中 Kubernetes 集群的内部开发者平台的重复登录事件减少了 55%。更重要的是，它为统一平台外壳、一致的注销、降低上游身份提供者负载，以及能够跨数据平面以委托用户身份行动的 AI 助手，创建了一个可复用的基础。

SSO 结束之处，数据平面身份开始之处

实现细节会因组织而异，但核心设计广泛适用于运行联邦 Kubernetes 环境、多云数据平台、机器学习工作台、内部开发者门户或具有多个已认证工具的 AI 应用栈的平台团队。SSO 为用户提供了一个入口点。

联邦数据平台仍然需要一种方式，将身份带入工作执行所在的平面。一个集群中的笔记本、另一个集群中的目录 API，以及第三个集群中调用查询引擎的助手，都需要同一个答案：用户是谁，他们在这里被允许做什么？

如果没有共享的身份传播模型，会出现几个问题：

• 控制平面身份验证不会自动成为可信的数据平面身份
• 原始令牌转发扩大了凭据暴露，并使推断谁可以在哪里使用哪个令牌变得更加困难
• 每个数据平面网关可能以不同方式与身份提供者集成，导致声明、刷新行为和审计记录不一致
• 注销和撤销可能无法快速传播到每个集群或执行平面
• 新应用继承身份管道，而不是消费标准平台契约

图 1. 之前：没有中央身份网关时，每个 Auth GW 都独立地向身份提供者执行完整的 OIDC 重定向——四个工具、四次登录、四个没有共享状态的隔离会话

对用户来说，症状可能看起来像是重复的登录提示。对平台工程师来说，更深层的问题是分布式令牌传播：在控制平面创建的身份必须转换为每个数据平面中可信、有作用域、可审计的上下文。

图 2. 跨两个区域集群的分布式会话所有权：每个网关维护自己的会话存储，需要按平台分别登录

这种模式适用于少量应用程序，但随着平台扩展，它会产生结构性问题：

• 会话的作用域限定在其创建位置。一个网关颁发的令牌对另一个网关未知，因此用户是按服务而不是按平台进行身份验证
• 注销是本地化的。从一个工具注销可能会在其他地方留下活动会话，既造成用户困惑，也带来安全风险
• 令牌刷新不协调。每个网关都独立地与上游身份提供者协商刷新周期，增加了负载并造成会话状态分歧
• 身份上下文不一致。下游服务通常以不同方式解析令牌或重复身份验证逻辑
• 新服务继承旧复杂性。添加另一个工具通常意味着再次重建相同的身份验证集成

对平台用户来说，症状是重复的登录提示和不一致的行为。对平台工程师来说，更深层的问题是会话所有权分散在那些本应只执行访问控制、而不应拥有身份状态的组件中。

比较两种身份模式

在联邦平台中构建身份有两种常见方式。

第一种模式是分布式会话所有权。每个服务网关拥有自己的登录流程、会话存储、令牌刷新逻辑和注销行为。这使每个集群保持独立，但也意味着身份状态无法在平台上顺畅迁移。

第二种模式是集中式会话所有权。专用的身份网关拥有登录、会话状态、刷新和注销。区域网关仍然保留，但它们将会话验证委托给中央身份网关，并专注于请求执行。

表 1. 分布式与集中式会话所有权在登录、登出、令牌刷新、身份传播和运维扩展方面的比较。

并非每个应用都需要集中式会话所有权。当用户作为同一工作流的一部分跨多个工具、集群或区域操作，并期望这些工具表现得像一个统一平台时，它才变得有价值。

中央身份网关模式

图 3. 使用中央身份网关时，用户只需登录一次。中央身份网关处理初始 OIDC 流程，并将会话存储在 Redis 中。之后每次访问工具都通过轻量级的 /gateway/userinfo 侧调用进行验证——无需重定向，无需重复登录

中央身份网关承担三项职责：

• 会话创建：处理 OIDC 授权码流程并创建平台级会话
• 每请求身份验证：为任何网关或可信服务回答“该用户是谁？”
• 会话生命周期管理：协调整个平台上的令牌刷新和登出

区域认证网关仍然保留。它们仍然执行每个集群的策略、保护本地服务，并将身份注入请求。变化的是会话的存放位置。

中央身份网关不再将会话存储在每个区域网关内部，而是将每个已认证会话写入共享存储（如 Redis）。会话以不透明会话 ID 为键，并与限定于平台域的安全、HTTP-only 浏览器 Cookie 关联。

每次请求时，区域网关调用身份验证端点（如 /gateway/userinfo）。中央身份网关检查会话存储并返回可信身份声明。随后，区域网关在将请求转发给应用之前，注入一组标准化的身份标头。

应用不再需要解析令牌、刷新凭证或直接与身份提供者集成。它们通过一致的接口消费身份信息。

图 4. 会话由中央身份网关持有，区域网关将认证/授权决策委托给身份网关

请求流程

该模式包含三个主要流程：登录、验证和登出。

登录

当用户在没有有效平台会话的情况下访问时，区域网关会将浏览器重定向到中央身份网关。中央网关针对组织的身份提供商运行 OIDC 授权码流程，在服务端交换授权码，将生成的会话以指定的生存时间（TTL）存储到 Redis 中，并设置一个 HTTP-only 会话 Cookie。

该会话 Cookie 在本次会话的剩余时间内成为用户的平台凭证。

逐请求验证

在后续请求中，区域网关将会话 Cookie 发送到 /gateway/userinfo。中央身份网关执行会话查找，并返回身份声明，例如用户 ID、电子邮件、组、角色和会话元数据。

区域网关使用这些声明注入可信的身份标头。下游服务读取这些标头，并在需要时应用本地授权逻辑。

这使请求路径保持轻量。普通请求不需要 OIDC 交换，也不需要直接调用身份提供商。它只需要一次会话查找和一次可信的网关到网关验证调用。

令牌刷新与登出

当访问令牌接近过期时，中央身份网关使用存储的刷新令牌对其进行刷新，并更新会话记录。由于刷新后的状态被写入共享存储，每个区域网关都能观察到相同的会话状态。

对于登出，中央身份网关会删除会话记录。在下一次请求时，每个区域网关都会看到无效会话，并拒绝访问或将用户重定向到登录页面。登出变得即时且覆盖整个平台。

开发者可以复用的内容

NVIDIA 实现背后的具体基础设施是内部的，但该架构模式是可移植的。外部平台团队可以复用以下部分：

• 平台的单一会话所有者
• 一个最小化的验证端点，例如 /gateway/userinfo
• 委托验证的无状态区域网关
• 具有显式 TTL 的共享会话存储
• 为下游服务提供的标准化身份声明或标头
• 使共享会话失效的单一登出路径
• 一次迁移一个网关或服务的迁移模型

该模式不需要专有中间件。它可以使用标准 OIDC 库、Redis 或其他低延迟会话存储，以及常见 Kubernetes Ingress 或服务网格环境中可用的网关集成来实现。

安全与可靠性护栏

集中式会话所有权简化了平台，但也使身份网关成为关键服务。采用此模式的团队应从一开始就针对故障、信任边界和可审计性进行设计。

在区域网关与中央身份网关之间使用安全的服务间认证。双向 TLS、工作负载身份或签名的内部令牌可以防止不受信任的调用方使用验证端点。

在注入可信身份标头之前，先剥离入站身份标头。应用程序应只信任由网关层添加的标头，而不是客户端请求提供的标头。

会话记录中只存储平台所需的内容。应用较短的访问令牌生命周期、显式的会话 TTL、刷新令牌保护、传输中加密，以及围绕会话存储的适当访问控制。

有意识地定义故障行为。某些平台应故障关闭，在身份网关或会话存储不可用时拒绝所有请求。其他平台可能需要短时缓存验证以保持韧性。该决策应明确，并与平台的风险模型保持一致。

记录验证、刷新和登出事件。集中化使生成可靠的审计追踪更容易，展示谁访问了哪些服务以及其会话何时发生变化。

减少上游身份系统的负载

集中式会话所有权一个不太明显的优势是减少上游身份基础设施的负载。

在分布式模型中，每个区域网关可以独立调用身份提供者、令牌密钥存储和授权策略引擎。当用户跨三个工具移动时，平台可能执行三次单独的令牌交换、三条独立的刷新路径和三次策略评估。

使用中央身份网关时，身份提供者每次登录只被调用一次。区域网关针对共享会话进行验证，而不是重复 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。

这些项目共同为实施本文所述的身份、网关和策略层提供了实用的起点。