連合 Kubernetes と AI プラットフォーム間でのユーザーアイデンティティ継承手法

現代の AI プラットフォームは、もはや単一のログイン画面の背後にあるアプリケーションではありません。ユーザーは中央ポータルから始まり、管理されたデータセットを開き、そのデータが存在するノートブックを起動し、別のクラスター内のサービスを呼び出すアシスタントを呼び出します。このワークフローは一貫して感じられますが、アイデンティティは各ステップで制御プレーンとデータプレーンの境界を越えて移動します。ここで従来のシングルサインオン（SSO）では不十分となることがあります。

SSO はフロントドアでのユーザー認証には有効です。しかし、複数のクラスターにまたがる連合型データや AI プラットフォームを管理するプラットフォームチームにとって、生トークンを各アプリケーションに手渡して権限剥奪の柔軟性を損なったり、各クラスターでアイデンティティプロバイダーロジックを再実装させたりすることなく、そのユーザーコンテキストを分散実行環境へ確実に引き継ぐ手段が必要です。

この課題は、データと計算リソースが生成・保存・管理される場所の近くに留まることが多い AI やデータプラットフォームにおいて特に重要です。ワークロードは地域クラスター、別々のクラウドアカウント、オンプレミス環境、あるいは専用の実行プレーンで実行されることがあります。ユーザーは依然として、ノートブック、カタログ、クエリツール、ダッシュボード、AI アシスタントにわたって一貫したプラットフォーム体験を求めています。

本稿では、連合化されたデータプレーン間でユーザーのアイデンティティを伝播させるための「中央集権型アイデンティティゲートウェイ」のパターンについて解説します。

このパターンでは、プラットフォームセッションを管理する中央ゲートウェイが中核となります。データプレーン側のゲートウェイは共有 API を通じてそのセッションを検証し、下流のアプリケーション向けに信頼できるローカルなアイデンティティコンテキストに変換します。実装には標準的な OpenID Connect (OIDC) や共有セッションストアを利用し、ステートレスなデータプレーンゲートウェイと、サービス側が信頼できる軽量なアイデンティティ検証 API を組み合わせます。

NVIDIA での実装では、AWS と OCI にまたがる内部開発プラットフォーム全体で、重複するログインイベントを 55% 削減することに成功しました。さらに重要なのは、統一されたプラットフォームシェルや一貫したログアウト機能を実現し、上位のアイデンティティプロバイダへの負荷を軽減できる基盤が構築できた点です。これにより、データプレーンを超えて委任されたユーザー権限で動作する AI アシスタントも可能になりました。

SSO の境界とデータプレーンにおけるアイデンティティの開始点

実装の詳細は組織によって異なりますが、このコアとなる設計思想は、連合化された Kubernetes 環境やマルチクラウドデータプラットフォーム、機械学習ワークベンチ、内部開発ポータル、あるいは複数の認証ツールを備えた AI アプリケーションスタックを運用するプラットフォームチームにとって広く適用可能です。SSO（シングルサインオン）は、ユーザーにとって単一のエントリーポイントを提供します。

連合データプラットフォームでは、依然としてワークが実行される領域へユーザーの身元情報を引き継ぐ仕組みが必要です。あるクラスター内のノートブック、別のクラスターのカタログ API、さらに別の場所でクエリエンジンを呼び出すアシスタントなど、すべてが同じ問いに答えなければなりません。「このユーザーは誰か？ここで何ができるのか？」

共有された身元情報伝播モデルがない場合、いくつかの問題が発生します。

• コントロールプレーンでの認証が自動的にデータプレーンの信頼できる身元情報にはならない
• トークンの生きた転送により認証情報の露出範囲が広がり、「どのトークンを誰がどこで使えるか」を把握することが難しくなる
• 各データプレーンゲートウェイが異なる方法で ID プロバイダーと統合するため、主張内容やリフレッシュ動作、監査記録に不整合が生じる
• ログアウトや権限剥奪がすべてのクラスターや実行領域へ迅速に伝播しない
• 新しいアプリケーションは標準的なプラットフォーム契約を利用するのではなく、既存の身元情報処理の仕組みを継承してしまう

