gcp stepUpChallenge

GKE Sandbox: Harden workload isolation

Do you run or test untrusted or unknown code often on GKE? Or have any requirement of deploying the code on GKE from any opensource space where you have a lot of unknown contributors?

Ever faced downtime or crashing of your GKE nodes after deploying any odd application on your GKE cluster?

If answer to any of the above question is yes, then GCP has just the right product for you! “GKE Sandbox”.

GKE Sandbox protects the host kernel on your nodes when containers in the Pod execute unknown or untrusted code.

In the multi-tenant clusters, SaaS Providers often execute unknown code submitted by their users. This unknown code upon execution has the potential of bringing down the host kernels of your node where it is executed. GKE Sandbox protects you here! GKE Sandbox uses gVisor, an open source project, to protect you.

GKE Sandbox leverages the gVisor’s userspace re-implementation of the Linux kernel API to limit the direct access to the host kernel. gVisor implementation is nearly transparent, and does not require any changes to the containerized application.

When you enable GKE Sandbox on a node pool, a sandbox is created for each Pod running on a node in that node pool. Each sandbox uses its own userspace kernel.

How to enable GKE Sandbox

Select an image from Image Type with containerd enabled

Select enable Sandbox with gVisor

When to use GKE Sandbox

GKE Sandbox is a good fit for you, if you work with:

  • Untrusted or third-party applications using runtimes such as Rust, Java, Python, PHP, Node.js, or Golang
  • Web server front-ends, caches, or proxies
  • Applications processing external media or data using CPUs
  • Machine-learning workloads using CPUs
  • CPU-intensive or memory-intensive applications

Catch with GKE Sandbox

However, GKE Sandbox comes with a cost and limits usual capabilities.

  • Default node pool cannot be configured to enable Sandbox
  • There has to always one node with Sandbox disabled
  • Sandboxed Pods are prevented from accessing cluster metadata


  • Sandbox nodes have Hyper-Threading disabled by default
  • Direct access to hardware or virtualization is prevented
  • Cannot use Accelerators such as GPUs or TPUs with GKE
  • Pods using PodSecurityPolicy settings such as privileged mode


Akhil Sharma

Akhil Sharma
DevOps Engineer, Horizontal Digital India
Azure Content Hero
Microsoft Certified: Azure DevOps Engineer Expert
Microsoft Certified: Azure Administrator Associate
Google Cloud Certified: Associate Cloud Engineer
Oracle Cloud Infrastructure Architect Associate
Oracle Cloud Infrastructure Foundations Associate
Oracle Cloud Infrastructure Cloud Operations Associate
Oracle Cloud Infrastructure Developer Associate
Oracle Autonomous Database Cloud Specialist
Aviatrix Certified Engineer - Multi-Cloud Network Associate
Lean Six Sigma White Belt Certified - v4.0
5+ Years of experience in DevOps
For more info, please read "About Me!"

Please subscribe for updates using the bell icon on your screen!

Back To Top
error: Content is protected !!
%d bloggers like this: