如何在联邦 Kubernetes 和 AI 平台上携带用户身份

现代 AI 平台不再是单一登录屏幕背后的单一应用。用户可以从中央门户开始，打开受治理的数据集，启动数据所在的 Notebook，然后调用另一个集群中的服务调用助手。工作流统一，但身份识别在每一步都跨越控制平面和数据平面界限。此时，传统的单点登录 (SSO) 不再足够。

SSO 可证明用户位于大门口。跨多个集群管理联合数据或 AI 平台的平台团队仍然需要一种可靠的方法来将该用户上下文带入分布式执行环境，而无需将原始 token 交给每个应用、削弱撤销或强制每个集群重新实现身份提供程序逻辑。

这一挑战对于 AI 和数据平台尤为重要，因为在这些平台中，数据和计算通常会保持在其生成、存储或治理位置附近。工作负载可以在区域集群、单独的云账户、本地环境或专用执行平面中运行。用户仍然期望在各种 Notebook、目录、查询工具、控制面板和 AI 助手中获得统一的平台体验。

本文将介绍一种中央身份网关模式，用于在这些联合数据平面上传播用户身份。中心网关拥有平台会话。数据平面网关通过共享 API 验证该会话，并将其转换为下游应用的可信本地身份上下文。该模式使用标准 OpenID Connect (OIDC) 、共享会话存储、无状态数据平面网关和可信任的小型身份验证 API。

在 NVIDIA，这种方法将跨 AWS 和 OCI 中 Kubernetes 集群的内部开发者平台的重复登录事件减少了 55%。更重要的是，它为统一的平台 shell、一致的注销、较低的上游身份提供商负载以及可以跨数据平面处理委托用户身份的 AI 助手奠定了可重复使用的基础。

SSO 结束和数据平面标识开始的位置

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

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

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

• 控制平面身份验证不会自动成为受信任的数据平面身份
• 原始令牌转发扩大了凭据曝光率，使得难以推理谁可以在哪里使用哪个令牌
• 每个数据平面网关可能以不同的方式与身份提供商集成，从而导致声明、刷新行为和审计记录不一致
• 注销和吊销可能不会在每个集群或执行平面中快速传播
• 新应用继承身份流程，而非使用标准平台合同

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

该模型适用于少数应用，但随着平台的扩展，它会产生结构问题：

• 会话的范围为其创建位置。一个网关发出的令牌对另一个网关来说是未知的，因此用户对每个服务而不是每个平台进行身份验证
• 退出是本地操作。注销某个工具会导致会话在其他地方处于活动状态，从而造成用户混乱并带来安全风险
• 令牌刷新不协调。每个网关都独立地与上游身份提供商协商刷新周期，从而增加负载并创建离散会话状态
• 身份上下文不一致。下游服务通常以不同的方式解析 token 或复制身份验证逻辑
• 新服务继承了过去的复杂性。添加其他工具通常意味着再次重建相同的身份验证集成

对于平台用户而言，症状是重复登录提示和行为不一致。对于平台工程师而言，更深层次的问题是，会话所有权分布在各个组件之间，这些组件应仅用于强制访问，而非拥有身份状态。

比较两种身份模式

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

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

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

表 1. 分布式和集中式会话所有权对比，涵盖登录、注销、令牌刷新、身份传播和操作扩展。

并非每个应用程序都需要集中式会话所有权。当用户在一个工作流中跨多个工具、集群或区域移动，并期望这些工具像单个平台一样运行时，它就变得很有价值。

中央身份网关模式

中央身份网关具有三项职责：

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

区域身份验证网关仍然有效。它们仍然会强制执行每个集群的策略，保护本地服务，并在请求中注入身份信息。改变的地方在于会议的直播位置。

中央身份网关不是在每个区域网关中存储会话，而是将每个经过身份验证的会话写入 Redis 等共享存储。会话由不透明的会话 ID 输入，并与仅适用于 HTTP 的安全浏览器 Cookie 关联，该 Cookie 的作用域为平台域。

对于每个请求，区域网关都会调用身份验证端点，例如/gateway/userinfo。中央身份网关会检查会话存储并返回可信身份声明。然后，区域网关会在将请求转发到应用程序之前，注入一组标准化的标识头。

应用不再需要解析令牌、刷新凭据或直接与身份提供商集成。它们使用来自一致界面的标识。

请求流

该模式有三个主要流程：登录、验证和注销。

登录

当用户未通过有效的平台会话到达时，区域网关会将浏览器重定向到中央身份网关。中央网关针对组织的身份提供程序运行 OIDC 授权代码流，交换授权代码服务器端，将生成的会话以定义的上线时间存储在 Redis 中，并设置纯 HTTP 会话 Cookie。

该会话 Cookie 将成为该会话其余部分的用户平台凭据。

每个请求验证

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

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

