What Are Kata Containers? A Dev Guide to Secure Containers

Kata Containers

Kata Containers is an open-source container runtime that runs containerized applications inside lightweight virtual machines (VMs), providing enhanced workload isolation and security without compromising the performance and flexibility of containers.

Background and Origin

Kata Containers was formed in 2017 as a merger between two secure container projects:

Intel Clear Containers, which focused on hardware-enforced isolation
Hyper.sh’s runV, which used QEMU to run containers as lightweight VMs

These efforts merged under the OpenStack Foundation, now the OpenInfra Foundation, to form a community-driven project.

Its mission: enable secure containers without losing container agility.

Why Kata Containers Exist

Traditional containers are fast and efficient—but not always secure. They run directly on the host OS, using namespaces and cgroups for isolation. That’s fine in trusted environments, but dangerous when:

You run multi-tenant apps on shared infrastructure
You need strong kernel isolation
You must comply with security or regulatory requirements

Kata Containers bridges the gap between:

Performance of containers
Security of VMs

The result: a sandboxed container that behaves like any other, but runs in a virtual machine for true isolation.

Architecture and How It Works

At its core, Kata Containers sits underneath your existing container runtime and launches every container (or pod) inside a lightweight VM. It supports:

OCI runtime spec (works with containerd, CRI-O)
Multiple hypervisors: QEMU, Cloud Hypervisor, Firecracker

Simplified architecture:

+------------------------------------------+
| Orchestrator (Kubernetes, Docker)        |
+----------------------+-------------------+
                       |
         Container Runtime (containerd, CRI-O)
                       |
                Kata Runtime (kata-shim-v2)
                       |
           Lightweight VM (QEMU, Firecracker)
                       |
     Guest OS + Containerized Application

Key Components

kata-agent: runs inside the guest VM and handles syscalls and container lifecycle
kata-runtime: interfaces with containerd or CRI-O to spawn VMs
shim: connects the container process to the orchestrator

Each pod or container runs with its own kernel in the VM, creating a hard separation from the host.

Kata Containers in Kubernetes

Kubernetes supports RuntimeClass to define how pods should be run. Kata Containers can be used to selectively run pods in secure sandboxes.

Example: Run a pod using Kata in Kubernetes

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
annotations:
  io.kubernetes.cri.untrusted-workload: "true"
spec:
  runtimeClassName: kata
  containers:
  - name: sandboxed-app
    image: busybox
    command: ["sh", "-c", "echo Hello from Kata && sleep 3600"]

This pod will be launched in a microVM instead of a standard Linux namespace. Ideal for untrusted code or third-party services.

Performance and Isolation Tradeoffs

Kata Containers is a balancing act. Let’s break it down:

Feature	Native Containers (`runc`)	Kata Containers
Startup Time	30–100ms	150–400ms
Memory Footprint	Low	Slightly higher
Kernel Isolation	None	✅ Full
I/O Performance	Fast	Slight overhead
Network Performance	Native speed	Slightly slower
CPU Overhead	Minimal	Slight

Note: With optimized Firecracker or Cloud Hypervisor setups, startup times are getting closer to native containers.

Kata Containers vs. Other Sandboxing Runtimes

Runtime	Isolation Type	Startup Time	Kernel	Use Case
runc	Namespaces/cgroups	Fast	Host	Standard container workloads
gVisor	User-space syscall proxy	Moderate	User	Moderate security, syscall filtering
Kata Containers	Hardware VMs	Moderate	Guest	High isolation, regulated workloads
Nabla	Library OS sandboxing	High	Custom	Research and unikernel experiments
Firejail	AppArmor & seccomp	Fast	Host	Desktop sandboxing (non-container)

Use Cases and Real-World Adoption

1. Multi-Tenant Kubernetes

Cloud providers like Alibaba use Kata to isolate customer workloads while keeping infrastructure costs low.

2. CI/CD Sandboxing

Secure your GitHub Actions, Jenkins, or GitLab jobs by running each in a microVM to limit potential damage from arbitrary code.

3. Edge and IoT Workloads

When deploying to devices where kernel isolation is essential (like medical devices or industrial systems).

4. Running Untrusted Third-Party Apps

E.g., SaaS platforms that let users upload and run code (Jupyter notebooks, ML models).

Challenges and Limitations

Cold Start Latency: Although improving, booting VMs takes longer than containers
Resource Usage: VMs have more overhead than namespace-based containers
Operational Complexity: Requires understanding of VMs and guest OS management
Storage Integration: Needs drivers for passing block devices between host and VM
Network Tuning: Bridging VM and host network interfaces can introduce configuration overhead

Despite these, Kata has become much more production-ready, especially when paired with faster hypervisors like Firecracker.