5.10.2 Use GKE Sandbox for untrusted or high risk workloads

Information

Use GKE Sandbox for untrusted, third party, multi tenant, or high risk workloads that need stronger isolation from the node host. GKE Sandbox uses gVisor to add an isolation layer between the container and the host kernel, reducing the risk that untrusted code can affect the node.

GKE Sandbox helps protect the host kernel when Pods run unknown or untrusted code. gVisor provides a user space kernel that handles most system calls on behalf of the host kernel, which limits direct access to the host kernel and helps reduce the impact of container escape vulnerabilities.

This control is especially useful for multi-tenant clusters, SaaS platforms, web hosting environments, services that process untrusted user input, workloads that run third party code, and high value workloads that need additional security. In GKE Standard, sandboxed workloads should use the gvisor RuntimeClass and run on node pools enabled for GKE Sandbox.

NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance.

Solution

Create a new GKE Sandbox enabled node pool for untrusted or high risk workloads. GKE Sandbox cannot be enabled on the default node pool when it is the only node pool, and GKE Sandbox node pools must use the cos_containerd node image.

gcloud container node-pools create $NODE_POOL \\
--cluster $CLUSTER_NAME \\
--location $LOCATION \\
--project $PROJECT_ID \\
--image-type=cos_containerd \\
--sandbox type=gvisor

Update workload manifests for untrusted or high risk workloads to request the gvisor RuntimeClass.

spec:
runtimeClassName: gvisor

Migrate the applicable workloads to the sandbox enabled node pool, validate application behavior, and confirm the Pods are running with runtimeClassName: gvisor . Keep trusted system workloads and regular workloads on separate node pools unless there is an approved reason to run them in the sandbox.

Impact:

GKE Sandbox requires cos_containerd for the sandbox enabled node pool and should be validated for workload compatibility before production use.

It can affect workloads that need privileged containers, direct host kernel access, direct hardware access, kernel level virtualization features, host path behavior, or unsupported low level Linux features. Some accelerator workloads are supported only on specific GKE versions and supported GPU or TPU types.

GKE Sandbox cannot be disabled on an existing Standard node pool, so removing it requires deleting the node pool and migrating workloads.

See Also

https://workbench.cisecurity.org/benchmarks/24956

Item Details

Category: SYSTEM AND COMMUNICATIONS PROTECTION

References: 800-53|SC-7, CSCv7|18.9

Plugin: GCP

Control ID: 8c60f559d634fe4a9560212d4d0780d4709e0c76d579edf7f5e7a4e7b6dfde60