2026年、Kubernetes上のAI推論ワークロードは企業インフラの中核へと移行した。IDCの推計によれば、グローバルAIインフラ投資は2026年に4,970億ドル規模に達し、その推論処理の66%がKubernetesクラスタ上で稼働している。しかし、この急拡大するGPU推論基盤には構造的な攻撃面が存在する。NVIDIA Container Toolkit CVE-2024-0132（CVSS 9.0）からCVE-2025-23266（NVIDIAScape）に至る一連のコンテナ脱出脆弱性、2025年11月に公開されたrunCの3脆弱性連鎖（CVE-2025-31133/52565/52881）、そしてGPU非使用ノードにまでカーネルモジュールが常駐する設計上の欠陥──これらが複合的に作用し、AI推論基盤のセキュリティ前提を根底から揺るがしている。AI自律コンテナエスケープ2026の産業化で分析した通り、攻撃者はこれらの脆弱性を連鎖させることで、単一コンテナからクラスタ全体の掌握に至る攻撃パスを構築できる。本稿では、この構造的攻撃面を技術的に解剖し、Pod Security Standards restricted・VM-based runtime・KSPMの実装設計を定義する。

NVIDIA Container Toolkit脆弱性の系譜 ── CVE-2024-0132からNVIDIAScapeまでの攻撃面拡大

NVIDIA Container Toolkitは、KubernetesクラスタでGPUリソースをコンテナに割り当てる事実上の標準ツールである。Device PluginやGPU Operatorと連携し、ホスト上のGPUデバイスをPodに公開する。しかし、2024年9月以降、このツールキットに致命的な脆弱性が連続して発見されている。

CVE-2024-0132（CVSS 9.0、2024年9月26日公開）は、TOCTOU（Time-of-Check Time-of-Use）競合条件を悪用するコンテナ脱出脆弱性である。Container Toolkit 1.16.1以前およびGPU Operator 24.6.1以前が影響を受ける。攻撃者は特別に細工されたコンテナイメージを通じて、ファイルパーミッションチェックと実際のファイルアクセスの間のタイミングウィンドウを突き、ホストファイルシステムへの直接アクセスを獲得する。これにより、任意コード実行・権限昇格・データ改竄・完全なコンテナ脱出が可能となる。同時に公開されたCVE-2024-0133（CVSS 4.1）は、同じくTOCTOU脆弱性であり、ホストファイルシステム上に空ファイルを作成できる。

注目すべきは、CVE-2024-0132のパッチが不完全であった点である。2025年に発見されたCVE-2025-23359（CVSS 9.0）は、Container Toolkit 1.17.3以前のmount_files関数におけるフォローアップのTOCTOU脆弱性であり、最初のパッチが根本原因を解消できていなかったことを示している。Container Toolkit 1.17.4、GPU Operator 24.9.2で修正された。

そして2025年7月、Wiz ResearchがCVE-2025-23266（NVIDIAScape、CVSS 9.0）を公開した。この脆弱性はクラウド環境の37%に影響するとされ、その攻撃ベクトルの単純さが衝撃的であった。nvidia-ctkのcreateContainerフックがLD_PRELOAD環境変数を継承する設計上の欠陥を悪用し、攻撃者はわずか3行のDockerfileで悪意あるライブラリをコンテナファイルシステムに配置するだけで、フックがroot権限でそれをロードし、即座にコンテナ脱出が成立する。Container Toolkit 1.17.8、GPU Operator 25.3.1で修正されたが、PoCエクスプロイトが公開されており、未パッチ環境への脅威は継続している。

筆者の脆弱性診断・ペネトレーションテストの実務経験からいえば、TOCTOU脆弱性はパッチが困難な部類に属する。時間窓の解消には設計レベルの変更が必要であり、個別のチェック追加では別のタイミングウィンドウが残存しやすい。NVIDIAの事例はまさにこのパターンを示しており、CVE-2024-0132→CVE-2025-23359→CVE-2025-23266と、同一アーキテクチャ上の異なる攻撃面が順次発見されている。Container Device Interface（CDI）を使用する構成ではCVE-2024-0132の影響を受けないことが確認されており、ツールキットのアーキテクチャ自体をCDIベースに移行することが根本的な対策となる。

