Before we meet the fixes, we need to understand the problem. Containers are wonderful, but they have one famous weak spot: they share a kernel.

What is a kernel, and why does everyone share it?

The kernel is the most trusted program on any computer. It sits between your applications and the hardware. When an application wants to read a file, send data over the network or start another process, it cannot touch the hardware directly. It asks the kernel to do the job on its behalf. Each of these requests is called a system call, or syscall for short.

A Linux container is not a tiny computer. It is just a normal group of Linux processes that has been given a restricted view of the system. Two Linux features create this restricted view. Namespaces control what a process can see, such as its own process list, its own network interfaces and its own file tree. Control groups, usually called cgroups, control how much a process can use, such as how much memory or CPU time it gets.

Notice what is missing from that list: a separate kernel. Every container on a node talks to the very same Linux kernel running on that node. That is why containers start in a fraction of a second and use so little memory. It is also why they are less isolated than virtual machines.

The attack surface problem

An attack surface is the total set of places where an attacker can try to break something. For a standard container, the attack surface includes every system call that the Linux kernel offers. Linux has several hundred of them, and behind them sits tens of millions of lines of kernel code written over three decades. Code that big always contains bugs, and some of those bugs are security holes.

When a security hole in the kernel is found, a malicious process inside a container can sometimes use it to escape. Escaping means gaining control over the host machine and, from there, over every other container on it. This is not a theory. It has happened many times in the real world.

Real escapes that made headlines

Here are a few well-known examples that show why teams worry about the shared kernel and the shared runtime.

• Dirty COW (2016). A flaw in how the Linux kernel handled memory let an ordinary user write to files they should only be able to read. It affected almost every Linux system of its time, including container hosts.
• runc CVE-2019-5736. A malicious container could overwrite the host’s copy of runc, the program that starts containers, and so run code as the host’s administrator.
• Dirty Pipe (2022). Another kernel flaw, this time in how pipes handled data, allowed overwriting read-only files.
• Leaky Vessels (2024). A set of runc flaws, including CVE-2024-21626, that could let a container reach the host file system through a leaked file handle.

Notice the pattern. Some of these bugs were in the kernel itself, and some were in the runtime that sets up containers. In both cases, the wall between the container and the host was only as strong as the shared code underneath it.

Who actually needs a stronger wall?

Not everyone does. If you run your own microservices, written by your own team, on your own cluster, regular containers plus good hygiene are usually fine. A stronger wall becomes valuable when the code you run is not fully trusted. Common cases include:

• Multi-tenant platforms, where many customers share one cluster and you promise each one that others cannot reach them.
• Serverless and function platforms, where strangers upload arbitrary code and you run it for them.
• Continuous integration systems, where a build job may run a script pulled from a pull request opened by anyone.
• Online coding playgrounds and notebooks, where users type code and press run.
• AI agents and code interpreters, where a model writes code that your platform executes without a human reading it first.
• Regulated workloads, where auditors want a strong, provable boundary around sensitive data.

For all of these, the answer is the same idea: put one more layer between the workload and the host kernel. That layer is what we call a sandbox.

A sandboxed runtime is a replacement for the part of the system that actually starts your container. It keeps everything else about containers the same, but changes how the container touches the host.

The sandbox idea in one sentence

A sandbox is a protective box around a program, built so that even if the program is hostile, it can only play inside the box. A children’s sandbox keeps sand from spreading across the garden. A software sandbox keeps a misbehaving program from spreading across the machine.

A sandboxed container runtime applies this idea to containers. You still build images the same way. You still write the same Kubernetes objects. Your application does not need to be rewritten. What changes is the engine underneath, which now adds an extra boundary between the container and the host kernel.

Two strategies: intercept or virtualize

There are two main ways to build that extra boundary, and these two ways are exactly what gVisor and Kata Containers represent.

What a sandbox does not do

It is important to stay realistic. A sandboxed runtime does not replace good security practice. It will not fix a weak password, an over-permissive cloud role or a leaked secret. It does not stop an application from being hacked at the application level, for example through a SQL injection. What it does is limit the damage after that, by making it much harder for the compromised program to break out to the host and to its neighbors. Security experts call this defense in depth: many layers, so that one failure is not fatal.

