GKE Sandbox: Harden workload isolation
akhilsharmaGCPsecurity

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
    OR
  • There has to always one node with Sandbox disabled
  • Sandboxed Pods are prevented from accessing cluster metadata

Limitations

  • 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

References