NVIDIA、複数Kubernetes環境でユーザー認証情報を引き継ぐ中央アイデンティティゲートウェイ構成を公開
要点
- 米NVIDIAは、複数のKubernetesクラスタやマルチクラウド環境にまたがるAI・データ基盤で、ユーザーの認証情報を安全に共有・伝播させるアーキテクチャ設計を公開した。
- セッションの管理とリクエストの検証を切り離す「中央アイデンティティゲートウェイ」方式を採用し、データ処理を実行する各環境で個別に認証基盤と連携する手間を省いている。
- AWSおよびOCI上のKubernetesクラスタで稼働する同社の社内開発者プラットフォームにおいて、利用者の再ログイン回数を55%削減した。
- ゲートウェイ間の相互TLSや外部ヘッダーの除去処理といったセキュリティ機構を組み込み、委譲された権限で自律的に動作するAIアシスタントにも対応する。
米NVIDIAは2026年9月3日、同社の公式技術ブログ「NVIDIA Technical Blog」において、分散したKubernetesクラスタや複数のクラウド環境にまたがるAIプラットフォーム向けに、ユーザーのアイデンティティ（識別情報）を横断して伝播させるアーキテクチャパターンを公開した。従来のシングルサインオン（SSO）では対応が難しかった分散実行環境特有の認証課題を解決するもので、同社エンジニアのBhagat Khemchandani氏とRohan Somvanshi氏が解説している。
分散AI基盤において従来のシングルサインオンが直面する課題
現代のAIプラットフォームでは、利用者が中央のWebポータルから統制されたデータセットを選択し、そのデータが存在するクラスタ上でノートブックを立ち上げ、さらに別のクラスタにあるサービスを呼び出すAIアシスタントを活用するといった複合的な作業の流れが一般的になっている。
しかし、1度のログインで各システムを利用可能にする一般的なシングルサインオン（SSO）は、システムの入り口となるフロントドアの認証を証明するにとどまる。全体の管理や指示を担う「制御プレーン」から実際の計算処理や通信を行う「データプレーン」へと作業が移行する際、認証されたユーザーのコンテキストを安全に引き継ぐ仕組みが別途必要になるという。
共通のアイデンティティ伝播モデルが存在しない場合、以下のような問題が発生すると記事では指摘されている。
- 制御プレーンで認証された情報が、データプレーン側で自動的に信頼されたアイデンティティとして扱われない
- 生の認証トークンをそのまま転送すると認証情報が漏洩するリスクが高まり、誰がどのトークンをどこで使用できるかの管理が困難になる
- データプレーンのゲートウェイごとにアイデンティティプロバイダ（IdP）との連携仕様が異なり、クレーム情報や更新動作、監査ログに不整合が生じる
- ユーザーのログアウトや権限の失効処理が、すべてのクラスタや実行プレーンへ即座に反映されにくい
- 新規アプリケーションを追加するたびに個別の認証パイプラインを構築する必要が生じる
セッション管理とリクエスト検証を分離するアーキテクチャ
NVIDIAが提案する「中央アイデンティティゲートウェイ（Central Identity Gateway）」パターンは、セッションの所有権（Session Ownership）とリクエストの検証・適用（Request Enforcement）を明確に分離する設計となっている。
この構成では、中央のゲートウェイがプラットフォーム全体のセッションを一元的に保有する。ユーザー認証情報を安全にやり取りするための標準プロトコルであるOpenID Connect（OIDC）を利用し、明示的な有効期限（TTL）が設定されたRedisベースの共有セッションストアを介してセッション状態を管理する仕組みだ。
一方で、実際のデータ処理環境側に配置されるデータプレーンゲートウェイは、状態を持たないステートレスな構成として配置される。これらのゲートウェイは、最小限の検証用エンドポイントである「/gateway/userinfo」を呼び出してセッションの有効性を確認し、下流の各アプリケーションに対して標準化された信頼できるアイデンティティヘッダーを注入してリクエストを中継する。
この分離モデルにより、トークンの更新やログアウト処理がプラットフォーム全体で一元調整される。さらに、上流のIdPに対する負荷が「ユーザー数×利用ツール数」ではなく「アクティブユーザー数」に応じてスケールするようになり、システム全体の負荷軽減にも寄与するという。
社内環境での導入成果と55%の再ログイン削減
NVIDIA社内では、Amazon Web Services（AWS）およびOracle Cloud Infrastructure（OCI）上にまたがる複数のKubernetesクラスタで稼働する開発者プラットフォームに本アーキテクチャを導入した。その結果、開発者が直面していた重複したログイン試行や再ログインのイベントを55%削減できたと報告されている。
ログイン回数の削減にとどまらず、統一されたプラットフォーム画面（シェル）の提供、確実なログアウト処理、IdPの負荷軽減を実現した。また、データプレーンを横断してユーザーから委譲された権限のもとでサービスを呼び出すAIアシスタントの運用基盤としても機能していると説明されている。
セキュリティの保護対策と活用ツール
分散環境での安全性を確保するため、本パターンでは複数のセキュリティガードレール（防御策）が定義されている。
ゲートウェイ間の通信には、クライアントとサーバー双方が互いに証明書で認証し合う相互TLS（mTLS）や、コンテナやプロセス自体に認証情報を付与するワークロードアイデンティティが適用される。また、下流サービスに向けて信頼できるヘッダーを注入する前段階で、外部から送信されてくる不正なアイデンティティヘッダーを確実に除去（ストリップ）する処理が必須とされている。セッションストアが一時的に利用不能となった際のフェイルセーフ動作についても、あらかじめ明確に定めておく必要があるという。
記事の最後では、このアーキテクチャを検証・構築するための参考リソースとして、OIDCログインやCookie処理を試せる「OAuth2 Proxy」のローカル環境、認可インターフェースを定義する「Istio external authorization」のサンプル、Rego言語でポリシーを評価する「OPA（Open Policy Agent）Envoy Istio」のプラグイン、JWTやAPIキーの検証およびポリシー判定を包括的に扱う「Authorino」のリファレンスが紹介されている。