図 1（以前の状態）：中央の ID ゲートウェイがない場合、各認証ゲートウェイが ID プロバイダに対して独立して OIDC リダイレクトを実行します。その結果、4 つのツールでそれぞれ個別にログインし、共有状態を持たない 4 つの孤立したセッションが発生します。

ユーザーにとっては、繰り返しログインを求められる症状として現れます。一方、プラットフォームエンジニアにとってより深刻な問題は、トークンの分散伝播です。コントロールプレーンで作成されたアイデンティティは、各データプレーンにおいて信頼性があり、スコープが限定され、監査可能なコンテキストへと変換される必要があります。

図 2：2 つのリージョンクラスターにまたがる分散型のセッション所有権。各ゲートウェイが独自のセッションストアを維持しているため、プラットフォームごとに別々のログインが必要です。

このモデルはアプリケーション数が少ない場合には機能しますが、プラットフォームが拡大すると構造的な問題が生じます。

• セッションは作成された場所に限定されます。あるゲートウェイが発行したトークンは他のゲートウェイでは認識されないため、ユーザーはプラットフォーム全体ではなくサービスごとに認証を行う必要があります。
• ログアウトもローカルに限定されます。1 つのツールからログアウトしても、他の場所にはアクティブなセッションが残ったままになり、ユーザーの混乱やセキュリティリスクを招きます。
• トークンの更新が調整されていません。各ゲートウェイが独立してアップストリームの ID プロバイダと更新サイクルを交渉するため、負荷が増大し、セッション状態が分岐する原因となります。

ID コンテキストの整合性が保たれていない状況が散見されます。下流サービスではトークンの解析方法がバラバラだったり、認証ロジックが重複して実装されたりしているのです。

新しいサービスを追加するたびに、既存の複雑さが引き継がれます。ツールを追加すればするほど、同じ認証統合を再構築することになりがちです。

プラットフォーム利用者にとっては、繰り返しログインを求められることや動作の不整合といった症状として現れます。一方、プラットフォームエンジニアにとっての本質的な課題は、セッション所有権がアクセスを強制すべきコンポーネントに分散してしまっている点にあります。ID 状態の管理まで担わされているのが実態です。

フェデレーション型プラットフォームにおける2つのIDパターン比較

フェデレーション型プラットフォームでID を構造化する一般的なアプローチには、主に2 つのパターンがあります。

1つ目は「分散セッション所有権」です。各サービスゲートウェイが独自のログインフロー、セッションストア、トークン更新ロジック、ログアウト動作を管理します。これにより各クラスターは独立して動作しますが、ID 状態がプラットフォーム全体でシームレスに移動しないという課題が生じます。

2つ目は「集中型セッション所有権」です。ログイン、セッション状態の管理、トークン更新、ログアウトを一元的な ID ゲートウェイが担当します。地域ゲートウェイは引き続き稼働しますが、セッション検証を中央の ID ゲートウェイに委譲し、リクエストの実行（エンフォースメント）に集中するようになります。

表 1：ログイン、ログアウト、トークン更新、ID の伝播、運用スケーリングにおける分散型と集中型のセッション所有権の比較

集中型のセッション所有権は、すべてのアプリケーションで必須ではありません。ユーザーが一つのワークフローの一部として複数のツールやクラスター、リージョンをまたいで移動し、それらのツールが単一のプラットフォームのように動作することを期待する場合に、その価値が発揮されます。

中央 ID ゲートウェイのパターン

中央 ID ゲートウェイが担う責任は以下の 3 つです：

セッション作成：OIDC 認可コードフローの処理と、プラットフォーム全体のセッション確立

リクエストごとのアイデンティティ検証：ゲートウェイや信頼できるサービスに対して「このユーザーは誰か」を回答する仕組み

セッションライフサイクル管理：プラットフォーム全体でトークンの更新とログアウトを調整する機能