flowchart TB
    subgraph RUNC["Regular container - runc"]
        A1["Application"] --> K1["Host Linux Kernel"]
    end
    subgraph GV["gVisor sandbox"]
        A2["Application"] --> S2["User-space kernel - Sentry"]
        S2 -->|"few filtered calls"| K2["Host Linux Kernel"]
    end
    subgraph KT["Kata Containers sandbox"]
        A3["Application"] --> G3["Guest Linux Kernel"]
        G3 --> H3["Hypervisor - VMM"]
        H3 --> K3["Host Linux Kernel"]
    end

Read the figure from top to bottom in each box. In the regular container, the application speaks straight to the host kernel. In gVisor, there is a guard program in the middle. In Kata, there is a whole second kernel and a hypervisor in the middle. The more layers there are, the harder an attack becomes, but each layer also adds some cost. We will weigh those costs later.

To understand how a sandboxed runtime plugs in, you first need to see the chain of programs that turns a pod request into a running process.

The chain, link by link

When you ask Kubernetes to run a pod, no single program does all the work. Several programs hand the job along like workers on an assembly line. Each one has a clear role.

Where the sandbox plugs in

The clever part is that only the last two links need to change. Kubernetes, the kubelet and even containerd stay exactly as they are. To get a sandbox, you swap runc for a different low-level runtime that follows the same rules but isolates the workload differently.

• For gVisor, the replacement is a runtime called runsc.
• For Kata Containers, the replacement is a shim and runtime pair, usually referenced as kata, that starts a lightweight virtual machine.

Because the swap happens deep in the stack, your container images, your registry, your deployment tools and your monitoring dashboards keep working. This compatibility is the single biggest reason these projects are practical.

flowchart LR
    API["Kubernetes API Server"] --> KL["Kubelet on the node"]
    KL -->|"CRI calls"| CD["containerd or CRI-O"]
    CD --> SH["Runtime shim"]
    SH --> R1["runc - default"]
    SH --> R2["runsc - gVisor"]
    SH --> R3["Kata runtime - lightweight VM"]
    R1 --> W1["Regular container"]
    R2 --> W2["gVisor sandbox"]
    R3 --> W3["Kata micro VM"]

A confusing word: “sandbox” used two ways

Here is a common trap for beginners. In Kubernetes, every pod already has something called a pod sandbox. This is simply the shared environment, namespaces and a tiny placeholder process often called the pause container, that all containers in the pod live in. It is a bookkeeping idea, not a security feature.

When people say sandboxed runtime or sandboxed container in a security conversation, they mean something stronger: an extra isolation layer such as gVisor or Kata. The two uses of the word are unrelated. Every pod has a pod sandbox, but only pods using a runtime like gVisor or Kata are security-sandboxed.

gVisor takes the “guard at the glass window” approach. It places a brand-new kernel, written from scratch, between your application and the real one.

What is gVisor?

gVisor is an open-source project started at Google. Its core idea is surprisingly bold: write a second Linux-compatible kernel that runs as an ordinary program, not as part of the operating system. Google calls this an application kernel. Your container believes it is talking to Linux. In truth, it is talking to this program, which then decides what is safe to pass along to the real kernel underneath.

gVisor is written in Go, a memory-safe language. This matters a great deal. Many of the worst kernel bugs in history come from memory mistakes in the C language, such as reading past the end of a buffer. A memory-safe language makes whole families of those mistakes much harder to make.

The main parts

flowchart TB
    APP["Your application in the container"] -->|"system calls"| SENTRY["Sentry - user-space kernel"]
    SENTRY --> NET["Netstack - own network stack"]
    SENTRY -->|"file requests"| GOFER["Gofer - file access helper"]
    SENTRY -->|"small filtered set of calls"| HOSTK["Host Linux Kernel"]
    GOFER --> HOSTK
    NET -->|"packets"| HOSTK
    SEC["Seccomp filter"] -.->|"restricts"| SENTRY

Two layers of protection

gVisor gives you two walls, not one. First, an attacker must find a bug in the Sentry to do anything interesting. Second, even after finding one, the Sentry is itself restricted to a short list of host calls. To escape, an attacker would need to chain two separate weaknesses: one in the Go code of gVisor and one in the small slice of the host kernel that the Sentry is still allowed to reach. That is a far taller order than exploiting a single kernel bug.

The best way to understand gVisor is to follow one small request, such as reading a file, from the moment the application asks to the moment it gets an answer.

Step by step

How the interception works

The platform is the piece that physically catches the call. Think of it as the doorbell that rings the concierge. Different platforms trade speed for portability.

