GKE Sandbox

Google Kubernetes Engine（GKE）クラスタで不明なコードや信頼できないコードを実行するコンテナは、ノードのホストカーネルに対する潜在的なセキュリティ リスクとなります。コードをカーネルから分離することで、ホストカーネルをこれらの脅威から保護できます。このドキュメントでは、GKE Sandbox が gVisor や microVM などのテクノロジーを使用してこの分離レイヤを作成する方法について説明します。

このドキュメントは、GKE ノードの攻撃対象領域を減らし、信頼できないコードからノードを保護するセキュリティ スペシャリストを対象としています。次のことに精通している必要があります。

• システムコール
• GKE ノードのアーキテクチャ
• コンピュータ システムでのサンドボックス化

GKE のサンドボックスについて

ノードにインストールされているコンテナ ランタイム（containerd など）は、コンテナのプロセスとノードで実行されているカーネルをある程度分離します。ただし、コンテナ ランタイムはノードの特権ユーザーとして実行されることが多く、その場合、ホストカーネルに対するほとんどのシステムコールにアクセスできます。

Kubernetes と GKE では、サンドボックス化により、実行中のコンテナが分離され、他のコンテナやコンテナ ランタイムに影響する可能性のあるエクスプロイトやエラーの影響が制限されます。サンドボックスでコンテナを実行すると、基盤となる Compute Engine インスタンスのカーネルを信頼できないコードや不明なコードから保護できます。サンドボックス化は、価値の高いコンテナが他のワークロードの影響を受けないようにするための多層防御の有効な手段でもあります。GKE Sandbox を使用して、サンドボックスでワークロードを実行できます。

潜在的な脅威

コンテナ ランタイムまたはホストカーネルの欠陥により、コンテナ内で実行されているプロセスがコンテナから「エスケープ」し、ノードのカーネルに影響を与える可能性があります。マルチテナント クラスタと、コンテナで信頼できないワークロードを実行するクラスタは、他のクラスタよりもセキュリティの脆弱性の影響を受けやすくなります。以下に例を示します。

• SaaS プロバイダやウェブホスティング プロバイダなど、ユーザーがコードをアップロードして実行できる組織。
• コードを生成して実行する AI エージェント（多くの場合、監督なし）。

GKE Sandbox が使用するサンドボックス技術は、コンテナ エスケープの次の潜在的な影響を軽減するのに役立ちます。

• ホスト カーネルをクラッシュさせてノードをダウンさせる悪意のあるコードまたは欠陥のあるコード。
• メモリまたはディスクにある他のテナントのデータを盗み出す悪意のあるテナント。
• 他の Cloud de Confiance by S3NS サービスやクラスタ メタデータにアクセスする信頼できないワークロード。

GKE のサンドボックス テクノロジー

GKE Sandbox は、次のサンドボックス テクノロジーをサポートしています。これらのテクノロジーはそれぞれ、ワークロードを分離するために異なるアプローチを使用しており、さまざまなユースケースに適しています。

• gVisor: 権限昇格を必要としない Linux カーネル API のユーザー空間を再実装したものです。ユーザー空間カーネルとコンテナ ランタイムは、システムコールの大部分を再実装し、ホストカーネルの代わりにサービスを提供します。これにより、ホストカーネルへの直接アクセスが制限されています。ゲスト カーネルの仕組みの詳細については、gVisor アーキテクチャ ガイドをご覧ください。

• MicroVMs: 完全な Linux カーネルとオペレーティング システムを実行する軽量の仮想マシン。各 Pod は独自の microVM で実行され、他の Pod やホストノードから厳密に分離されます。GKE Sandbox は、オープンソースの Kata Containers ソフトウェアと Cloud Hypervisor 仮想マシン モニター（VMM）を使用して、microVM を作成して管理します。

次の表に、gVisor と microVM の主な違いをまとめます。この情報を参考に、ユースケースに適したサンドボックス テクノロジーを選択してください。

特定の種類のサンドボックスで実行するアプリケーションの決定に役立つ詳細については、制限事項をご覧ください。

サンドボックスのリクエストの仕組み

サンドボックスでアプリケーションを実行するには、次の操作を行います。

