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
MediumAddress
SecurityCompliance Standards
- CIS GKE
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
Identify untrusted / risky workloads and namespaces
- On any machine with
kubectlaccess, 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.
- On any machine with
-
Check current Sandbox (gVisor) configuration on all node pools
- On any machine with
gcloudaccess, list node pools for the cluster: - For each node pool, inspect sandbox configuration:
type: "GVISOR"indicates the node pool is configured for GKE Sandbox.
- On any machine with
-
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).
- If no node pool has
-
Create a GKE Sandbox node pool (if needed)
- On any machine with
gcloudaccess, create a new sandboxed node pool following the benchmark remediation: - Optionally, add labels/taints to target only untrusted workloads, for example:
- On any machine with
-
Schedule untrusted workloads onto GKE Sandbox nodes
- On any machine with
kubectlaccess, 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.
- On any machine with
-
Verify GKE Sandbox is enabled and in use
- Re-run the audit for the sandbox node pool(s):
- On any machine with
kubectlaccess, confirm untrusted Pods are running on nodes from the sandbox pool: - Optionally, list nodes and confirm labels/taints are correctly set:
- Re-run the audit for the sandbox node pool(s):
Using kubectl
Using kubectl
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.
Automation
Automation