• Systrap is the modern default. It uses a combination of host features to trap system calls efficiently and works on ordinary machines, including cloud virtual machines, without special hardware access.
• KVM platform uses the processor’s virtualization features to run the application in a special mode, which can make interception faster on bare-metal hosts where this is available.

Older versions also offered a ptrace-based platform that was easy to run but slower. Recent versions have moved on from it, so treat any advice that relies on it as dated.

Files and the network

File access deserves special attention because it is where many container escapes begin. In gVisor, the Sentry keeps its own in-memory picture of the file tree and talks to the Gofer over a dedicated protocol when it needs real files from the host. The Gofer is a separate process with a very limited set of permissions. Even if the application tricks the Sentry, the Gofer will only open what it has been told is allowed.

For networking, gVisor can use its own netstack. Packets are processed by gVisor’s Go code, and only raw packets cross to the host. This keeps the host’s network code, which has seen its share of vulnerabilities, further from the workload. There is also a mode that passes network calls through to the host stack for speed. That mode is faster but gives up part of the isolation benefit, so teams choose it deliberately.

The honest cost: compatibility

Because gVisor re-implements Linux rather than using Linux, it must catch up with every feature. It supports most commonly used system calls, which is enough for the vast majority of web services, databases and language runtimes. However, unusual calls, exotic file systems, and some specialized tools may be missing or behave slightly differently. A program that works on regular Linux may fail in gVisor because of one rarely used call. This is why testing your workload in the sandbox before rolling it out widely is non-negotiable.

Kata Containers takes the opposite road. It does not guard the kernel. It gives each pod its own private kernel inside a very small, very fast virtual machine.

What is Kata Containers?

Kata Containers is an open-source project that runs containers inside lightweight virtual machines while still behaving like a container runtime. It was formed in 2017 by merging two earlier efforts: Intel’s Clear Containers and Hyper’s runV. It is now hosted by the OpenInfra Foundation and has contributors from many large companies, with strong early involvement from firms such as Ant Group and Intel.

A virtual machine, or VM, is a pretend computer running inside a real one. The pretend computer has its own kernel. A hypervisor is the program that creates and manages such pretend computers, and it uses special processor features to keep each one strictly walled off. Ordinary VMs are heavy because they carry a full operating system and boot slowly. Kata trims the VM down to the bare minimum so that it boots in a fraction of a second and uses little memory.

The main parts

flowchart TB
    CRI["containerd or CRI-O"] --> SHIM["Kata shim v2"]
    SHIM --> VMM["Hypervisor - QEMU, Cloud Hypervisor, Firecracker"]
    subgraph VM["Lightweight VM - one per pod"]
        GK["Guest Linux Kernel"]
        AG["Kata agent"]
        C1["Container A"]
        C2["Container B"]
        AG --> C1
        AG --> C2
        GK --- AG
    end
    VMM --> VM
    SHIM |"vsock channel"| AG
    VMM --> HK["Host Linux Kernel and KVM"]

One VM per pod, not per container

A key design choice is that Kata creates a VM for the whole pod, not for each container. This matches how Kubernetes thinks. All containers in a pod already share a network and can share storage, so they all live together in the same VM. The boundary that Kata protects is between pods, which is exactly where trust boundaries usually sit.

Now let us follow a pod from request to running container and see where the isolation comes from.

The lifecycle

Why this is strong

When your application makes a system call, the guest kernel answers it. The host kernel never sees that call. For a program to harm the host, it would first need to find a bug in the guest kernel, which only gets it control of the guest. Then it would need a second bug in the hypervisor or in the narrow set of virtual devices, to cross from the guest to the host. Hardware virtualization is one of the most heavily tested isolation mechanisms in computing, and it is what public clouds already rely on to separate customers from each other.

Networking and storage

Networking is a tricky part, because Kubernetes expects each pod to have a network identity prepared by a network plugin outside the VM. Kata bridges this gap by connecting the virtual network card inside the VM to the pod’s network setup on the host, so that traffic flows as the cluster expects. From outside, the pod still looks and behaves like any other pod, with its own IP address.

For storage, volumes mounted into a pod must cross the VM boundary. Kata handles this with shared file system mechanisms or by handing the VM a virtual disk. This crossing is a place where performance can differ from regular containers, so file-heavy workloads should be measured.

Resources and overhead

A VM carries a fixed cost: the guest kernel, the agent and the hypervisor itself use memory and CPU even if your application is idle. Kata can resize the VM as containers are added, adding CPU and memory while it runs. Still, this fixed cost is real, and Kubernetes has a field to account for it, which we will meet in the next chapter.

