行业动态
developer.nvidia.com ·
@Elizabeth Goodman
如何在联邦Kubernetes和AI平台间传递用户身份
现代AI平台不再局限于单一应用和登录界面。用户可能从中央门户开始，访问受管数据集、启动笔记本等。本文探讨如何在联邦Kubernetes和AI平台环境中安全传递用户身份，确保一致性和安全性。
AI推荐理由 NVIDIA技术博客介绍如何在联邦Kubernetes和AI平台间传递用户身份，对开发者和平台架构师有参考价值。内容具体，但摘要不完整，可能缺乏深度。
65
正文
AI平台/部署
如何在联邦Kubernetes和AI平台间传递用户身份
2026年9月3日
作者：Bhagat Khemchandani 和 Rohan Somvanshi
喜欢
L
T
F
R
E
AI生成摘要
一种中央身份网关模式将会话所有权与请求执行分离，允许区域网关通过共享会话存储验证用户身份，而不是管理独立的OIDC流程。
在NVIDIA，这种方法将跨AWS和OCI中Kubernetes集群的内部开发者平台的重复登录事件减少了55%，同时实现了统一平台外壳和具有委派用户身份的AI助手。
该架构使用标准OpenID Connect、一个最小的/gateway/userinfo验证端点、无状态区域网关以及一个带有显式TTL的共享Redis支持的会话存储。
集中式会话所有权协调平台范围内的令牌刷新和注销，减少上游身份提供商负载，使其随活跃用户而非用户-工具组合扩展，并为下游服务标准化身份头。
安全护栏包括网关之间的双向TLS或工作负载身份，在注入可信头之前剥离入站身份头，并为会话存储不可用定义明确的失败行为。
后续步骤
探索OAuth2 Proxy本地环境，尝试OIDC登录、Cookie处理和Redis支持的会话。
遵循Istio外部授权示例来定义Auth Gateway接口。
使用OPA Envoy Istio示例添加Rego策略评估。
查看Authorino，了解涵盖JWT和API密钥验证、元数据丰富、策略决策和可信上游头的集成参考。
由NVIDIA Nemotron提供支持。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. 跨两个区域集群的分布式会话所有权：每个网关维护自己的会话存储，要求每个平台单独登录
该模型适用于少量应用程序，但随着平台扩展会产生结构性问题：
会话仅限于创建它们的位置。一个网关颁发的令牌对另一个网关未知，因此用户按服务进行身份验证
而不是按平台进行身份验证
注销是局部的。退出一个工具可能会在其他地方留下活动会话，造成用户困惑和安全风险
令牌刷新不协调。每个网关独立与上游身份提供商协商刷新周期，增加负载并产生不同的会话状态
身份上下文不一致。下游服务通常以不同方式解析令牌或重复认证逻辑
新服务继承旧复杂性。添加另一个工具通常意味着再次重建相同的认证集成
对于平台用户来说，症状是重复的登录提示和不一致的行为。对于平台工程师来说，更深层次的问题是会话所有权分布在应该只执行访问而不是拥有身份状态的组件中。
比较两种身份模式
在联邦平台中构建身份有两种常见方式。
第一种模式是分布式会话所有权。每个服务网关拥有自己的登录流程、会话存储、令牌刷新逻辑和注销行为。这使每个集群保持独立，但也意味着身份状态不能干净地跨平台移动。
第二种模式是集中式会话所有权。一个专用的身份网关拥有登录、会话状态、刷新和注销。区域网关仍然存在，但它们将会话验证委托给中央身份网关，并专注于请求执行。
设计选择 | 分布式会话所有权 | 集中式会话所有权
登录体验 | 用户可能每个工具或网关登录一次 | 用户每个平台会话登录一次
注销行为 | 特定于服务或集群 | 通过一个会话记录实现平台范围
令牌刷新 | 每个网关独立重复 | 由中央网关协调
上游IdP负载 | 随用户、工具和集群扩展 | 主要随活跃用户扩展
下游身份 | 经常重复或不一致 | 通过可信头或声明标准化
运营模式 | 起初简单，规模扩大后更难 | 需要中央服务，新工具更简单
表1. 分布式和集中式会话所有权在登录、注销、令牌刷新、身份传播和运营扩展方面的比较。
集中式会话所有权并非每个应用程序都需要。当用户在一个工作流中跨多个工具、集群或区域移动，并期望这些工具表现得像一个单一平台时，它就变得有价值。
中央身份网关模式
图3. 使用中央身份网关，用户登录一次。中央身份网关处理初始OIDC流程并将会话存储在Redis中。每次后续工具访问都通过轻量级/gateway/userinfo侧调用进行验证——无需重定向，无需重复登录
中央身份网关拥有三个职责：
会话创建：处理OIDC授权码流程并创建平台范围的会话
每请求身份验证：为任何网关或可信服务回答“这个用户是谁？”
会话生命周期管理：协调平台范围内的令牌刷新和注销
区域认证网关仍然存在。它们仍然执行每集群策略、保护本地服务并将身份注入请求。改变的是会话的存储位置。
中央身份网关不是将会话存储在每个区域网关内部，而是将每个认证会话写入共享存储（如Redis）。会话以不透明会话ID为键，并与安全、仅HTTP的浏览器Cookie关联，该Cookie限定在平台域内。
在每个请求上，区域网关调用身份验证端点，如/gateway/userinfo。中央身份网关检查会话存储并返回可信的身份声明。区域网关然后在将请求转发到应用程序之前注入一组标准化的身份头。
应用程序不再需要解析令牌、刷新凭证或直接与身份提供商集成。它们从一致的接口消费身份。
图4. 会话由中央身份网关拥有，区域网关将AuthN/Z决策委托给身份网关
请求流程
该模式有三个主要流程：登录、验证和注销。
登录
当用户没有有效平台会话到达时，区域网关将浏览器重定向到中央身份网关。中央网关针对组织的身份提供商运行OIDC授权码流程，在服务器端交换授权码，将生成的会话存储在Redis中并带有定义的时间到活，并设置仅HTTP会话Cookie。
该会话Cookie成为用户在该会话剩余时间内的平台凭证。
每请求验证
在后续请求中，区域网关将会话Cookie发送到/gateway/userinfo。中央身份网关执行会话查找并返回身份声明，如用户ID、电子邮件、组、角色和会话元数据。
区域网关使用这些声明注入可信身份头。下游服务读取头并在需要时应用本地授权逻辑。
这保持了请求路径的轻量。正常请求不需要OIDC交换或直接调用身份提供商。它需要会话查找和可信的网关到网关验证调用。
令牌刷新和注销
当访问令牌接近过期时，中央身份网关使用存储的刷新令牌刷新它并更新会话记录。因为刷新状态写入共享存储，每个区域网关观察到相同的会话状态。
对于注销，中央身份网关删除会话记录。在下一次请求时，每个区域网关看到无效会话并拒绝访问或将用户重定向到登录。注销变得即时且平台范围。
开发者可以重用哪些内容
NVIDIA i背后的具体基础设施
实现是内部的，但架构模式是可移植的。外部平台团队可以重用以下部分：
平台的单一会话所有者
最小的验证端点，如/gateway/userinfo
委托验证的无状态区域网关
具有显式TTL的共享会话存储
用于下游服务的标准化身份声明或头
使共享会话失效的单一注销路径
一次移动一个网关或服务的迁移模型
该模式不需要专有中间件。它可以使用标准OIDC库、Redis或另一个低延迟会话存储以及常见Kubernetes入口或服务网格环境中可用的网关集成来实现。
安全性和可靠性护栏
集中会话所有权简化了平台，但也使身份网关成为关键服务。采用此模式的团队应从一开始就为故障、信任边界和可审计性进行设计。
在区域网关和中央身份网关之间使用安全的服务到服务认证。双向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。
这些项目共同为实施本文所述的身份、网关和策略层提供了实用的起点。
喜欢
标签
AI平台/部署 | 数据中心/云 | 开发者工具与技术 | HPC/科学计算 | 通用 | AI企业 | 中级技术 | 教程 | AI平台 | 云服务 | 基础设施 | Kubernetes | 软件定义数据中心
关于作者
关于Bhagat Khemchandani
Bhagat Khemchandani是NVIDIA的高级平台工程师，致力于大规模AI和数据系统背后的平台架构。他们的工作涵盖分析和机器学习工作流中的身份、访问和产品体验，专注于使复杂的分布式系统对用户来说更无缝、可靠和直观。他们帮助推动了平台现代化工作，提高了可靠性，简化了访问，并为统一的、AI驱动的用户体验奠定了更坚实的基础。
查看Bhagat Khemchandani的所有帖子
关于Rohan Somvanshi
Rohan Somvanshi是NVIDIA的高级软件工程师，帮助设计大规模AI和数据平台的安全、可扩展基础。他们的工作涵盖安全访问、GPU工作负载编排和多云平台架构，提供可重用的功能，加强数据治理，同时改善开发者体验、效率、可靠性和平台可扩展性。通过跨职能技术领导和指导，他们帮助团队采用一致的平台模式，并高效、安全地将复杂的分布式工作负载从开发转移到生产。
查看Rohan Somvanshi的所有帖子
查看原文（中文正文为 AI 翻译）
AI Platforms/Deployment
How to Carry User Identity Across Federated Kubernetes and AI Platforms
Sep 03, 2026
By Bhagat Khemchandani and Rohan Somvanshi
Like
L
T
F
R
E
AI-Generated Summary
A central identity gateway pattern separates session ownership from request enforcement, allowing regional gateways to validate user identity through a shared session store instead of managing independent OIDC flows.
At NVIDIA, this approach reduced repeated login events by 55% across internal developer platforms spanning Kubernetes clusters in AWS and OCI while enabling unified platform shells and AI assistants with delegated user identity.
The architecture uses standard OpenID Connect, a minimal /gateway/userinfo validation endpoint, stateless regional gateways, and a shared Redis-backed session store with explicit TTLs.
Centralized session ownership coordinates token refresh and logout platform-wide, reduces upstream identity-provider load to scale with active users rather than user-tool combinations, and standardizes identity headers for downstream services.
Security guardrails include mutual TLS or workload identity between gateways, stripping inbound identity headers before injecting trusted ones, and defining explicit failure behavior for session-store unavailability.
Next Steps
Explore the OAuth2 Proxy local environment to experiment with OIDC login, cookie handling, and Redis-backed sessions.
Follow the Istio external authorization sample to define the Auth Gateway interface.
Add Rego policy evaluation with the OPA Envoy Istio example.
Review Authorino for an integrated reference covering JWT and API-key validation, metadata enrichment, policy decisions, and trusted upstream headers.
Powered by NVIDIA Nemotron. AI-generated content may summarize information incompletely. Verify important information. Learn more
Modern AI platforms are no longer a single application behind one login screen. A user may start in a central portal, open a governed dataset, launch a notebook where that data resides, and invoke an assistant that calls services in another cluster. The workflow feels unified, but identity crosses control-plane and data-plane boundaries at every step. That is where conventional single sign-on (SSO) stops being enough.
SSO proves the user at the front door. Platform teams who manage a federated data or AI platform across multiple clusters still need a reliable way to carry that user context into distributed execution environments without handing raw tokens to every application, weakening revocation, or forcing each cluster to reimplement identity-provider logic.
This challenge is especially important for AI and data platforms, where data and compute often stay close to where they are produced, stored, or governed. Workloads may run in regional clusters, separate cloud accounts, on-premises environments, or specialized execution planes. Users still expect one platform experience across notebooks, catalogs, query tools, dashboards, and AI assistants.
This post describes a central identity gateway pattern for propagating user identity across those federated data planes. A central gateway owns the platform session. Data-plane gateways validate that session through a shared API and convert it into trusted local identity context for downstream applications. The pattern uses standard OpenID Connect (OIDC), a shared session store, stateless data-plane gateways, and a small identity-validation API that services can trust.
At NVIDIA, this approach reduced repeated login events by 55% across internal developer platforms spanning Kubernetes clusters in AWS and OCI. More importantly, it created a reusable foundation for unified platform shells, consistent logout, lower upstream identity-provider load, and AI assistants that can act with delegated user identity across data planes.
Where SSO ends and data-plane identity begins
The implementation details will vary by organization, but the core design is broadly applicable to platform teams running federated Kubernetes environments, multi-cloud data platforms, machine learning workbenches, internal developer portals, or AI application stacks with multiple authenticated tools. SSO gives users one entry point.
Federated data platforms still need a way to carry identity into the planes where work executes. A notebook in one cluster, a catalog API in another, and an assistant calling a query engine in a third all need the same answer: Who is the user, and what are they allowed to do here?
Without a shared identity propagation model, several problems appear:
Control-plane authentication doesn’t automatically become trusted data-plane identity
Raw token forwarding expands credential exposure and makes it harder to reason about who can use which token where
Each data-plane gateway may integrate with the identity provider differently, creating inconsistent claims, refresh behavior, and audit records
Logout and revocation may not propagate quickly across every cluster or execution plane
New applications inherit identity plumbing instead of consuming a standard platform contract
Figure 1. Before: Without a Central Identity Gateway, each Auth GW performs a full OIDC redirect to the Identity Provider independently — four tools, four logins, four isolated sessions with no shared state
For users, the symptom may look like repeated login prompts. For platform engineers, the deeper issue is distributed token propagation: identity created at the control plane must be transformed into trusted, scoped, auditable context at each data plane.
Figure 2. Distributed session ownership across two regional clusters: each gateway maintains its own session store, requiring separate logins per platform
That model works for a small number of applications, but it creates structural problems as the platform expands:
Sessions are scoped to where they were created. A token issued by one gateway is unknown to another, so users authenticate per service instead of per platform
Logout is local. Signing out of one tool can leave active sessions elsewhere, creating both user confusion and security risk
Token refresh is uncoordinated. Every gateway independently negotiates refresh cycles with the upstream identity provider, increasing load and creating divergent session states
Identity context is inconsistent. Downstream services often parse tokens differently or duplicate authentication logic
New services inherit old complexity. Adding another tool usually means rebuilding the same auth integration again
For platform users, the symptoms are repeated login prompts and inconsistent behavior. For platform engineers, the deeper issue is that session ownership is distributed across components that should only be enforcing access, not owning identity state.
Comparing two identity patterns
There are two common ways to structure identity in a federated platform.
The first pattern is distributed session ownership. Each service gateway owns its own login flow, session store, token refresh logic, and logout behavior. This keeps each cluster independent, but it also means the identity state does not move cleanly across the platform.
The second pattern is centralized session ownership. A dedicated identity gateway owns login, session state, refresh, and logout. Regional gateways remain in place, but they delegate session validation to the central identity gateway and focus on request enforcement.
Design choiceDistributed session ownershipCentralized session ownershipLogin experienceUsers may log in once per tool or gatewayUsers log in once per platform sessionLogout behaviorLocal to a service or clusterPlatform-wide through one session recordToken refreshRepeated independently by each gatewayCoordinated by the central gatewayUpstream IdP loadScales with users, tools, and clustersScales primarily with active usersDownstream identityOften duplicated or inconsistentStandardized through trusted headers or claimsOperational modelSimple at first, harder at scaleRequires central service, simpler for new tools
Table 1. Comparison of distributed and centralized session ownership across login, logout, token refresh, identity propagation, and operational scaling.
Centralized session ownership is not required for every application. It becomes valuable when users move across multiple tools, clusters, or regions as part of one workflow and expect those tools to behave like a single platform.
The central identity gateway pattern
Figure 3. With Central Identity Gateway, the user logs in once. The Central Identity GW handles the initial OIDC flow and stores the session in Redis. Every subsequent tool access is validated via a lightweight /gateway/userinfo side-call — no redirect, no repeat login
The central identity gateway owns three responsibilities:
Session creation: handling the OIDC authorization code flow and creating a platform-wide session
Per-request identity validation: answering “who is this user?” for any gateway or trusted service
Session lifecycle management: coordinating token refresh and logout across the platform
Regional authentication gateways remain in place. They still enforce per-cluster policy, protect local services, and inject identity into requests. What changes is where sessions live.
Instead of storing sessions inside each regional gateway, the central identity gateway writes every authenticated session to a shared store such as Redis. The session is keyed by an opaque session ID and associated with a secure, HTTP-only browser cookie scoped to the platform domain.
On each request, a regional gateway calls an identity-validation endpoint such as /gateway/userinfo. The central identity gateway checks the session store and returns trusted identity claims. The regional gateway then injects a standardized set of identity headers before forwarding the request to the application.
Applications no longer need to parse tokens, refresh credentials, or integrate directly with the identity provider. They consume identity from a consistent interface.
Figure 4. Session is owned by Central Identity Gateway, Regional gateways delegate the AuthN/Z decision to identity gateway
Request flow
The pattern has three primary flows: login, validation, and logout.
Login
When a user arrives without a valid platform session, the regional gateway redirects the browser to the central identity gateway. The central gateway runs the OIDC authorization code flow against the organization’s identity provider, exchanges the authorization code server-side, stores the resulting session in Redis with a defined time-to-live, and sets an HTTP-only session cookie.
That session cookie becomes the user’s platform credential for the rest of the session.
Per-request validation
On subsequent requests, the regional gateway sends the session cookie to /gateway/userinfo. The central identity gateway performs a session lookup and returns identity claims such as user ID, email, groups, roles, and session metadata.
The regional gateway uses those claims to inject trusted identity headers. Downstream services read the headers and apply local authorization logic where needed.
This keeps the request path lightweight. A normal request does not require an OIDC exchange or a direct call to the identity provider. It requires a session lookup and a trusted gateway-to-gateway validation call.
Token refresh and logout
When an access token nears expiry, the central identity gateway refreshes it using the stored refresh token and updates the session record. Because the refreshed state is written to the shared store, every regional gateway observes the same session state.
For logout, the central identity gateway deletes the session record. On the next request, every regional gateway sees an invalid session and denies access or redirects the user to login. Logout becomes immediate and platform-wide.
What developers can reuse
The specific infrastructure behind the NVIDIA implementation is internal, but the architecture pattern is portable. External platform teams can reuse the following pieces:
A single session owner for the platform
A minimal validation endpoint, such as /gateway/userinfo
Stateless regional gateways that delegate validation
A shared session store with explicit TTLs
Standardized identity claims or headers for downstream services
A single logout path that invalidates the shared session
A migration model that moves one gateway or service at a time
The pattern doesn’t require proprietary middleware. It can be implemented with standard OIDC libraries, Redis or another low-latency session store, and gateway integrations available in common Kubernetes ingress or service-mesh environments.
Security and reliability guardrails
Centralizing session ownership simplifies the platform, but it also makes the identity gateway a critical service. Teams adopting this pattern should design for failure, trust boundaries, and auditability from the beginning.
Use secure service-to-service authentication between regional gateways and the central identity gateway. Mutual TLS, workload identity, or signed internal tokens can prevent untrusted callers from using the validation endpoint.
Strip inbound identity headers before injecting trusted ones. Applications should only trust headers added by the gateway layer, not headers provided by a client request.
Store only what the platform needs in the session record. Apply short access-token lifetimes, explicit session TTLs, refresh-token protection, encryption in transit, and appropriate access controls around the session store.
Define failure behavior deliberately. Some platforms should fail closed, denying all requests if the identity gateway or session store is unavailable. Others may need short-lived cached validation for resilience. That decision should be explicit and aligned with the platform’s risk model.
Log validation, refresh, and logout events. Centralization makes it easier to produce a reliable audit trail showing who accessed which services and when their session changed.
Reducing load on upstream identity systems
One less obvious benefit of centralized session ownership is reduced load on upstream identity infrastructure.
In a distributed model, each regional gateway can call the identity provider, token secret store, and authorization policy engine independently. When a user moves across three tools, the platform may perform three separate token exchanges, three independent refresh paths, and three policy evaluations.
With a central identity gateway, the identity provider is called once per login. Regional gateways validate against the shared session instead of repeating the OIDC flow. Token refresh is coordinated by one service, and cached authorization context can be reused until it expires.
As the number of clusters and tools grows, upstream identity load scales closer to the number of active users rather than the number of user-tool-cluster combinations. This distinction becomes important in platforms that embed many tools into one workflow.
Enabling unified AI and data workflows
Centralized identity also enables higher-level platform capabilities.
A unified platform shell can embed multiple tools, and assistants behind one login. Each embedded application still validates requests through the gateway layer, but the user experiences a single authenticated platform.
AI assistants benefit from the same model. A platform assistant often needs to query data, retrieve metadata, call tools, and summarize results on behalf of the user. With centralized session validation, the assistant can resolve the user’s identity through the platform session and pass trusted identity context to backend tools.
That means the assistant does not need broad service credentials or separate per-tool login flows. Its actions can inherit the user’s RBAC scope, making the system easier to reason about and easier to audit.
Applying the pattern
To apply this architecture in your own platform, start by inventorying where sessions are created today. Identify which gateways run OIDC flows, which services parse tokens directly, which headers downstream applications trust, and how logout currently works.
Then define the central contract:
Which service owns session creation?
What claims will /gateway/userinfo return?
Which gateway layer is allowed to inject identity headers?
How long should platform sessions live?
How will refresh and logout be audited?
What happens if the session store is unavailable?
After the contract is clear, migrate incrementally. Start with one regional gateway or one group of related services. Replace local session validation with a call to the central identity gateway. Keep the application-facing identity interface stable so downstream services do not need large rewrites.
Once the first migration is working, add more gateways and tools. The goal is not to remove every regional enforcement point. The goal is to make every enforcement point read from the same source of session truth.
One question
Distributed session state is an architectural debt that accumulates quietly. It often appears first as repeated login prompts, but the larger cost is duplicated auth logic, inconsistent logout, unnecessary identity-provider load, and fragmented user context.
A central identity gateway addresses the root cause by separating session ownership from request enforcement. One service owns login, refresh, validation, and logout. Regional gateways enforce access locally while reading from a shared session record.
At NVIDIA, this pattern reduced repeated login events by 55% and created a foundation for unified developer portals and AI assistants with delegated user identity. The same approach can help other platform teams building federated Kubernetes, data, and AI environments.
To evaluate whether this pattern fits your platform, start with one question: Where does session state live today, and how many services are making identity decisions they should not need to make? If the answer reveals more distributed session state than you’d like, the migration path is straightforward: pick one gateway, replace local session validation with a central validation call, and keep the rest of the platform stable while you expand from there.
Getting started
Ready to implement a similar identity-aware gateway architecture? Begin with the OAuth2 Proxy local environment to explore OIDC login, cookie handling, and Redis-backed sessions. Next, follow the Istio external authorization sample to define the Auth Gateway interface, and add Rego policy evaluation with the OPA Envoy Istio example. For an integrated reference covering JWT and API-key validation, metadata enrichment, policy decisions, and trusted upstream headers, explore Authorino.
Together, these projects provide practical starting points for implementing the identity, gateway, and policy layers described in this post.
Like
Tags
AI Platforms/Deployment | Data Center / Cloud | Developer Tools & Techniques | HPC / Scientific Computing | General | AI Enterprise | Intermediate Technical | Tutorial | AI Platform | Cloud Services | Infrastructure | Kubernetes | Software-Defined Data Center
About the Authors
About Bhagat Khemchandani
Bhagat Khemchandani is a senior platform Engineer at NVIDIA who works on the platform architecture behind large-scale AI and data systems. Their work spans identity, access, and product experience across analytics and machine learning workflows, with a focus on making complex distributed systems feel more seamless, reliable, and intuitive for users. They have helped drive platform modernization efforts that improved reliability, simplified access, and created a stronger foundation for unified, AI-enabled user experiences.
View all posts by Bhagat Khemchandani
About Rohan Somvanshi
Rohan Somvanshi is a senior software engineer at NVIDIA who helps design secure, scalable foundations for large-scale AI and data platforms. Their work spans secure access, GPU workload orchestration, and multi-cloud platform architecture, delivering reusable capabilities that strengthen data governance while improving developer experience, efficiency, reliability, and scalability across the platform. Through cross-functional technical leadership and mentorship, they help teams adopt consistent platform patterns and move complex distributed workloads from development to production efficiently and securely.
View all posts by Rohan Somvanshi