| name | cis-gke-v170-5.10.3 |
| description | Consider GKE Sandbox for running untrusted workloads (Automated) |
| category | cis-gke |
| version | 1.7.0 |
| author | cyberstrike-official |
| tags | ["cis","gke","kubernetes","gcp","cluster-config","sandbox","gvisor","workload-isolation","multi-tenant"] |
| cis_id | 5.10.3 |
| cis_benchmark | CIS Google Kubernetes Engine (GKE) Benchmark v1.7.0 |
| tech_stack | ["kubernetes","gcp","gke"] |
| cwe_ids | [] |
| chains_with | [] |
| prerequisites | [] |
| severity_boost | {} |
5.10.3 Consider GKE Sandbox for running untrusted workloads (Automated)
Profile Applicability
Description
Use GKE Sandbox to restrict untrusted workloads as an additional layer of protection when running in a multi-tenant environment.
Rationale
GKE Sandbox provides an extra layer of security to prevent untrusted code from affecting the host kernel on your cluster nodes.
When you enable GKE Sandbox on a Node pool, a sandbox is created for each Pod running on a node in that Node pool. In addition, nodes running sandboxed Pods are prevented from accessing other GCP services or cluster metadata. Each sandbox uses its own userspace kernel.
Multi-tenant clusters and clusters whose containers run untrusted workloads are more exposed to security vulnerabilities than other clusters. Examples include SaaS providers, web-hosting providers, or other organizations that allow their users to upload and run code. A flaw in the container runtime or in the host kernel could allow a process running within a container to 'escape' the container and affect the node's kernel, potentially bringing down the node.
The potential also exists for a malicious tenant to gain access to and exfiltrate another tenant's data in memory or on disk, by exploiting such a defect.
Impact
Using GKE Sandbox requires the node image to be set to Container-Optimized OS with containerd (cos_containerd).
It is not currently possible to use GKE Sandbox along with the following Kubernetes features:
- Accelerators such as GPUs or TPUs
- Istio
- Monitoring statistics at the level of the Pod or container
- Hostpath storage
- Per-container PID namespace
- CPU and memory limits are only applied for Guaranteed Pods and Burstable Pods, and only when CPU and memory limits are specified for all containers running in the Pod
- Pods using PodSecurityPolicies that specify host namespaces, such as hostNetwork, hostPID, or hostIPC
- Pods using PodSecurityPolicy settings such as privileged mode
- VolumeDevices
- Portforward
- Linux kernel security modules such as Seccomp, Apparmor, or Selinux Sysctl, NoNewPrivileges, bidirectional MountPropagation, FSGroup, or ProcMount
Audit
Using Google Cloud Console:
- Go to Kubernetes Engine by visiting: https://console.cloud.google.com/kubernetes/list.
- Click on each cluster, and click on any Node pools that are not provisioned by default.
- On the Node pool Details page, under the
Security heading on the Node pool details page, check that is set to 'Enabled'.
