gVisor Sandboxing Explained for Container Security

The container isolation gap

Containers feel isolated, but they share one thing that matters enormously: the host kernel. A normal container is just a process with namespaces and cgroups around it. When your containerized app makes a syscall — open, read, socket, mmap — that call goes straight to the host's Linux kernel.

That shared kernel is the problem. The Linux kernel is millions of lines of C with a steady stream of CVEs. A container-escape vulnerability in the kernel (or in how it handles a crafted syscall) can let a process break out of its container and compromise the host — and on a shared host, every other tenant on it. This is why "containers aren't a security boundary" is a common refrain among security engineers.

The heavyweight answer is a VM per workload (real hardware-virtualized isolation). The lightweight answer is gVisor.

What gVisor actually is

gVisor, from Google, is a user-space kernel. It implements a large portion of the Linux syscall surface in a sandboxed process called Sentry, written in Go (a memory-safe language). Your container's syscalls don't go to the host kernel directly — they're intercepted and handled by Sentry.

The architecture has two main components:

• Sentry — the application kernel. It intercepts syscalls from the sandboxed app and implements them itself (file systems, networking, signals, memory management). It re-implements Linux semantics rather than passing calls through.
• Gofer — a separate host process that mediates filesystem access, so Sentry itself doesn't get direct host file access.

The critical insight: Sentry itself runs as an unprivileged, heavily restricted process on the host, with a tiny seccomp filter limiting which *real* host syscalls it can make. So even if an attacker fully compromises the application, they're trapped inside Sentry; and even if they somehow compromise Sentry, they hit a minimal seccomp boundary before reaching the host kernel. It's defense in depth.

App in container
   |  syscalls
   v
Sentry (user-space kernel, Go, sandboxed)
   |  small, filtered set of real syscalls
   v
Host Linux kernel

The host kernel's attack surface — exposed to untrusted code — shrinks from "the entire syscall table" to "the handful of calls Sentry is allowed to make."

gVisor vs the alternatives

gVisor sits in the sweet spot: much stronger isolation than plain containers, much lighter than a full VM. It runs as an OCI runtime (runsc), so it slots into containerd/Kubernetes as a drop-in RuntimeClass — you don't rewrite your app.

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: gvisor
handler: runsc
---
apiVersion: v1
kind: Pod
spec:
  runtimeClassName: gvisor   # this pod runs inside gVisor
  containers:
    - name: app
      image: myapp:latest

What it costs

Nothing is free, and gVisor's costs are real:

• Syscall overhead. Every syscall is intercepted and handled in user space, so syscall-heavy workloads (lots of small I/O, fork-heavy processes) see measurable slowdown. Google's own data shows the impact is workload-dependent — CPU-bound work is barely affected; I/O- and syscall-heavy work pays more.
• Compatibility gaps. gVisor implements *most* of Linux but not all of it. Exotic syscalls, certain /proc features, some niche networking, and specific kernel modules may not be supported. Most standard web apps, runtimes, and databases work fine; deeply kernel-coupled software might not.
• Networking modes. gVisor's network stack (netstack) is a user-space TCP/IP implementation; for max throughput you can use host networking passthrough at some cost to isolation.

The honest summary: for typical application workloads the overhead is modest and the isolation gain is large. For latency-critical, syscall-bound workloads, benchmark before committing.

Where gVisor fits in a platform

gVisor shines exactly where you run untrusted or multi-tenant code on shared hosts and can't afford a full VM per workload. That's the scenario for free-tier and hobby workloads on a shared platform: you want strong isolation between tenants without paying for a dedicated VM each.

That's precisely how PandaStack uses it. Free-tier apps run inside a gVisor sandbox, on spot/preemptible nodes, with KEDA scale-to-zero. The gVisor layer means one free-tier tenant's code can't use a kernel exploit to reach another's, even though they share node capacity — the user-space kernel absorbs the syscall surface that would otherwise be the escape route. Higher tiers and build pipelines layer in other isolation (rootless BuildKit, separate node pools), but gVisor is the boundary that makes dense, shared, untrusted workloads defensible.

Should you use it?

Use gVisor when you run code you don't fully trust on shared infrastructure and a VM-per-workload is too heavy. Skip it (or benchmark hard first) for latency-critical, syscall-bound services where every microsecond counts and you already trust the code. And remember it's one layer — pair it with least-privilege containers, dropped capabilities, read-only root filesystems, and network policy. No single mechanism is the whole story; gVisor is a strong, practical layer in a defense-in-depth stack.

References

• [gVisor — official documentation](https://gvisor.dev/docs/)
• [gVisor — architecture guide](https://gvisor.dev/docs/architecture_guide/)
• [gVisor — performance guide](https://gvisor.dev/docs/architecture_guide/performance/)
• [Kubernetes — RuntimeClass](https://kubernetes.io/docs/concepts/containers/runtime-class/)

Want strong container isolation without managing it yourself? PandaStack runs free-tier apps in a gVisor sandbox by default — try it: [dashboard.pandastack.io](https://dashboard.pandastack.io)