1. ComputeClass を使用してノードを自動作成するか、ノードプールを手動で作成して、ノードでサンドボックス テクノロジーを有効にします。
2. gvisor や microvm など、サンドボックス タイプに対応する RuntimeClass を使用して、Pod のサンドボックスをリクエストします。詳細については、GKE Sandbox によるワークロード分離の強化をご覧ください。

GKE は、リクエストされたサンドボックス テクノロジーを使用するノードで Pod をスケジュールします。このノードは、サンドボックスでのアプリケーションの実行を処理します。必要に応じて、ノードセレクタと許容値を使用して、GKE Sandbox が有効になっているノードでサンドボックスをリクエストしない Pod を実行できます。これは、すべてのノードで実行するモニタリング ツールなどの信頼できるワークロードに役立ちます。

その他のセキュリティに関する推奨事項

GKE Sandbox を使用する場合は、次の推奨事項も考慮してください。

• サンドボックス内で実行されるすべてのコンテナに対してリソースの上限を指定します。これにより、不正なアプリケーションによるノードリソースの占有を回避し、ノード上で実行中の他のアプリケーションやシステム プロセスへの悪影響を防ぐことができます。

• GKE 用 Workload Identity 連携を使用している場合は、ネットワーク ポリシーを使用してクラスタ メタデータへのアクセスをブロックし、169.254.169.254 へのアクセスをブロックします。これにより、悪意のあるアプリケーションがプロジェクト ID、ノード名、ゾーンのプライベート データにアクセスする可能性があるリスクを防ぎます。GKE 用 Workload Identity 連携は、GKE Autopilot クラスタで常に有効になっています。

制限事項

GKE Sandbox は多くのアプリケーションで動作していますが、すべてのアプリケーションに対応しているわけではありません。このセクションでは、GKE Sandbox の現在の制限事項について詳しく説明します。

GKE Sandbox の GPU

gVisor を使用すると、サンドボックスで GPU ワークロードを実行できます。gVisor ですべての NVIDIA ドライバの脆弱性が軽減されるわけではありませんが、Linux カーネルの脆弱性からは引き続き保護されます。サンドボックス化された Pod では GPU タイム シェアリングを使用しないでください。GPU は Pod 間で完全に分離されていません。gVisor が GPU ワークロードを保護する方法については、GPU サポートガイドをご覧ください。

GKE Sandbox の GPU ワークロードには、次の制限が適用されます。

• MicroVM は GPU をサポートしていません。
• gVisor には次の制限が適用されます。
  • CUDA ワークロードのみがサポートされます。
  • 使用可能な GPU モデルの一部のみがサポートされています。詳細については、GPU モデルのサポートをご覧ください。
  • 各 GKE バージョンでサポートされているのは、latest と default の NVIDIA ドライバ バージョンのみです。他のドライバ バージョンは動作しない可能性があります。
  • RDMA や IMEX などのすべての GPU 機能がサポートされているわけではありません。お客様のニーズに応じて、gVisor が特定の機能をケースバイケースでサポートする場合があります。特定の機能のサポートをリクエストするには、サポートケースを開くか、gVisor の機能リクエストを開きます。

GPU モデルのサポート

次の表に示すのは、GKE Sandbox でのさまざまな GPU モデルのサポートについての説明です。

GKE Sandbox の TPU

GKE バージョン 1.31.3-gke.1111001 以降では、gVisor を使用してサンドボックスで TPU ワークロードを実行できます。gVisor ですべての TPU ドライバの脆弱性が軽減されるわけではありませんが、Linux カーネルの脆弱性からは引き続き保護されます。gVisor プロジェクトで TPU ワークロードを保護する方法については、TPU サポートガイドをご覧ください。

GKE Sandbox の TPU ワークロードには、次の制限が適用されます。

• MicroVM は TPU をサポートしていません。

• gVisor は次の TPU バージョンをサポートしています。

  • V4pod
  • V4lite
  • V5litepod
  • V5pod
  • V6e

ノード構成

GKE Sandbox を使用するノードには、次の制限が適用されます。