runC 3脆弱性連鎖が暴くコンテナランタイムの構造的弱点 ── Docker・containerd・CRI-O全面影響の実態

2025年11月、CNCFはrunCに影響する3つの重大な脆弱性を公開した。runCはDocker、containerd、CRI-Oの全てが依存する低レベルコンテナランタイムであり、これらの脆弱性はKubernetesエコシステム全体に波及する。

CVE-2025-31133（CVSS 7.3）は、マスクされたパスに対するシンボリックリンク置換攻撃である。攻撃者は/dev/nullをprocfsファイルへのシンボリックリンクに置き換え、runCがそのシンボリックリンクターゲットをread-writeでバインドマウントさせることで、maskedPathsセキュリティ機能をバイパスする。runc 1.0.0-rc3以降の全バージョンが影響を受け、コンテナ脱出またはホストクラッシュを引き起こす。

CVE-2025-52565（CVSS 7.3）は、/dev/consoleシンボリックリンクの悪用である。runCが/dev/consoleを/dev/pts/$nにバインドする際、攻撃者が/dev/pts/$nをシンボリックリンクに置き換えることで、runCにシンボリックリンクターゲットを/dev/console上にバインドマウントさせる。これにより、機密性の高いprocfsファイルへのread-writeアクセスが可能となり、完全なコンテナ脱出に至る。

CVE-2025-52881（CVSS 7.3）は、CVE-2019-19921の洗練された変種であり、LSM（Linux Security Module）ラベルバイパスを伴う。root権限で動作するrunCが、ホストの/procファイルシステム内の機密procfsガジェットにデータを書き込むことを可能にする。一時的なバインドマウント管理とprocfsへの書き込み操作を悪用する高度な手法である。

これら3脆弱性の本質は、runCが長年にわたって抱えてきたシンボリックリンク処理の構造的弱点にある。2024年1月に公開されたCVE-2024-21626（Leaky File Descriptors）では、/sys/fs/cgroupからのファイルディスクリプタリークを悪用し、Dockerfileの単一のWORKDIR命令だけでコンテナ脱出が可能であった。これは単発の実装バグではなく、コンテナランタイムがホストファイルシステムとの境界を維持するメカニズムそのものに根本的な限界があることを示している。

GPU推論基盤において、この問題は特に深刻である。GPUワークロードはホストデバイスへの直接アクセスを必要とし、通常のコンテナよりも多くの特権を要求する。NVIDIA Container Toolkitの脆弱性とrunCの脆弱性を連鎖させることで、攻撃者はまずrunCのシンボリックリンク脆弱性でコンテナの名前空間制約を破り、次にNVIDIA Toolkitの TOCTOU脆弱性やLD_PRELOAD継承を利用してホストレベルの権限を獲得するという、多段攻撃パスを構築できる。成功した場合、ノードのkubeletを掌握し、そのノード上の全Podを侵害し、最終的にはクラスタ全体への横展開が可能となる。

K8s AI推論ワークロード攻撃面の構造的拡大で指摘した通り、GPU特権コンテナの増加とマシンIDの40,000:1比率が、この攻撃チェーンの成功確率を構造的に引き上げている。

全ノードカーネルモジュール常駐の設計欠陥 ── GPU非使用ノードが攻撃面となる理由

Kubernetes GPU推論基盤のセキュリティを論じる上で、見過ごされがちな構造的欠陥がある。NVIDIAのGPUドライバはカーネルモジュールとしてロードされ、nvidia.ko、nvidia-uvm.ko、nvidia-modeset.ko、nvidia-peermem.koの4つのモジュールがカーネル空間（ring 0）で動作する。これらは全てプロプライエタリかつクローズドソースであり、外部からの監査が不可能である。

問題の核心は、クラスタ構成によってはGPUを実際に使用しないノードにもこれらのカーネルモジュールがロードされるケースがあることである。GPU Operatorのデフォルト設定やノードラベリングの不備により、GPUドライバがクラスタ全体に展開される構成は珍しくない。これは、攻撃面がGPUノードだけでなく、クラスタ内の全ノードに拡大することを意味する。

