Carrying User Identity Across Federated Kubernetes and AI Platforms

Carrying User Identity Across Federated Kubernetes and AI Platforms Standard single sign-on falls short in federated AI and data platforms where workflows cross multiple clusters, clouds, and execution planes. NVIDIA presents a central identity gateway pattern that decouples platform session ownership from local request enforcement. At NVIDIA, the central identity gateway pattern reduced repeated login events by 55% across internal developer platforms spanning AWS and OCI Kubernetes clusters. Distributed session ownership causes repeated logins, localized logout risks, uncoordinated token refreshes, and unnecessary load on upstream identity providers. A central identity gateway manages OIDC flows, platform-wide sessions in a shared store like Redis, token refreshes, and instant logout, while regional gateways validate requests via a lightweight API. Centralized identity allows AI assistants to act with delegated user identity and inherit role-based access control without needing broad service credentials. Limitations of Distributed Session Ownership When workloads span regional clusters, clouds, and on-premises environments, distributed session ownership forces each gateway to run independent OIDC flows and maintain isolated session stores. This results in repeated login prompts, localized sign-outs that leave sessions active elsewhere, inconsistent token parsing, and uncoordinated token refreshes that inflate upstream identity-provider load. The Central Identity Gateway Pattern The proposed architecture centralizes session creation, lifecycle management, and per-request validation. An initial OIDC authorization flow stores the session in a shared store such as Redis and issues an HTTP-only platform cookie. Regional gateways remain stateless, calling a lightweight endpoint like /gateway/userinfo to validate sessions and inject trusted headers into downstream requests, eliminating raw token forwarding. Operational Benefits and AI Workflows Centralizing session ownership aligns identity provider load with the number of active users rather than multiplicative user-tool-cluster combinations. Furthermore, it enables unified portal shells and lets AI assistants inherit the user's role-based access control to query back-end tools without requiring separate logins or broad service credentials. Security Guardrails and Migration Adopting teams must enforce secure service-to-service communication using mutual TLS or workload identity, strip untrusted inbound identity headers, define explicit failure behaviors, and protect session stores with time-to-live settings. Migration can proceed incrementally by moving one regional gateway or service group at a time to read from the central session truth.

NVIDIA提出中央身份网关模式：实现联邦Kubernetes与AI平台的跨集群用户身份传递 现代AI与数据平台常跨越多个Kubernetes集群和云环境，传统单点登录无法将用户身份可靠传递至分布式执行平面。NVIDIA提出了一种中央身份网关架构，通过将控制平面的会话所有权与数据平面的请求执行解耦，有效解决了重复登录、注销不同步以及上游IdP负载过高的问题。 在NVIDIA内部跨AWS与OCI集群的开发者平台中，该方案将重复登录事件减少了55%。 架构将职责划分为中央身份网关负责全局会话与生命周期管理，无状态区域网关负责向应用注入受信任身份头。 会话集中存储于共享存储（如Redis）并通过不透明Cookie关联，每次请求经由轻量验证API确认身份，避免了各组件直接解析原生Token。 上游身份提供商（IdP）的负载从随用户、工具及集群组合扩展，降为仅随活跃用户数扩展。 分布式会话所有权的局限性 在传统的分布式模式下，每个数据平面网关独立运行OIDC流程并拥有本地会话，导致多工具间频繁重复登录、注销仅在本地生效、令牌刷新无序并造成上游IdP高负载。此外，直接转发原始Token会扩大凭证泄露风险，下游服务重复解析身份也增加了架构脆弱性。 中央身份网关架构与核心流程 该模式采用集中的身份网关处理OIDC授权码流，并将包含生命周期的会话存入Redis等共享存储，向浏览器写入平台域名的HTTP-only Cookie。各区域网关在收到请求时，调用如/gateway/userinfo的轻量API进行校验，并在剥离客户端原有身份头后注入标准化的可信身份标头。令牌刷新与注销均在中央统一处理，一旦中央删除会话记录，全平台即刻同步失效。 赋能AI工作流与安全实践 该模式使得AI助手在跨集群查询数据或调用后端服务时，可以直接继承用户上下文和RBAC权限，降低鉴权复杂度并提供可靠审计。在实施安全防范时，需在网关间部署双向TLS或工作负载凭证，审慎定义故障响应机制（如失败闭合或短时缓存验证），并建议团队通过渐进式迁移逐步将区域网关接入中央验证API。

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 choice Distributed session ownership Centralized session ownership Login experience Users may log in once per tool or gateway Users log in once per platform session Logout behavior Local to a service or cluster Platform-wide through one session record Token refresh Repeated independently by each gateway Coordinated by the central gateway Upstream IdP load Scales with users, tools, and clusters Scales primarily with active users Downstream identity Often duplicated or inconsistent Standardized through trusted headers or claims Operational model Simple at first, harder at scale Requires 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.