• gVisor と microVM は Linux ノードのみをサポートします。Windows Server ノードはサポートされていません。
• gVisor は、Container-Optimized OS ノードイメージのみをサポートします。MicroVM は、Container-Optimized OS と Ubuntu のノードイメージをサポートしています。
• MicroVM では、ノードでネストされた仮想化を有効にする必要があります。ネストされた仮想化の要件と制限事項がすべて適用されます。
• Standard クラスタでは、デフォルトのノードプールで GKE Sandbox を有効にできません。クラスタには、GKE Sandbox を使用しないノードプールが常に 1 つ以上必要です。すべてのワークロードがサンドボックス化されていても、このノードプールには 1 つ以上のノードが必要です。この制限は、システム サービスを信頼できないワークロードから分離するために存在します。

クラスタ メタデータへのアクセス

ノードで gVisor サンドボックス タイプを使用している場合、ノード上の Pod はノード OS レベルでクラスタ メタデータにアクセスできません。Workload Identity Federation for GKE を使用して Pod ID にロールを付与しない限り、Pod は Cloud de Confianceサービスにアクセスできません。

この制限は、microVM サンドボックス タイプには適用されません。microVM の Pod からクラスタ メタデータへのアクセスを防ぐには、ポート 988 の 169.254.169.252/32 への下り（外向き）トラフィックを拒否する NetworkPolicy を使用します。

SMT が無効になっている可能性がある

同時マルチスレッディング（SMT）設定（Intel CPU のハイパー スレッディングとも呼ばれます）は、マイクロアーキテクチャ データ サンプリング（MDS）の脆弱性など、コア状態を共有するスレッドを利用するサイドチャネルの脆弱性を軽減するために使用されます。

サイドチャネル攻撃を軽減するために、gVisor は Linux Core Scheduling を使用します。SMT のデフォルト設定は変更されません。Linux Core Scheduling は、gVisor サンドボックスで実行される Pod にのみ適用されます。

マシンタイプのデフォルトの SMT またはハイパースレッディングの設定は、マシンの MDS に対する脆弱性に応じて次のように異なります。

• Scale-Out ComputeClass を使用する Autopilot Pod: SMT は常に無効になります。
• Intel プロセッサを使用するマシンタイプ: ハイパースレッディングはデフォルトで無効になっています。
• AMD プロセッサを使用するマシンタイプ: SMT はデフォルトで有効になります。
• コアごとに 1 つのスレッドのみを使用するマシンタイプ（Arm プロセッサなど）: SMT はサポートされません。リクエストされたすべての vCPU が表示されます。

SMT を有効にする

GKE Standard ノードプールでは、選択したマシンタイプで SMT がデフォルトで無効になっている場合は SMT を有効にできます。SMT が有効か無効かに関係なく、vCPU ごとに課金されます。詳細については、コアあたりのスレッド数を変更した場合の料金をご覧ください。SMT 設定を変更するには、次のいずれかを行います。

• gVisor を使用する GKE Sandbox ノードプールを作成するときに、--threads-per-core フラグを設定します。

  gcloud container node-pools create smt-enabled \
      --cluster=CLUSTER_NAME \
      --location=LOCATION \
      --machine-type=MACHINE_TYPE \
      --threads-per-core=2 \
      --sandbox=type=gvisor
  

  • CLUSTER_NAME: 新しいノードプールを作成する既存のクラスタの名前。
  • LOCATION: クラスタの Compute Engine のリージョンまたはゾーン。
  • MACHINE_TYPE: マシンタイプ。

• DaemonSet を使用して、既存のノードプールで SMT を有効にします。

  1. gVisor を使用する既存のノードプールに cloud.google.com/gke-smt-disabled=false ノードラベルを追加します。

     gcloud container node-pools update NODE_POOL_NAME \
         --cluster=CLUSTER_NAME \
         --location=LOCATION \
         --node-labels=cloud.google.com/gke-smt-disabled=false
     

     次のように置き換えます。

     • NODE_POOL_NAME: 既存のノードプールの名前。
     • CLUSTER_NAME: 新しいノードプールを作成する既存のクラスタの名前。
     • LOCATION: クラスタの Compute Engine のリージョンまたはゾーン。

  2. DaemonSet をデプロイします。DaemonSet は、cloud.google.com/gke-smt-disabled=false ラベルのあるノードでのみ実行されます。

     kubectl create -f \
         https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-node-tools/master/disable-smt/gke/enable-smt.yaml
     

  3. DaemonSet Pod のステータスが Running であることを確認します。

     kubectl get pods --selector=name=enable-smt -n kube-system
     

     出力は次のようになります。

     NAME               READY     STATUS    RESTARTS   AGE
     enable-smt-2xnnc   1/1       Running   0          6m
     

  4. Pod のログに SMT has been enabled があることを確認します。

     kubectl logs enable-smt-2xnnc enable-smt -n kube-system
     