nvidia.koはGPU操作のためのioctlインターフェースを公開し、nvidia-uvm.koはUnified Virtual Memory（UVM）サブシステムとしてUVM_MAP_EXTERNAL_ALLOCATIONなどの追加ioctlを公開する。Quarkslab社の研究によれば、これらのioctlの多くは非特権ユーザーからアクセス可能であり、メモリ関連の脆弱性が手動のアタックサーフェース調査で発見されている。カーネルモジュールの単一のバグが、ホストのカーネルメモリ全体へのアクセスを攻撃者に与えることになる。

さらに、nvidia-container-cliの動作にも構造的な問題がある。このCLIユーティリティはrunCからGPUデバイスの仕様と共に呼び出され、デバイスのマウントとインジェクション操作を実行する。これらの操作には昇格した権限が必要であり、ホストのドライババイナリをコンテナにバインドマウントする。この設計パターン自体が、ホストとコンテナの間に直接的な信頼ブリッジを作成しており、コンテナからホストへの権限昇格を構造的に可能にしている。CVE-2025-23266（NVIDIAScape）で悪用されたLD_PRELOAD継承は、まさにこの信頼ブリッジの一側面である。

筆者がセキュリティアーキテクトとして複数のゼロトラスト設計に携わった経験からいえば、セキュリティ戦略はビジネスの制約を理解した上でなければ絵に描いた餅になる。GPU推論基盤では「GPUリソースを効率的に共有したい」というビジネス要件と「カーネルレベルの隔離を維持したい」というセキュリティ要件が根本的に矛盾している。この矛盾を解消するには、ノード単位のGPUドライバ隔離を実現するアーキテクチャ変更が不可欠である。具体的には、GPUノードプールの厳密な分離、Taint/Tolerationによる非GPUワークロードのGPUノードからの排除、そしてGPU Operatorの適用範囲をGPUラベル付きノードに限定する設定の徹底が最低限の対策となる。

Edera社がKubeCon 2025で提示した分析は示唆的である。同社のエンジニアはNVIDIA GPUスタックのアーキテクチャを調査し、「GPUスタックを見た後、眠れなくなった」と報告している。クローズドソースのカーネルモジュールがring 0で動作し、ioctlインターフェースが広範囲に公開され、コンテナとホストの間にドライババイナリの共有を通じた直接的な信頼関係が存在する──この構造は、従来のコンテナ隔離モデルの前提を根底から覆すものである。

Pod Security Standards restrictedとVM-based runtimeの実装設計 ── 隔離強度と推論性能のトレードオフ

Kubernetes Pod Security Standardsは、Privileged（制限なし）、Baseline（既知の権限昇格を防止）、Restricted（最も厳格なハードニング）の3段階を定義する。GPU推論基盤のセキュリティ強化にあたり、Restrictedプロファイルの適用は自然な選択に思えるが、実際にはGPUワークロード固有の矛盾が存在する。

Restrictedプロファイルは特権コンテナの使用を禁止し、最小権限を強制し、強力なPod隔離を保証する。しかし、GPUワークロードは通常、デバイスへの直接アクセスやCAP_SYS_ADMINケーパビリティなど、特権的なアクセスを要求する。2022年時点で、リスクのあるLinuxケーパビリティを無効化している企業はわずか10%であり、2021年の42%から大幅に後退している。これはGPU/AIワークロードの急増が、セキュリティ設定の緩和圧力として作用していることを示唆している。

Pod Security Standardsの限界は明確である。GPUデバイスの隔離やマルチテナント環境でのGPUメモリアクセス制御、カーネルモジュールエクスプロイトからの保護といったGPU固有の脅威には対応していない。この限界を補完するのが、VM-based runtimeによるハードウェアレベルの隔離である。

gVisorはユーザー空間でシステムコールを傍受するアプローチを取る。一般的なワークロードでは10〜20%のオーバーヘッドだが、システムコール頻度の高いワークロードでは5〜15倍のレイテンシ増加が発生する。GPUワークロードに対してはGPUドライバやメモリアクセスの隔離機能を持たず、GPU推論基盤への適用は限定的である。ただし、非GPUワークロードのカーネル攻撃面を縮小する用途には有効であり、GPUノードと非GPUノードで異なるランタイムを使い分ける戦略が合理的である。