这样可以使请求路径保持轻量级。正常请求不需要 OIDC 交换或直接调用身份提供商。它需要会话查找和可信网关到网关验证调用。

令牌刷新和注销

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

对于注销，中央身份网关会删除会话记录。在下一个请求中，每个区域网关都会看到无效会话并拒绝访问或重定向用户以登录。立即在整个平台范围内退出。

开发者可以重用的内容

NVIDIA 实施背后的特定基础架构是内部架构，但架构模式是可移植的。外部平台团队可以重复使用以下组件：

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

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

安全性和可靠性护栏

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

在区域网关和中央身份网关之间使用安全的服务到服务身份验证。双向 TLS、工作负载标识或签名的内部令牌可以阻止未受信任的调用者使用验证端点。

在注入可信头文件之前，先删除入站身份头文件。应用应仅信任网关层添加的报文头，而不应信任客户端请求提供的报文头。

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

刻意定义故障行为。某些平台应关闭失败，如果身份网关或会话存储不可用，则拒绝所有请求。其他系统可能需要进行短期缓存验证以实现弹性。该决策应明确且与平台的风险模型保持一致。

日志验证、刷新和注销事件。通过集中化，可以更轻松地生成可靠的审计追踪，显示谁访问了哪些服务以及会话发生了变化。

减轻上游身份系统的负载

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

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

借助中央身份网关，每次登录只需调用一次身份提供商。区域网关会针对共享会话进行验证，而不是重复 OIDC 流。令牌刷新由一个服务协调，并且缓存的授权上下文可以重复使用，直到过期。

随着集群和工具数量的增加，上游标识负载的规模更接近活跃用户数量，而非用户 – 工具 – 集群组合的数量。在将多个工具嵌入一个工作流的平台中，这种区分变得非常重要。

实现统一的 AI 和数据工作流

集中式身份还支持更高级别的平台功能。

统一的平台 shell 可以在一次登录后嵌入多个工具和助手。每个嵌入式应用程序仍然通过网关层验证请求，但用户会体验到一个经过身份验证的平台。

AI 助手也受益于同样的模型。平台助手通常需要代表用户查询数据、检索元数据、调用工具并汇总结果。通过集中式会话验证，助手可以通过平台会话解析用户身份，并将可信身份上下文传递给后端工具。

这意味着助手不需要广泛的服务凭据或单独的工具登录流程。其操作可以继承用户的 RBAC 范围，使系统更易于推理和审核。

应用模式

要在您自己的平台中应用此架构，请先清点当前创建会话的位置。确定哪些网关运行 OIDC 流，哪些服务直接解析 token，哪些报文指向下游应用程序信任，以及当前注销的工作原理。

然后定义中心合约：

• 哪个服务拥有会话创建？
• /gateway/userinfo 将返回哪些声明？
• 允许哪个网关层注入身份标头？
• 平台会议应持续多长时间？
• 如何审核刷新和注销？
• 如果会话存储不可用，会出现什么情况？

合同明确后，逐步迁移。从一个区域网关或一组相关服务开始。将本地会话验证替换为对中央身份网关的调用。保持面向应用的身份接口稳定，以便下游服务不需要大量重写。

首次迁移成功后，请添加更多网关和工具。其目标并非移除所有区域执行点。目标是让每个执行点读取相同的会话真值来源。

一个问题

分布式会话状态是一种悄无声息地累积的架构借项。它通常首先以重复登录提示的形式出现，但代价更大的是验证逻辑重复、登出不一致、不必要的身份提供程序负载以及用户上下文碎片化。

中央身份网关通过将会话所有权与请求执行分开来解决根本原因。一个服务拥有登录、刷新、验证和注销功能。区域网关在读取共享会话记录时在本地执行访问。

在 NVIDIA，这种模式将重复登录事件减少了 55%，并为统一的开发者门户和具有委托用户身份的 AI 助手奠定了基础。该方法还可以帮助其他平台团队构建联合 Kubernetes、数据和 AI 环境。

要评估这种模式是否适合您的平台，请从一个问题开始：当前会话处于何种状态，以及有多少服务正在做出它们不需要做出的身份决策？如果答案显示的分布式会话状态超出您的预期，则迁移路径很简单：选择一个网关，将本地会话验证替换为集中验证调用，并在您进行扩展的同时保持平台的其余部分稳定。

开始使用

准备好实施类似的身份感知网关架构了吗？从 OAuth2 代理本地环境 开始，探索 OIDC 登录、Cookie 处理和 Redis 支持的会话。接下来，按照 Istio 外部授权示例 定义 Auth 网关接口，并使用 OPA Envoy Istio 示例 添加 Rego 策略评估。如需获取涵盖 CWT 和 API 密钥验证、元数据充实、策略决策和可信上游标头的集成参考，请探索 Authorino。

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