What is container isolation? Mechanisms, limitations, and secure runtimes

Container isolation is how containerised workloads are kept separate from the host operating system and from each other. Understanding how it works, and where it stops working, is one of the more important decisions an engineering team makes when designing multi-tenant infrastructure or running workloads they do not fully control.

This guide covers the core mechanisms, what they prevent, where they fall short, and what secure runtimes provide when the standard model is not sufficient.

Container isolation is the set of mechanisms that keep a containerised process separated from the host operating system and from other containers running on the same host. It controls what a container can see (other processes, network interfaces, filesystems), what resources it can consume (CPU, memory, disk I/O), and what system calls it can make.

Isolation acts as a containment boundary. If a container misbehaves, crashes, or is compromised, isolation limits how far the impact can spread. The strength of that boundary depends on which mechanisms are in place and how they are configured.

Standard container isolation is implemented entirely in the Linux kernel. It does not introduce a separate execution environment or a new kernel. The container and the host share the same kernel, and isolation is enforced through kernel-level access controls.

Container runtimes like runc implement isolation using three kernel primitives. Each addresses a different dimension of separation.

Namespaces restrict what a process can see. Each namespace type controls visibility into a different resource:

• PID namespace: the container sees its own process tree. It cannot see or signal processes on the host.
• NET namespace: the container gets its own network stack, interfaces, and routing table.
• MNT namespace: the container has its own filesystem mount points, isolated from the host filesystem.
• USER namespace: process UIDs and GIDs inside the container map to different IDs on the host, so root inside a container is not root on the host (when user namespaces are enabled).
• IPC namespace: inter-process communication resources (shared memory, semaphores) are isolated between containers.

Namespaces control visibility, not resource usage. A container that cannot see host processes can still exhaust CPU or memory and affect neighbouring workloads.

Control groups enforce resource limits. They cap how much CPU, memory, disk I/O, and network bandwidth a container can consume. cgroups prevent one container from starving the host or adjacent containers of resources (the noisy neighbour problem).

cgroups do not restrict what a container can do within its resource allocation. A container running within its memory limit can still make arbitrary system calls.

Seccomp (secure computing mode) filters which system calls a container is allowed to make. Docker's default seccomp profile blocks around 44 syscalls that are not needed for most workloads and that represent meaningful attack surface.

AppArmor and SELinux are Linux Security Modules (LSMs) that enforce mandatory access controls on top of the standard permission model. They restrict what files a process can access, what capabilities it can use, and what operations it can perform.

Together, these reduce the attack surface available to a compromised container. They do not eliminate it.

Standard container isolation handles several dimensions of separation well. The table below covers what each mechanism prevents and where the boundary ends.

Standard container isolation handles the common cases well. It is the shared kernel that creates the fundamental gap.

Every syscall a containerised process makes goes directly to the host kernel, the same kernel shared by every other container on that node. Namespaces, cgroups, and seccomp reduce the available attack surface, but they do not eliminate it. If an attacker finds a kernel vulnerability and exploits it from inside a container, they reach the host.

The default container runtime for Docker and Kubernetes is runc. runc creates containers using namespaces and cgroups but does not introduce any additional isolation layer between the container and the host kernel. A container escape via runc gives an attacker access to the node. In a multi-tenant environment where multiple customers share the same node, that means access to other tenants' workloads, environment variables, credentials, and data.

This is not a theoretical risk. Container escapes have been demonstrated against runc, the Linux kernel, and various container runtime implementations. The attack surface exists by design. For a detailed breakdown of how container escapes work and what they expose, see why your containers aren't as isolated as you think.

For workloads you trust and control on dedicated infrastructure, the standard model is a reasonable tradeoff. For untrusted code, AI-generated scripts, multi-tenant environments, or customer-facing execution, secure runtimes provide a stronger isolation boundary than shared-kernel isolation alone.

Three isolation approaches cover the majority of production use cases. Each makes a different tradeoff between security, performance, and operational complexity.

All three integrate with Kubernetes and Docker. runc is the default. gVisor and Kata Containers are drop-in replacements for specific workload classes.

For a detailed comparison, see Firecracker vs gVisor and Kata Containers vs Firecracker vs gVisor. For isolation patterns specific to Kubernetes multi-tenant environments, see Kubernetes multi-tenancy.

Secure runtimes replace or wrap the standard container runtime to provide a stronger isolation boundary than namespaces and cgroups alone.