Kata Containers + Firecrackerは、軽量VMによるフルGPUパススルーを実現する。定常状態のCPUオーバーヘッドは実質ゼロとされ、VM境界による強力な隔離を提供する。GPU推論ワークロードにはVFIOパススルーでGPUをVMに直接割り当てる。ただし、VFIOパススルーはDMA脆弱性を通じてマイクロVM境界を弱める可能性があり、完全な隔離とはいえない点に注意が必要である。Firecrackerは主にCPUバウンドワークロード向けであり、GPU対応は限定的である。

Ederaは2026年に登場した新興のType-1ハイパーバイザソリューションであり、ゾーンベースの隔離モデルを提供する。CPUオーバーヘッドは約0.9%と報告されており、低レベルIOMMU制御による高速起動を実現する。GPUドライバを専用カーネル境界の背後に隔離し、物理GPUを隔離を維持しながら共有できるモデルは、Kata Containersの隔離モデルとgVisorの共有モデルを統合する試みとして注目される。ただし、2026年夏時点でKVM上のゾーンベース隔離を開始したばかりのスタートアップであり、大規模本番環境での実績はまだ乏しい。ベンチャー支援のランタイムをテナント隔離のクリティカルパスに配置するリスクは慎重に評価すべきである。

実装設計としては、以下の多層アプローチが現実的である。第一に、Pod Security Standards Restrictedを全名前空間のデフォルトとし、GPUワークロード用名前空間にのみBaselineを適用する例外ポリシーを設定する。第二に、GPUノードプールをTaint/Tolerationで厳密に分離し、GPU Operatorの適用範囲をGPUラベル付きノードに限定する。第三に、Kata ContainersをGPUワークロードのランタイムとして導入し、VM境界による隔離を確保する。第四に、非GPUワークロードにはgVisorを適用してカーネル攻撃面を縮小する。この構成により、Pod Security Standards単体では達成できないGPU固有の隔離要件を補完できる。

KSPM統合とGPUワークロード監視の実装 ── 検知から対応までの自動化設計

KSPM（Kubernetes Security Posture Management）は、クラスタ構成の継続的監視、ポリシー違反の検出、過剰な権限の特定、コンプライアンスギャップの可視化を提供するフレームワークである。2024年のセキュリティインシデントの45%がKubernetesクラスタの構成ミスに関連していたことを考えると、GPUワークロードの増加に伴うKSPMの重要性は一層高まっている。

GPU推論基盤におけるKSPMの実装は、以下の4層で構成すべきである。

第1層：構成監査（Configuration Audit）。GPU Operatorの設定、Container Toolkitのバージョン、runCのバージョンを継続的に監視し、既知のCVE（CVE-2024-0132、CVE-2025-23266、CVE-2025-31133等）に対する脆弱性状態を自動判定する。Container Device Interface（CDI）の使用有無も監査対象に含める。CDIを使用している構成ではCVE-2024-0132の影響を受けないため、CDI移行の進捗をKPIとして追跡することが有効である。

第2層：ランタイム検知（Runtime Detection）。GPUデバイスファイル（/dev/nvidia*）への異常アクセスパターン、nvidia-container-cliの予期しない呼び出し、LD_PRELOAD環境変数の不正設定、procfsへの書き込み試行を検知ルールとして定義する。Sysdigなどのランタイム保護ツールは、eBPFベースのカーネルレベル監視でこれらのシグナルを捕捉できる。

第3層：ネットワークポリシー監視。GPU Podのネットワーク通信パターンを学習し、コンテナ脱出後の横展開（lateral movement）を示す異常な通信をリアルタイムで検出する。GPU推論Podは通常、モデルサーバーとAPI Gatewayの間の限定的な通信パターンを持つため、ベースラインからの逸脱は高精度で検知可能である。

第4層：自動修復（Auto-Remediation）。脆弱なContainer Toolkitバージョンが検出された場合のローリングアップデート自動起動、不正なPod Security Context（特権モード、過剰なケーパビリティ）が検出された場合のAdmission Webhookによるブロック、コンテナ脱出の兆候が検知された場合のPod隔離（NetworkPolicyの動的適用）とノードドレインの自動実行を定義する。

