Skip to main content

More Info:

Use GKE Sandbox (gVisor) to isolate untrusted workloads from the host kernel, reducing the impact of container escapes. This adds a strong isolation boundary for risky workloads.

Risk Level

Medium

Address

Security

Compliance Standards

  • CIS GKE

Triage and Remediation

Remediation

Manual Steps

  1. Identify untrusted / risky workloads and namespaces
    • On any machine with kubectl access, list namespaces and deployments to find workloads that run untrusted code, multi-tenant apps, user-supplied images, or high-risk services:
    • Document which namespaces/workloads should be isolated with GKE Sandbox.
  2. Check current Sandbox (gVisor) configuration on all node pools
    • On any machine with gcloud access, list node pools for the cluster:
    • For each node pool, inspect sandbox configuration:
    • type: "GVISOR" indicates the node pool is configured for GKE Sandbox.
  3. Decide whether to introduce or expand GKE Sandbox
    • If no node pool has "type": "GVISOR" and you have identified untrusted workloads, decide to create at least one dedicated GKE Sandbox node pool.
    • If some node pools use GKE Sandbox, decide whether to migrate additional untrusted workloads to those or to new sandboxed pools.
    • Consider operational impacts: performance overhead, supported OS/image (cos_containerd), and compatibility of privileged / hostPath workloads (these generally cannot use gVisor).
  4. Create a GKE Sandbox node pool (if needed)
    • On any machine with gcloud access, create a new sandboxed node pool following the benchmark remediation:
    • Optionally, add labels/taints to target only untrusted workloads, for example:
  5. Schedule untrusted workloads onto GKE Sandbox nodes
    • On any machine with kubectl access, update the Pod/Deployment specs of untrusted workloads to use node selectors and/or tolerations matching the sandbox node pool, for example:
    • Apply updated manifests:
    • Ensure no privileged or incompatible workloads are targeted to gVisor nodes.
  6. Verify GKE Sandbox is enabled and in use
    • Re-run the audit for the sandbox node pool(s):
    • On any machine with kubectl access, confirm untrusted Pods are running on nodes from the sandbox pool:
    • Optionally, list nodes and confirm labels/taints are correctly set:
kubectl cannot enable GKE Sandbox, because this setting is configured at the managed control-plane / node pool level via the Google Cloud Console, gcloud CLI, or IaC, not through Kubernetes API objects. Refer to the Manual Steps section for how to create or update node pools with GKE Sandbox (gVisor) enabled.