You now know the two sandboxes. The next question is practical: how do you tell Kubernetes, pod by pod, which one to use?

What is a RuntimeClass?

A RuntimeClass is a cluster-wide Kubernetes object that gives a friendly name to a runtime configuration. Think of it as a menu item. The kitchen, which is the node, knows how to prepare each dish. The customer, which is the pod, just orders by name. RuntimeClass became generally available in Kubernetes 1.20, so every supported cluster today has it.

A RuntimeClass has three important parts.

The full journey

sequenceDiagram
    participant Dev as Developer
    participant API as API Server
    participant Sch as Scheduler
    participant Kub as Kubelet
    participant Run as containerd
    participant Sbx as Sandbox runtime
    Dev->>API: Create pod with runtimeClassName
    API->>API: Admission adds overhead and node rules
    API->>Sch: Pod needs scheduling
    Sch->>Kub: Assign to a sandbox-capable node
    Kub->>Run: Create pod sandbox via CRI
    Run->>Sbx: Start with matching handler
    Sbx-->>Kub: Sandbox and containers running

Common failures at this stage

• Handler name mismatch. The RuntimeClass names a handler that the node does not know. The pod stays stuck in a creating state, and the event log mentions an unknown runtime.
• Missing node selection. The scheduler places the pod on a node without the runtime. Always pair the RuntimeClass with scheduling rules.
• Forgotten overhead. Without it, nodes look emptier than they are, and pods can get squeezed or evicted under load.
• Unsupported pod settings. Privileged mode, sharing the host network or process space, and some host-path mounts conflict with the whole point of a sandbox and may be rejected or ignored.

Now that you know how each one works, here is a direct comparison. The figures here are directional, since real numbers depend heavily on your hardware and workload.

Reading the table like an architect

No column wins every row. A regular container is the fastest and simplest, but has the weakest wall. gVisor gives a strong wall for a modest price, but you pay with compatibility questions and slower system-call-heavy work. Kata gives the strongest wall and the highest compatibility, but you pay with start-up time, per-pod memory, and a hardware requirement.

A simple way to decide

Every engineering choice is a trade. Here is an honest ledger for each sandbox, so you can decide with open eyes.

gVisor

Kata Containers

The three-way tension

You can think of the decision as a triangle with three corners: security, performance and compatibility. Regular containers sit at performance and compatibility. gVisor leans to security and performance, at some cost to compatibility. Kata leans to security and compatibility, at some cost to performance and density. No point inside the triangle gives you all three corners at once, and anyone who promises otherwise is selling something.

Security is not a switch. It is a stack of layers, and a sandbox is only one of them. Here is how to think about it clearly.

Start with a threat model

A threat model is simply a written answer to three questions: who might attack, what are they after, and how could they try. For sandboxed runtimes, the typical attacker is a tenant or a piece of untrusted code that already runs inside your cluster. Their goals are usually to reach the host, to read other tenants’ data, to steal credentials, or to use your machines for mining and attacks.

A sandbox mainly addresses the first goal and, by extension, the second. It makes the jump from “I control this container” to “I control this node” far harder. That jump is called a container escape, and stopping it is the main reason these runtimes exist.

Layers that work alongside the sandbox

What a sandbox does not cover

• Application bugs. A sandbox does not stop someone exploiting your web app. It only limits what they can do next.
• Over-broad permissions. If the pod carries a powerful cloud role, the attacker uses that role from inside the sandbox, with no escape needed.
• Shared mounts. Mounting sensitive host directories into the pod hands the attacker a path out, and it is often unsupported anyway.
• Network trust. A compromised pod can still call services reachable on the network. Isolation of the kernel is not isolation of traffic.
• Hardware side channels. Attacks that infer secrets from shared processor behavior are a separate problem. VMs and sandboxes help in different ways, but neither erases the risk fully.
• Supply chain. A poisoned dependency running inside a sandbox is still poisoned. The sandbox just keeps the blast radius smaller.

Real escape history and the sandbox lesson

Recall the bugs from the first chapter. Flaws that live in the host kernel or in the container runner are reachable by a normal container, because the container shares them. In a sandbox, the application is aimed at a different target first, either the Sentry or a guest kernel. An attacker needs to find a flaw in that new target and then another one past it. This does not make an escape impossible, and both projects have had their own security fixes over the years. What it does is raise the price and force an attacker to chain several bugs together, which is much rarer and much noisier.

