Menu

How gVisor sandboxes untrusted pods: a second Linux kernel, written in Go, and what it costs you

Reading 0:00
15s threshold

We run backend code we've never seen, from thousands of sites, on Kubernetes, and every one of those pods runs inside gVisor. Most of my day goes to it. This is the map I wish I'd had before I started sending fixes upstream.

Why a second kernel

A normal container is a Linux process with walls: namespaces decide what it can see, cgroups how much it can use, seccomp which system calls it may make. Every call it's allowed still lands in the host kernel, and every container on the node shares that kernel. One kernel bug is enough to escape.

A VM fixes that with a guest kernel and a hypervisor, and pays for it in boot time and memory. gVisor sits in the middle. A sandbox starts like a container, but the app's system calls never reach the host kernel.

The pieces

Sentry : the core. A from-scratch reimplementation of the Linux system call interface in Go: memory management, filesystems, a network stack, signals, even the TCP connections.…

Continue reading — create a free account

Join HashtagPLUS to read full articles, follow hashtags, vote, and join the conversation.