Understanding Secure Containers: From HyperContainer to Kata and gVisor

Since early 2015 the author has been developing HyperContainer (runV) and reflects on the evolution of the term “secure container,” emphasizing the difficulty of naming technologies that provide additional isolation for container workloads.

In the cloud‑native era, containers are essentially “application containers” defined by the OCI specification, which describes how an application’s root filesystem, executable, resources, and I/O are launched inside a standard OS environment.

A secure container is defined as a runtime technology that gives a containerized application a complete OS execution environment (often a Linux ABI) while isolating the application from the host OS, thereby adding an extra protection layer.

Kata Containers, announced at KubeCon 2017, implements this idea by using a lightweight VM (via QEMU, Firecracker, ACRN, or cloud‑hypervisor) as a sandbox for each Pod. Each Pod gets a shim‑v2 process that coordinates containerd/CRI‑O, launches the VM, and hot‑plugs the container rootfs into the VM. Multiple containers in the same Pod share the VM’s namespace, and storage can be provided via virtio‑fs for fast, POSIX‑compatible file sharing.

gVisor, released by Google later, takes a different approach: it rewrites the Linux kernel in Go to run in user space (the Sentry), intercepting system calls and handling them without a VM. This reduces the attack surface by limiting the host to only about 20 % of Linux syscalls and delegating critical calls like open() to a dedicated process.

Both Kata Containers and gVisor illustrate how adding an isolation layer improves security, reduces scheduling overhead on the host, and can enhance performance and resource efficiency, pointing toward a future where secure containers become a standard component of cloud‑native infrastructure.