gVisor: Secure Sandboxing for Untrusted Containers on Kubernetes

Introduction

If you’ve ever run “untrusted but still necessary” workloads on Kubernetes — CI jobs from pull requests, build containers with root in the image, or third‑party plugins — you’ve probably felt the gap between container convenience and VM isolation.

On May 2, 2018, Google open sourced gVisor, a container sandbox that tries to narrow that gap by interposing a userspace kernel between your container processes and the host kernel.

What gVisor is (and isn’t)

A userspace kernel with a container runtime

gVisor consists of:

• A userspace kernel (“the sentry”) that implements a large set of Linux system calls.
• A runtime (runsc) that plugs into common container workflows and starts containers inside the sandbox.

The core idea is simple: reduce the amount of host kernel surface area that container code can touch directly.

Not a replacement for namespaces/seccomp

gVisor is best viewed as an additional isolation layer, not a magic switch that replaces everything else. You still want:

• PodSecurity / PSP-era controls (for the 2018 context)
• seccomp / AppArmor (where available)
• least-privilege RBAC and tight admission controls

Why this matters for Kubernetes operators

In 2018, platform teams were increasingly running multi-tenant clusters: shared build infrastructure, “platform as a product” internal clusters, and early serverless platforms. gVisor is attractive in those environments because:

• Breakouts get harder: many syscalls are handled in userspace, limiting direct host kernel interaction.
• Operationally familiar: you keep Kubernetes primitives (Pods, Deployments, quotas) instead of provisioning a VM per job.
• Good fit for bursty workloads: CI and function-style jobs care about fast start more than peak throughput.

Practical notes from the field

Compatibility: syscall coverage is the real constraint

The most common “surprise” is not installation — it’s workloads that assume the full Linux syscall surface. Watch for:

• language runtimes doing unusual ioctl calls
• tracing/debug tooling that expects privileged syscalls
• apps that lean on ptrace or uncommon networking behavior

Performance: expect overhead, pick your targets

You generally trade some performance for isolation. In practice, gVisor often makes the most sense for:

• CI runners
• plugin/extension workloads
• multi-tenant “user code” execution

and less sense for latency-critical data planes.

Getting started (high level)

Most teams start by introducing gVisor as an opt-in runtime for a small set of namespaces, then expanding:

1. Install the runtime (runsc) on a dedicated node pool.
2. Expose it via your container runtime (Docker/containerd) integration.
3. Route only specific workloads to that pool (labels/taints) and validate behavior.

Summary

gVisor is one of the more pragmatic answers to a long-running Kubernetes question: how do you safely run code you don’t fully trust, without giving up the operational model that containers made easy?