地域認証ゲートウェイは引き続き稼働します。各クラスターごとのポリシー適用、ローカルサービスの保護、リクエストへのアイデンティティ注入といった役割は従来通りです。変化するのは、セッションがどこに保存されるかという点だけです。

従来のようにセッションを各地域のゲートウェイ内に格納するのではなく、中央のアイデンティティゲートウェイは、認証されたすべてのセッションを Redis などの共有ストアへ書き込みます。セッションは非表示のセッション ID をキーとして識別され、プラットフォームドメインにスコープを限定した安全な HTTP-only ブラウザ Cookie と紐付けられます。

各リクエストでは、地域ゲートウェイが /gateway/userinfo といったアイデンティティ検証エンドポイントを呼び出します。中央のアイデンティティゲートウェイはセッションストアを確認し、信頼できるアイデンティティクレームを返却します。その後、地域ゲートウェイは標準化されたアイデンティティヘッダー群をリクエストに付与して、アプリケーションへ転送します。

アプリケーション側ではもはや、トークンの解析や認証情報の更新、アイデンティティプロバイダとの直接連携を行う必要はありません。一貫したインターフェースを通じてアイデンティティを利用するだけで済みます。

リクエストフロー

このパターンには、ログイン、検証、ログアウトの 3 つの主要なフローがあります。

ログイン

有効なプラットフォームセッションを持たずにユーザーがアクセスしてきた場合、リージョンゲートウェイはブラウザを中央アイデンティティゲートウェイへリダイレクトします。中央ゲートウェイは組織の ID プロバイダーに対して OIDC オーザーライゼーションコードフローを実行し、サーバーサイドで認証コードを交換します。その後、生成されたセッションを Redis に保存して有効期限（TTL）を設定し、HTTP-only セッションクッキーをセットします。

このセッションクッキーが、そのセッションの残りの間におけるユーザーのプラットフォーム資格情報となります。

リクエストごとの検証

その後のリクエストでは、リージョンゲートウェイはセッションクッキーを /gateway/userinfo へ送信します。中央アイデンティティゲートウェイはセッションを検索し、ユーザー ID、メール、グループ、ロール、セッションメタデータなどのアイデンティティクレームを返却します。

リージョンゲートウェイはこのクレームを使用して、信頼できるアイデンティティヘッダーに注入します。下流のサービスはこれらのヘッダーを読み取り、必要に応じてローカルの認可ロジックを適用します。

これにより、リクエストパスを軽量に保つことができます。通常の要求では、OIDC 交換や ID プロバイダへの直接呼び出しは不要です。必要なのはセッションの参照と、信頼されたゲートウェイ間での検証呼び出しだけです。

トークンの更新とログアウト

アクセストークンが期限切れに近づくと、中央の ID ゲートウェイは保存されたリフレッシュトークンを使用してトークンを更新し、セッションレコードを更新します。更新された状態は共有ストアに書き込まれるため、すべての地域ゲートウェイが同じセッション状態を認識します。

ログアウトの場合、中央の ID ゲートウェイはセッションレコードを削除します。次の要求で、すべての地域ゲートウェイが無効なセッションを検知し、アクセスを拒否するか、ユーザーをログインページへリダイレクトします。これにより、ログアウトは即座に、かつプラットフォーム全体で有効になります。

開発者が再利用できる要素

NVIDIA の実装背後にある具体的なインフラストラクチャは社内情報ですが、このアーキテクチャパターンは移植可能です。外部のプラットフォームチームは以下の要素を再利用できます：

• プラットフォーム全体のセッション所有者を一元化すること

• /gateway/userinfo などの最小限の検証エンドポイントを用意すること

• 検証を委任するステートレスな地域ゲートウェイを採用すること

• 明示的な TTL（有効期限）を設定した共有セッションストアを使用すること

• 下流サービス向けに標準化された ID クレームまたはヘッダーを利用すること

• 共有セッションを無効化する単一のログアウトパスを確立すること

• ゲートウェイやサービスを一度に一つずつ移行するモデルを採用すること