gVisor is an open-source application kernel developed by Google. It intercepts system calls in user space through a component called the Sentry, which re-implements Linux system interfaces in Go, significantly reducing the number of syscalls that reach the host kernel and ensuring those that do are sanitised by the Sentry. The host kernel's attack surface is reduced because the workload interacts with the Sentry rather than the host kernel directly.

gVisor integrates with Docker and Kubernetes via an OCI-compatible runtime called runsc. Existing container workloads run with minimal changes. The tradeoff is syscall coverage: gVisor does not implement every Linux syscall, so some workloads are incompatible without modification. It also adds overhead on I/O-heavy workloads due to the syscall interception layer.

Kata Containers runs each workload inside a lightweight virtual machine with its own dedicated guest kernel. The isolation boundary is enforced by hardware virtualisation via KVM, not by the Linux kernel's access controls. An attacker who escapes the container still faces a VM boundary before reaching the host.

Kata Containers is an orchestration framework, not itself a VMM. It supports Cloud Hypervisor, Firecracker, and QEMU as interchangeable backends. From Kubernetes' perspective, a Kata-backed workload looks like a standard container. The microVM underneath provides hardware-level isolation.

Northflank uses Kata Containers with Cloud Hypervisor as its primary isolation approach in production, with Firecracker and gVisor applied depending on workload requirements and infrastructure constraints. This stack powers Northflank sandboxes, which run untrusted workloads at scale in isolated microVMs.

Standard container isolation is appropriate for trusted, internal workloads on dedicated infrastructure. The threat model changes when any of the following are true:

• Untrusted code execution: Running code you did not write and have not reviewed (AI-generated scripts, customer-submitted jobs, third-party packages) means the content of the workload is part of your attack surface. Standard containers do not contain a determined attacker who can reach the kernel. See remote code execution sandbox and what is sandbox infrastructure for how teams approach this.
• Multi-tenant workloads: When multiple customers share the same infrastructure, a compromise in one tenant's workload must not reach another tenant's data or the host. Shared-kernel isolation does not provide that guarantee. Kernel-level isolation via microVMs does.
• AI agent execution: AI agents write and execute code, install packages, and call external services. The code they generate may be malicious, incorrect, or exploit vulnerable dependencies. Running agent-generated code in standard containers on shared infrastructure is the equivalent of running untrusted user input as a privileged process. See how to sandbox AI agents and self-hosted AI sandboxes for isolation strategies in this context.
• Compliance and regulated workloads: Some regulated industries require workload isolation that can be demonstrated at the hardware level. Standard container isolation does not satisfy those requirements. MicroVM-backed workloads with dedicated guest kernels do.

Isolating a container means restricting its visibility into and access to host resources: other processes, network interfaces, filesystems, and the kernel. A fully isolated container cannot see host processes, cannot access the host filesystem, cannot exhaust host resources without limit, and ideally cannot reach the host kernel directly, instead interacting with a sandboxed or guest kernel.

Kubernetes and Docker support multiple container runtimes. runc is the default and uses shared-kernel isolation. gVisor (via runsc) intercepts syscalls in user space. Kata Containers runs each workload in a dedicated microVM. You select the runtime per workload class using RuntimeClass in Kubernetes, applying stronger isolation to workloads that require it without changing the deployment model.

Kubernetes delegates isolation to the container runtime configured on each node. The default is runc, which uses Linux namespaces, cgroups, and seccomp. Stronger isolation is available by configuring Kata Containers or gVisor as a RuntimeClass, which Kubernetes applies per pod. Network policies, PodSecurityAdmission, and RBAC provide additional isolation layers at the Kubernetes level.

Container isolation uses Linux kernel primitives (namespaces, cgroups) to separate processes on a shared kernel. VM isolation uses hardware virtualisation (KVM) to give each workload its own dedicated guest kernel. A container escape in a shared-kernel environment can reach the host. A guest escape in a VM environment still faces the hypervisor boundary before reaching the host. MicroVMs (Kata Containers, Firecracker) bring VM-level isolation to container workflows.

Standard container isolation is not sufficient when the workload is untrusted, when multiple tenants share infrastructure, when AI agents execute arbitrary code, or when compliance requirements demand hardware-level isolation. In those cases, secure runtimes (gVisor or Kata Containers with a microVM backend) provide the stronger boundary that shared-kernel isolation cannot.