機能

Standard クラスタに適用

デフォルトでは、コンテナは未処理のソケットを開けないため、悪質な攻撃を防ぐことができます。ping や tcpdump など、特定のネットワーク関連ツールは、そのコア オペレーションの一部として未処理のソケットを作成します。未処理のソケットを有効にするには、NET_RAW の機能をコンテナのセキュリティ コンテキストに明示的に追加する必要があります。

spec:
  containers:
  - name: my-container
    securityContext:
      capabilities:
        add: ["NET_RAW"]

GKE Autopilot を使用する場合、この機能にはセキュリティ上の影響があるため、 Cloud de Confiance では NET_RAW 権限をコンテナに追加できません。

外部依存関係

Autopilot クラスタと Standard クラスタに適用

サンドボックス内で実行される信頼できないコードに、データベース サーバー、API、その他のコンテナ、CSI ドライバなどの外部サービスとの接続が許可されている場合があります。これらのサービスはサンドボックス境界の外部で実行されているため、個別に保護する必要があります。これらのサービスの脆弱性が悪用されると、サンドボックスが回避される可能性があります。サンドボックス内で実行されるコードがこれらのサービスに接続するリスクと影響を考慮し、必要な保護手段を講じる必要があります。

たとえば、ext4 や CSI ドライバなど、コンテナ ボリュームのファイル システム実装などを検討する必要があります。CSI ドライバはサンドボックス分離の外部で実行され、ホストとサービスに対して特権アクセスが許可されている場合があります。これらのドライバが悪用されると、ホストのカーネルに侵入され、ノード全体が乗っ取られる可能性があります。攻撃による影響を抑えるため、コンテナ内の CSI ドライバは必要最小限の権限で実行することをおすすめします。GKE Sandbox では、Compute Engine 永続ディスクの CSI ドライバの使用がサポートされています。

互換性のない機能

GKE Sandbox には、次の機能制限が適用されます。

• gVisor と microVM の両方のサンドボックスには、次の制限が適用されます。

  • Cloud Service Mesh は、Autopilot クラスタのサンドボックスではサポートされていません。
  • seccomp、AppArmor、SELinux、No New Privileges フラグ、双方向マウント伝播、procMount Pod セキュリティ コンテキストなどの Linux カーネル セキュリティ モジュールは、サンドボックス化された Pod ではサポートされていません。
  • コンテナレベルのメモリ使用量の指標はサポートされていません。ただし、Pod のメモリ使用量はサポートされています。

• 次の制限は、gVisor サンドボックスにのみ適用されます。

  • 特権モードを使用するコンテナはサポートされていません。
  • 未加工のブロック ボリュームはサポートされていません。
  • ポート転送（kubectl port-forward の使用など）はサポートされていません。
  • Hostpath ストレージはサポートされていません。
  • sysctl カーネル パラメータの設定はサポートされていません。
  • CPU とメモリの制限は、Guaranteed または Burstable QoS クラスを持つ Pod にのみ適用されますが、適用されるのは、Pod 内のすべてのコンテナに CPU とメモリの制限が指定されている場合だけです。

• 次の制限は microVM サンドボックスにのみ適用されます。

  • hostNetwork: true 設定を使用する Pod はサポートされていません。microVM サンドボックスで実行され、hostNetwork: true 設定を使用する Pod は、Pod の外部にあるリソースにアクセスできません。
  • ソケットレベルのトレースに依存する診断ツールは、microVM に接続されているネットワーク インターフェースにのみアクセスできます。

次のステップ

• GKE Sandbox を構成する。
• セキュリティの概要を確認する。
• Pod のライフサイクルを理解する。