在 Google Kubernetes Engine (GKE) 叢集中執行不明或不受信任程式碼的容器，可能會對節點的主機核心造成安全風險。您可以將程式碼與核心隔離，保護主機核心免受這些威脅。本文說明 GKE Sandbox 如何使用 gVisor 和微型 VM 等技術，建立這個隔離層。
這份文件適用於安全防護專家，可協助他們縮小 GKE 節點的攻擊面，並保護節點免於不受信任的程式碼侵害。您應已熟悉下列項目：
GKE 沙盒機制簡介
安裝在節點上的容器執行階段 (例如 containerd) 會在容器的程序和節點上執行的核心之間，提供一定程度的隔離。不過，容器執行階段通常會以節點上的特殊權限使用者身分執行，且可存取主機核心的大部分系統呼叫。
在 Kubernetes 和 GKE 中，沙箱會隔離執行中的容器，以限制可能影響其他容器或容器執行階段的攻擊或錯誤。您可以在沙箱中執行容器，保護基礎 Compute Engine 執行個體的核心，避免受到不受信任或不明程式碼影響。沙箱也是一種良好的縱深防禦措施，可保護重要容器不受其他工作負載影響。您可以使用 GKE Sandbox，在沙箱中執行工作負載。
潛在威脅
容器執行階段或主機核心中的缺陷，可能會讓在容器中執行的程序「跳脫」容器，並影響節點的核心。多租戶叢集和執行不受信任工作負載的叢集，比其他叢集更容易受到安全漏洞影響。例如：
- 允許使用者上傳及執行程式碼的機構，例如 SaaS 供應商和網頁代管供應商。
- 生成及執行程式碼的 AI 代理，通常不需監督。
GKE Sandbox 使用的沙箱技術有助於減輕容器逸出造成的下列潛在影響：
- 惡意或有缺陷的程式碼，導致主機核心當機並使節點停止運作。
- 惡意租戶竊取其他租戶在記憶體或磁碟中的資料。
- 存取其他服務或叢集 Google Cloud 中繼資料的不受信任工作負載。
GKE 中的沙箱技術
GKE Sandbox 支援下列沙箱技術，每種技術都採用不同的方法來隔離工作負載，且適用於不同的用途：
gVisor：Linux 核心 API 的使用者空間重新實作，不需要進階權限。使用者空間核心和容器執行階段會重新實作大部分的系統呼叫，並代表主機核心提供這些呼叫。直接存取主機核心的權限有限。如要進一步瞭解客體核心的運作方式，請參閱 gVisor 架構指南。
MicroVMs：輕量型虛擬機器，可執行完整的 Linux 核心和作業系統。每個 Pod 都在自己的 microVM 中執行，與其他 Pod 和主機節點嚴格隔離。GKE Sandbox 使用開放原始碼 Kata Containers 軟體和 Cloud Hypervisor 虛擬機器監控器 (VMM)，建立及管理微型 VM。
下表摘要列出 gVisor 和 microVM 的主要差異。根據這項資訊，為您的用途選擇適當的沙箱技術。
| gVisor | MicroVMs | |
|---|---|---|
| 核心存取權 | Linux 核心系統呼叫的子集 | 完整 Linux 核心 |
| 隔離等級 | 使用者空間核心中的系統呼叫攔截 | 完整的硬體虛擬化，並配備專屬的客體核心 |
| CPU 和記憶體負擔 | 動態額外負荷，使用者空間核心的基礎記憶體較低 | 每個 Pod 的固定額外負擔為 250 mCPU 和 130 MiB 記憶體 |
| 開始時間 | 不到 200 毫秒 | 約一到兩秒 |
| GKE 節點設定 | 適用於任何 Standard 節點集區和 Autopilot 節點。Autopilot 叢集預設會啟用這項功能。 | 僅適用於啟用巢狀虛擬化的節點。 |
| 節點映像檔支援 | 僅限 Container-Optimized OS | Container-Optimized OS 或 Ubuntu |
| 機型相容性 | 支援大多數 CPU、Arm 架構和加速器機型。 | 僅適用於支援巢狀虛擬化的機型。 |
| 加速器支援 | 支援特定 GPU 模型和 TPU 版本。 | 不支援 GPU 或 TPU。 |
| 特殊權限容器 | 不支援。 | 支援。特殊權限容器只能取得 microVM 中訪客 OS 的根層級存取權，無法存取主機節點。 |
| 應用實例 |
|
|
如需更多資訊，協助您決定要在特定類型的沙箱中執行哪些應用程式，請參閱「限制」。
如何要求沙箱
如要在沙箱中執行應用程式，請按照下列步驟操作：
- 使用 ComputeClasses 自動建立節點，或手動建立節點集區，在節點中啟用沙箱技術。
- 如要為 Pod 要求沙箱，請使用該沙箱類型對應的 RuntimeClass，例如
gvisor或microvm。詳情請參閱「使用 GKE Sandbox 強化工作負載隔離」。
GKE 會在節點上排定 Pod，這些節點使用要求的沙箱技術，然後處理在沙箱中執行應用程式。您可以選擇在啟用 GKE Sandbox 的節點上，使用節點選取器和容許條件，執行不要求沙箱的 Pod，這對於您想在每個節點上執行的監控工具等信任工作負載很有用。
其他安全性建議
使用 GKE Sandbox 時，建議您同時採用下列建議：
在沙箱中執行的所有容器上指定資源限制。這可防止有缺陷或惡意的應用程式耗盡節點資源，以及對節點上執行的其他應用程式或系統程序造成負面影響等風險。
如果您使用 Workload Identity Federation for GKE，請使用網路政策封鎖叢集中繼資料存取權，禁止存取
169.254.169.254。這項措施可防範惡意應用程式存取資訊，避免專案 ID、節點名稱和區域等潛在私人資料外洩。GKE Autopilot 叢集一律會啟用 Workload Identity Federation for GKE。
限制
GKE Sandbox 適用於許多應用程式，但並非全部都適用。本節將進一步說明目前 GKE Sandbox 的限制。
GKE Sandbox 中的 GPU
您可以使用 gVisor 在沙箱中執行 GPU 工作負載。gVisor 無法防範所有 NVIDIA 驅動程式漏洞，但仍可防範 Linux 核心漏洞。請勿在沙箱化 Pod 中使用 GPU 分時，因為 Pod 之間的 GPU 並非完全隔離。如要進一步瞭解 gVisor 如何保護 GPU 工作負載，請參閱 GPU 支援指南。
GKE Sandbox 中的 GPU 工作負載有下列限制：
- MicroVM 不支援 GPU。
- gVisor 有以下限制：
- 僅支援 CUDA 工作負載。
- 系統僅支援部分可用的 GPU 型號。詳情請參閱「支援的 GPU 型號」。
- 每個 GKE 版本僅支援
latest和defaultNVIDIA 驅動程式版本。其他驅動程式版本可能無法運作。 - 系統不支援所有 GPU 功能，例如 RDMA 或 IMEX。視客戶需求而定，gVisor 可能會視情況支援特定功能。如要取得特定功能的支援，請建立支援案件或提出 gVisor 功能要求。
支援的 GPU 型號
下表說明 GKE Sandbox 支援的 GPU 型號：
| 模型 | 預覽 | Google Analytics 支援 | 附註 |
|---|---|---|---|
|
|
|
- | - |
|
|
|
- | - |
|
|
- |
|
自推出以來即支援。 |
|
|
不支援 | 不支援 | V100 和 P100 使用專屬驅動程式，因此不支援。 |
|
|
- | - | GKE Sandbox 不支援 Windows 或 Ubuntu 節點類型，而虛擬工作站節點需要這些類型。 |
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 的節點集區。即使所有工作負載都已沙箱化，該節點集區也必須至少包含一個節點。這項限制是為了將系統服務與不受信任的工作負載分開。
存取叢集中繼資料
如果節點使用 gVisor 沙箱類型，節點上的 Pod 就無法在節點 OS 層級存取叢集中繼資料。除非使用 Google CloudWorkload Identity Federation for GKE 將角色授予 Pod 身分，否則 Pod 也無法存取服務。
這項限制不適用於 microVM 沙箱類型。如要禁止微型 VM 中的 Pod 存取叢集的中繼資料，請使用 NetworkPolicy 拒絕傳送至 169.254.169.252/32 (連接埠 988) 的輸出流量，或在採用 GKE Dataplane V2 的叢集中，拒絕傳送至 169.254.169.254/32 (連接埠 80) 的輸出流量。
SMT 可能已停用
多執行緒並行 (SMT) 設定 (在 Intel CPU 上也稱為超執行緒) 可用於緩解利用執行緒共用核心狀態的側通道安全漏洞，例如微架構資料取樣 (MDS) 安全漏洞。
為減輕側通道攻擊的影響，gVisor 使用 Linux 核心排程。SMT 設定與預設值相同。Linux 核心排程僅適用於在 gVisor 沙箱中執行的 Pod。
機型的預設 SMT 或超執行緒設定取決於機器的 MDS 漏洞嚴重程度，如下所示：
- 使用
Scale-OutComputeClass 的 Autopilot Pod：一律會停用 SMT。 - 使用 Intel 處理器的機型： 預設會停用超執行緒。
- 使用 AMD 處理器的機型：SMT 預設為啟用。
- 每個核心只使用一個執行緒的機型，例如 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=gvisorCLUSTER_NAME：要建立新節點集區的現有叢集名稱。LOCATION：叢集的 Compute Engine 區域或可用區。MACHINE_TYPE：機型。
使用 DaemonSet 在現有節點集區中啟用 SMT：
將
cloud.google.com/gke-smt-disabled=false節點標籤新增至使用 gVisor 的現有節點集區：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 區域或可用區。
部署 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確認 DaemonSet Pod 處於執行中狀態。
kubectl get pods --selector=name=enable-smt -n kube-system輸出結果會與下列內容相似：
NAME READY STATUS RESTARTS AGE enable-smt-2xnnc 1/1 Running 0 6m確認 Pod 的記錄檔中顯示
SMT has been enabled：kubectl logs enable-smt-2xnnc enable-smt -n kube-system
功能
適用於 Standard 叢集
根據預設，容器無法開啟原始 socket 以減少潛在的惡意攻擊。某些網路相關工具 (例如 ping 和 tcpdump) 會建立原始通訊端，做為核心作業的一部分。如要啟用原始 socket，您必須在容器的安全性內容中明確加入 NET_RAW 功能：
spec:
containers:
- name: my-container
securityContext:
capabilities:
add: ["NET_RAW"]
如果您使用 GKE Autopilot， Google Cloud 會基於這項功能的安全影響，禁止您將 NET_RAW 權限新增至容器。
外部依附元件
適用於 Autopilot 和 Standard 叢集
在沙箱中執行的不受信任程式碼，可能可以連線至外部服務，例如資料庫伺服器、API、其他容器和 CSI 驅動程式。這些服務會在沙箱邊界外執行，因此需要個別保護。攻擊者可能會試圖利用這些服務中的安全漏洞，突破沙箱限制。您必須考量沙箱內執行的程式碼可存取這些服務的風險和影響，並採取必要措施來保護這些服務。
這包括容器磁碟區的檔案系統實作項目，例如 ext4 和 CSI 驅動程式。CSI 驅動程式會在沙箱隔離區外執行，且可能具有主機和服務的特殊權限。如果這些驅動程式遭到入侵，可能會影響主機核心，並破壞整個節點。建議您在容器中執行 CSI 驅動程式，並盡量減少所需權限，以降低遭到攻擊的風險。GKE Sandbox 支援使用 Compute Engine Persistent Disk CSI 驅動程式。
不相容的功能
GKE Sandbox 有以下功能限制：
gVisor 和 microVM 沙箱皆有下列限制：
- Autopilot 叢集中的沙箱不支援 Cloud Service Mesh。
- 沙箱化 Pod 不支援 Linux 核心安全模組，例如 seccomp、AppArmor、SELinux、No New Privileges 標記、雙向掛接傳播，以及
procMountPod 安全性環境。 - 系統不支援容器層級的記憶體用量指標。不過，系統支援 Pod 記憶體用量。
以下限制僅適用於 gVisor 沙箱：
- 系統不支援使用特殊權限模式的容器。
- 不支援原始區塊磁碟區。
- 系統不支援通訊埠轉送，例如使用
kubectl port-forward。 - 不支援 Hostpath 儲存空間。
- 系統不支援設定
sysctl核心參數。 - CPU 和記憶體限制僅適用於具有
Guaranteed或BurstableQoS 類別的 Pod，且只有在 Pod 中所有容器都指定 CPU 和記憶體限制時，才會套用。
以下限制僅適用於 microVM 沙箱：
- 系統不支援使用
hostNetwork: true設定的廣告連播。在 microVM 沙箱中執行的 Pod，如果使用hostNetwork: true設定，就無法存取 Pod 以外的任何資源。 - 任何依賴通訊端層級追蹤的診斷工具，都只能存取附加至 microVM 的網路介面。
- 系統不支援使用