このパターンは、独自ミドルウェアに依存するものではありません。標準的な OIDC ライブラリ、Redis やその他の低遅延セッションストア、そして一般的な Kubernetes Ingress やサービスメッシュ環境で利用可能なゲートウェイ連携機能を用いて実装可能です。

セキュリティと信頼性のガードレール

セッション所有権を一元化することでプラットフォームは簡素化されますが、その分、アイデンティティゲートウェイが重要な基盤サービスとなります。このパターンを採用するチームは、初めから障害発生時の設計、信頼境界の明確化、監査可能性を考慮して構築する必要があります。

地域ゲートウェイと中央アイデンティティゲートウェイの間では、堅牢なサービス間認証を実装してください。相互 TLS（mTLS）、ワークロードアイデンティティ、署名付き内部トークンを用いれば、信頼できない呼び出し元が検証エンドポイントを利用するのを防ぐことができます。

信頼性の低い外部から送信されたアイデンティティヘッダーは、ゲートウェイ層が追加した信頼できるヘッダーに置き換える必要があります。アプリケーションは、クライアントリクエストに含まれるヘッダーを信用せず、必ずゲートウェイ層によって付与されたヘッダーのみを信頼すべきです。

セッションレコードにはプラットフォームが必要とする情報のみを含めましょう。アクセストークンの有効期限を短く設定し、明示的なセッション TTL（Time To Live）を設定し、リフレッシュトークンを保護し、転送中の暗号化を適用し、セッションストア周囲には適切なアクセス制御を設けることが重要です。

障害発生時の挙動は意図的に定義してください。アイデンティティゲートウェイやセッションストアが利用不可になった場合、すべてのリクエストを拒否する「フェイルクローズ」を採用すべきプラットフォームもあれば、回復力のために短時間のキャッシュ検証を行う必要があるケースもあります。この判断は明確に行い、プラットフォームのリスクモデルと整合させる必要があります。

ログの検証、リフレッシュ、ログアウトイベントを一元化することで、誰がどのサービスにいつアクセスし、セッションがどのように変更されたかを示す信頼性の高い監査証跡を作成しやすくなります。

上位アイデンティティシステムへの負荷軽減

セッション所有権を中央集権化するもう一つの目に見えない利点は、上位のアイデンティティインフラストラクチャにかかる負荷が軽減されることです。

分散型モデルでは、各リージョンゲートウェイが独立してアイデンティティプロバイダー、トークン秘密格納庫、認可ポリシーエンジンに呼び出しを行います。ユーザーが 3 つのツールをまたいで移動すると、プラットフォームは 3 回の別々のトークン交換、3 つの独立したリフレッシュパス、そして 3 回のポリシー評価を実行する可能性があります。

一方、中央集権型のアイデンティティゲートウェイでは、ログイン時にアイデンティティプロバイダーへの呼び出しは 1 回で済みます。リージョンゲートウェイは OIDC フローを繰り返すのではなく、共有セッションに対して検証を行います。トークンのリフレッシュは 1 つのサービスによって調整され、キャッシュされた認可コンテキストは有効期限が切れるまで再利用されます。

クラスターやツールの数が増えるにつれて、上位アイデンティティへの負荷は「ユーザー・ツール・クラスターの組み合わせの数」ではなく、「アクティブなユーザーの数」に比例してスケールします。多数のツールを 1 つのワークフローに組み込むプラットフォームでは、この違いが重要になります。

統合された AI およびデータワークフローの実現

中央集権型のアイデンティティは、より高レベルなプラットフォーム機能を実現する基盤となります。

統一されたプラットフォームシェルでは、複数のツールを埋め込み、1 つのログインで背後に AI アシスタントを配置できます。各埋め込まれたアプリケーションは依然としてゲートウェイ層を通じてリクエストを検証しますが、ユーザーにとっては単一の認証済みプラットフォームとして体験されます。

