2026年のAI推論基盤では、GPU効率だけを追う設計は不十分である。Kubernetes上で本番推論を運用する場合、特権コンテナ、プロンプト経由の不正入力、モデル重みの持ち出し、依存イメージ汚染といった攻撃面を前提に、ゼロトラストの防御境界を実装レベルで設計する必要がある。本稿は、NVIDIAのConfidential Containers参照アーキテクチャ、SUSE VirtualizationのMIG vGPU分離、Kubernetes DRAのGA化、CNCF Kubernetes AI Conformance Programを接続し、Kubernetes GPUセキュリティの実装手順を整理する。

1. 脅威モデルを先に固定する: Kubernetes GPU推論の攻撃面

設計開始時点で、少なくとも以下を明示するべきである。第一に、ノード管理者権限とワークロード実行権限の分離である。第二に、GPU割当て時の隣接テナント干渉リスクである。第三に、推論リクエスト経由で誘発されるデータ漏えいとモデル抽出リスクである。第四に、コンテナイメージとドライバ配布経路のサプライチェーンリスクである。これらは別々の層で対策しなければ、単一の制御点が突破された際に一気に侵害される。

実装上は、(a) 実行隔離（Kata/VM境界）、(b) GPU隔離（MIG/vGPU）、(c) 割当て制御（DRA）、(d) 構成適合性（AI Conformance）を独立した防御レイヤとして設計するのが現実的である。

2. NVIDIA Kata Containers統合でConfidential Computingを実装する手順

NVIDIAのConfidential Containers参照アーキテクチャは、GPU Confidential Computing、Kata Containers、GPU Operatorを組み合わせて、Kubernetes上の機密推論を実装する構成を提示している（初版GAは2026-04-03公開のリリースノート）。GPU Operatorドキュメントでは、Kata Manager（k8s-kata-manager）およびCC Manager（k8s-cc-manager）でランタイムとGPU機密モードを管理する流れが示される。

実装順序は次の通りである。1) ハードウェア前提（対応GPU、CPU TEE、BIOS設定）を満たす。2) Kubernetesノードをcontainerdベースで構成し、GPU Operatorを導入する。3) Kata RuntimeClass（例: kata-qemu-nvidia-gpu-snp）を推論ワークロードへ適用する。4) リモートアテステーションを必須化し、証明成功時のみ秘密情報（暗号鍵、レジストリ認証情報、sealed secret）を払い出す。5) CCモードをノードラベルで明示制御し、検証環境と本番環境を分離する。

この構成で重要なのは「秘密の払い出し条件」をアテステーション結果に紐づける点である。暗号化済みモデル重みや資格情報を、検証済みTEE内でのみ利用可能にすることで、ホスト侵害時の横展開を抑制できる。

3. SUSE Virtualization×MIG vGPUで物理GPU分離を組み込む

マルチテナント推論では、ソフトウェア隔離だけでなく、GPUリソースの物理的分割が必要である。SUSEは2026-03-24公開の技術記事で、SUSE VirtualizationにおけるNVIDIA MIG vGPUマルチテナンシーを提示し、MIGインスタンスをVMに割り当てる運用を説明している。加えて、SUSE Virtualization v1.7ドキュメントでは、MIGConfigurationリソースによるMIG-backed vGPUの有効化手順が定義されている。

実装上は、1) MIG対応GPUノードを用意、2) SUSE VirtualizationでPCIDevices ControllerとNVIDIA Driver Toolkitを有効化、3) MIGプロファイルを構成、4) vGPUデバイスを有効化、5) 推論VM/ワークロードに必要プロファイルのみ割当て、の順で進める。これにより、同一物理GPU上でも計算資源とメモリ帯域を分離した運用が可能となる。

特に共有環境では、MIG分割を「性能最適化」ではなく「分離境界」として扱うべきである。Kataによる実行隔離と重ねることで、防御層の冗長化が成立する。

4. DRA GAとコミュニティ実装を前提にした割当て制御

Kubernetesでは、Dynamic Resource Allocation（DRA）がv1.34でGA化（2025-09-01公開ブログ）され、特殊デバイス割当てをより宣言的かつ拡張可能に扱えるようになった。GPUでは、kubernetes-sigs/dra-driver-nvidia-gpu が公開され、GPUおよびComputeDomainを対象にしたDRA実装がコミュニティ運営で進んでいる。

実務では、デバイス要求を単純な「GPU個数」から、プロファイル・分離要件・再構成要件を含む要求定義へ移行することが要点である。DRA導入時は、ResourceClaimのライフサイクル、失敗時再試行、ノード障害時の再割当て、監査ログ出力を同時設計しないと、可用性と統制のどちらかが破綻しやすい。

したがって、DRAは単なる新APIではなく、GPUセキュリティガバナンスをコード化するための土台と位置づけるべきである。

5. 2026年版ゼロトラスト実装チェックリスト（AI Conformance対応）

CNCFは2025-11-11にCertified Kubernetes AI Conformance Programを公開し、2026-03-24時点で認証プラットフォームが拡大している。Google CloudのGKE AI conformance解説でも、DRAやGateway APIなどを含む要件が示されている。これらは「動作するクラスタ」から「再現可能に安全運用できるクラスタ」へ移行するための基準として有効である。

実装チェックリストは以下である。1) RuntimeClass強制と特権設定の最小化。2) アテステーション成功を秘密払い出しの前提に設定。3) MIG/vGPU分離とテナント境界の明文化。4) DRAで割当て要件を宣言化。5) 推論API前段で入力検証、レート制御、監査ログを実装。6) SBOM・署名検証・脆弱性スキャンでサプライチェーン統制。7) AI Conformance要件との差分を定期監査。

結論として、Kubernetes GPUセキュリティは「製品導入」ではなく「多層制御の統合作業」である。Kata、MIG、DRA、Conformanceを同時に設計し、運用監査までつなげることが2026年の推論基盤で実用的なゼロトラスト実装となる。

FAQ

Q1. Kata ContainersだけでGPU推論のゼロトラスト要件は満たせるか？

単独では不十分である。実行隔離は強化されるが、GPU資源分離、秘密管理、割当て統制、API防御を別レイヤで補完する必要がある。

Q2. MIG vGPUは性能改善目的だけで導入してよいか？

本番推論では分離境界として設計すべきである。性能改善は副次効果であり、主目的はテナント間干渉と情報漏えいリスクの低減である。

Q3. DRA GA化で従来のデバイスプラグインは不要になるか？

直ちに不要にはならない。既存運用との併用期間を設け、DRAの要求定義と監査フローを段階的に移行するのが安全である。

Q4. AI Conformance Programは必須要件か？

法的必須ではないが、複数クラスタ・複数ベンダ運用で再現性と移植性を確保する実務基準として有効である。

参考文献