MCP Server防御実装の設計標準で分析した認証・サンドボックス・ポイズニング対策の設計原則は、KSPMにおけるGPUワークロード監視にも応用できる。特に、38%のインスタンスが無認証で露出していたMCPの事例と同様に、GPUデバイスへのアクセス制御が適切に設定されていないクラスタは、攻撃者にとって低コストの標的となる。

KSPM導入の経済性を検討すると、Gartnerは2025年までのクラウドセキュリティ障害の99%が顧客側の設定ミスに起因すると予測しており、KSPMの投資対効果はインシデント予防の観点から正当化される。GPU推論基盤の場合、単一のコンテナ脱出がモデル資産の窃取、学習データの漏洩、推論結果の改竄という複合的な被害をもたらすため、従来のWebアプリケーション基盤と比較してインシデント単価が桁違いに高い。Cast AIの2026年レポートによれば、分析対象クラスタのGPU平均利用率はわずか5%であり、最適化された環境でも49%（136基のH200）に留まる。この低利用率は、GPUリソースの効率的な共有（マルチテナンシー）への強い経済的圧力を生み、セキュリティ上の妥協を誘発しやすい構造にある。KSPMは、この効率化圧力とセキュリティ要件のバランスを定量的に可視化し、経営層の意思決定を支援する機能を果たす。

FAQ

NVIDIA Container Toolkit CVE-2024-0132は現在も影響がありますか？

Container Toolkit 1.16.2以降にアップグレードすれば直接の影響は解消される。ただし、同一アーキテクチャ上の後続脆弱性（CVE-2025-23359、CVE-2025-23266）も存在するため、1.17.8以降への更新が推奨される。CDI（Container Device Interface）を使用する構成ではCVE-2024-0132の影響を受けない。

runCの3脆弱性はDockerだけでなくKubernetesにも影響しますか？

影響する。CVE-2025-31133/52565/52881はrunC 1.0.0-rc3以降の全バージョンに影響し、Docker、containerd、CRI-Oの全てが依存するため、Kubernetesの主要コンテナランタイム全てが影響範囲に含まれる。パッチ適用済みrunCへの更新が必須である。

GPU非使用ノードにもNVIDIAカーネルモジュールがロードされるのはなぜですか？

GPU Operatorのデフォルト設定やノードラベリングの不備により、GPUドライバがクラスタ全体にDaemonSetとして展開されるケースがある。GPUノードプールの厳密な分離とTaint/Tolerationの適用、GPU Operatorの適用範囲をGPUラベル付きノードに限定する設定で防止できる。

VM-based runtimeのGPU推論性能への影響はどの程度ですか？

Kata Containers + VFIOパススルーの場合、定常状態のCPUオーバーヘッドは実質ゼロとされる。Edera社のType-1ハイパーバイザアプローチでは約0.9%のCPUオーバーヘッドが報告されている。gVisorはGPUワークロードには不向きであり、非GPUワークロード向けのカーネル攻撃面縮小に限定して使用すべきである。

Pod Security Standards RestrictedをGPUワークロードに適用できますか？

GPUワークロードはデバイスアクセスや特定のケーパビリティを必要とするため、Restricted全項目の厳密な適用は困難である。全名前空間のデフォルトをRestrictedとし、GPU専用名前空間にのみBaselineを適用する例外ポリシーと、VM-based runtimeによる補完的隔離を組み合わせる設計が現実的である。

KSPMでGPU固有のセキュリティリスクを検知できますか？

標準的なKSPMに加え、GPUデバイスファイルへの異常アクセス・nvidia-container-cliの不正呼び出し・LD_PRELOAD設定の監視などのカスタム検知ルールを定義することで対応可能である。Sysdig等のeBPFベースランタイム保護ツールとの統合が有効である。詳細はAI自律コンテナエスケープの産業化分析を参照。

CDI（Container Device Interface）への移行は優先すべきですか？

優先すべきである。CDIはNVIDIA Container ToolkitのTOCTOU脆弱性（CVE-2024-0132）の影響を受けない構成であり、デバイスの仕様と割り当てを宣言的に管理できる。Kubernetes 1.31以降でCDI対応が進んでおり、新規構築ではCDIベースの構成を標準とすることを推奨する。

参考文献