AI アシスタントも同じモデルの恩恵を受けます。プラットフォームアシスタントは、ユーザーに代わってデータの照会、メタデータの取得、ツールの呼び出し、結果の要約などを頻繁に行う必要があります。セッション検証を一元化することで、アシスタントはプラットフォームセッションを通じてユーザーの身元を解決し、信頼できる身元コンテキストをバックエンドツールへ渡すことが可能になります。

つまり、アシスタントが広範なサービス認証情報や、ツールごとの個別ログインフローを必要としないことを意味します。そのアクションはユーザーの RBAC スコープを引き継ぐため、システムの推論と監査が容易になります。

パターンの適用

このアーキテクチャを実際のプラットフォームに適用するには、まず現在セッションが作成されている場所を洗い出すことから始めます。OIDC フローを実行しているゲートウェイ、トークンを直接解析するサービス、下流のアプリケーションが信頼するヘッダー、そして現在のログアウト処理がどうなっているかを特定します。

その後、中央契約を定義してください。

• セッション作成を担当するのはどのサービスか？
• /gateway/userinfo で返すクレームは何か？
• 身元ヘッダーの注入を許可するゲートウェイ層はどれか？
• プラットフォームセッションの有効期限はどの程度にするか？
• リフレッシュとログアウトの監査はどう行うか？
• セッションストアが利用不能になった場合、どう対処するか？

契約が明確になったら、段階的な移行を開始します。まずは一つのリージョンゲートウェイか、関連するサービスグループから始めましょう。ローカルのセッション検証を中央のアイデンティティゲートウェイへの呼び出しに置き換えます。アプリケーション側のアイデンティティインターフェースは安定したまま保つことで、下流のサービスが大幅な書き換えを余儀なくされないようにします。

最初の移行が成功したら、さらに多くのゲートウェイやツールを追加していきます。目標はすべてのリージョンにおける強制ポイントを排除することではありません。重要なのは、すべての強制ポイントが同じ「セッションの真実」のソースから読み込むようにすることです。

一つの問い

分散されたセッション状態は、静かに蓄積していくアーキテクチャ上の負債です。最初は繰り返しログインを促す形で現れますが、より大きなコストとして、認証ロジックの重複、ログアウトの一貫性の欠如、不必要なアイデンティティプロバイダへの負荷、そして分断されたユーザーコンテキストなどが挙げられます。

中央のアイデンティティゲートウェイは、セッションの所有権とリクエストの強制を分離することで根本原因に対処します。ログイン、トークン更新、検証、ログアウトのすべてを一つのサービスが担当し、リージョンゲートウェイは共有されたセッションレコードを読み取りながらローカルでアクセスを強制します。

NVIDIA ではこのパターンにより、繰り返しのログインイベントが 55% 減少し、委任されたユーザーアイデンティティを持つ統一された開発者ポータルや AI アシスタントの基盤が作られました。同じアプローチは、連合 Kubernetes やデータ、AI 環境を構築する他のプラットフォームチームにも役立ちます。

このアーキテクチャがあなたのプラットフォームに適しているか評価するには、まず一つだけ問いかけてみてください。「現在、セッション状態はどこに保存されており、どのサービスが本来不要なID判断を行っているのか？」もし答えが「想定以上に分散したセッション状態がある」というものであれば、移行パスは単純です。ゲートウェイを一つ選び、ローカルでのセッション検証を中央集権的な検証呼び出しに置き換え、そこから順次拡張していく間にプラットフォームの残りは安定したまま維持します。

始め方

同様のID対応ゲートウェイアーキテクチャの実装を検討しているなら、まずは OAuth2 Proxy のローカル環境 を使って OIDC ログインやクッキー処理、Redis ベースのセッション管理を探索してみましょう。次に、Istio 外部認証サンプル に従って Auth Gateway のインターフェースを定義し、OPA Envoy Istio 例 を用いて Rego ポリシー評価を追加します。JWT や API キーの検証、メタデータの付加、ポリシー決定、信頼できるアップストリームヘッダーを統合的にカバーする参照実装としては Authorino を確認してください。

これらプロジェクト群は、本記事で説明した ID 層、ゲートウェイ層、ポリシー層を実装するための実践的な出発点となります。