A stronger wall always costs something. The job of an architect is to know where the cost lands and how to keep it small.

The figures above come from the design goals that the Firecracker project publishes for its own microVMs. Treat them as best-case examples of how small a VM can be made, not as promises for every Kata setup. Your numbers will depend on the hypervisor, the guest kernel, the image and the hardware.

Where the cost appears

• Start-up latency. Regular containers start in tens of milliseconds. gVisor adds a little. Kata adds the time to boot a guest, which can reach a few hundred milliseconds or more depending on settings. For long-running services this is irrelevant. For functions that must start on every request, it matters a lot.
• Per-pod memory. Kata’s VM has a fixed footprint, so a node holds fewer pods than it would with regular containers. gVisor’s footprint is lighter.
• System call and I/O speed. gVisor’s detour through the Sentry affects call-heavy workloads such as databases that do many small reads. Kata’s cost shows up in shared file systems and virtual network paths.
• CPU-bound work. Pure computation, such as encoding or number crunching, runs at close to native speed in both.

Ways to keep the cost down

Scaling to many thousands of sandboxes

At large scale, the limiting factors are usually node memory for Kata and system-call throughput for gVisor. Platforms that run huge numbers of short tasks tune the guest image to be tiny, trim the number of devices exposed to each VM, and place the sandbox pool in its own autoscaling group. They also watch the rate at which new sandboxes are created, since mass start-ups can saturate the container runtime and the image pull path before the sandbox layer itself.

A sandbox hides your workload from the host, and that includes hiding it from some of your usual tools. Plan your observability before the first incident, not during it.

What keeps working

The good news is that the everyday Kubernetes experience is unchanged. Application logs written to standard output still flow through the kubelet, so your log shippers keep collecting them. Commands such as viewing logs or opening a shell in a pod still work. Resource requests, limits, readiness checks and liveness checks behave as expected. Metrics for CPU and memory still reach your monitoring system through the normal channels.

What changes

Putting security monitoring in the right place

If your security team relies on agents that watch the host kernel, they will need a plan for sandboxed pods. One common choice is to run a lightweight agent inside the sandbox, as a sidecar or part of the image, where it sees the sandboxed system calls. Another is to rely on network-level monitoring and audit logs from the cluster API, which are unaffected by the sandbox. Whichever you choose, test it on a sandbox node before declaring the detection coverage complete.

A short troubleshooting checklist

Teams that run sandboxes well tend to follow the same few patterns. Teams that struggle tend to fall into the same few traps.

Patterns that work

Anti-patterns to avoid

This chapter pulls the lessons together into a checklist you can actually use.

Best practices

• Write down your threat model first. Know who you are defending against. It guides whether you need gVisor, Kata or neither.
• Test your actual workload. Run your real container, with real traffic patterns, in the sandbox before you commit. Check both correctness and speed.
• Use RuntimeClass fully. Set the handler, the overhead and the scheduling rules together, so that the platform handles placement and capacity for you.
• Separate the pools. Keep sandbox nodes apart from regular nodes with labels and taints. This keeps cost visible and troubleshooting simple.
• Keep all the other layers. Non-root users, limited capabilities, network policies, narrow credentials and image scanning all stay in place.
• Patch promptly. Track security announcements for your chosen runtime, hypervisor, guest kernel and host operating system. Upgrade on a regular schedule.
• Plan observability early. Decide how logs, metrics and security detections will work from inside or around the sandbox.
• Enforce with policy. Use admission controls so that untrusted namespaces cannot run without the sandbox class.
• Document the limits. Tell developers which features are unsupported, such as privileged mode or host networking, so they do not discover the rules by failure.
• Rehearse failure. Practice what happens if the sandbox node pool is full, if a runtime upgrade fails, or if a guest crashes.

Common mistakes

• Believing a sandbox makes an insecure application safe.
• Choosing a runtime from a blog post benchmark instead of measuring your own workload.
• Forgetting that Kata on cloud virtual machines needs nested virtualization or bare-metal nodes.
• Leaving the RuntimeClass overhead empty and then wondering why nodes run out of memory.
• Mounting host paths or enabling host networking and expecting the sandbox to cope.
• Using the sandbox for databases or very I/O-heavy systems without checking the performance impact.
• Skipping upgrades because the sandbox “feels” secure already.
• Relying only on host-level security agents that cannot see inside the sandbox.

These ideas are not experimental. Some of the largest cloud platforms run on them every day.

Quick answers to the questions that come up most often.