Sandboxed containers overview

Background information

Sandboxed containers suit scenarios such as untrusted application isolation, fault isolation, performance isolation, and multi-tenant workload isolation. They enhance security with minimal performance impact and provide the same user experience as Docker containers for features such as logging, monitoring, and elastic scaling.

Compared to Kata Containers, sandboxed containers improve storage, networking, and stability.

Architecture

Key benefits

ACK sandboxed containers vs. Kata Containers

Use cases

Scenario 1: Isolate untrusted applications with sandboxed containers (runV)

• Security risks of runC containers

  

  • Containers using namespace and cgroup isolation have a large attack surface.

  • All containers on a node share the host kernel. If a kernel vulnerability is exploited, malicious code can escape to the host, penetrate the private network, execute privileged code, disrupt services, and steal data.

  • Application vulnerabilities can also allow attackers to penetrate the private network.

  Mitigate runC container security risks with the following measures:

  • Seccomp: Filter system calls.

  • SELinux: Restrict permissions for container processes, files, and users.

  • Capability: Limit container process capabilities.

  • Rootless mode: Prevent running the container runtime and containers as root.

  These measures enhance runC container security but cannot prevent container escapes that exploit host kernel vulnerabilities.

• Isolate security risks with sandboxed containers (runV)

  

  Applications in a VM sandbox run on an independent guest OS kernel. Even if the guest kernel is compromised, the impact stays within that sandbox and does not affect the host or other containers. Combine sandboxed containers (runV) with Terway NetworkPolicy to configure pod-level access policies for full system, data, and network isolation.

Scenario 2: Address issues with runC containers, such as fault amplification, resource contention, and performance interference

Kubernetes co-locates containers on nodes, but cgroups do not fully resolve resource contention. Resource-intensive applications, such as CPU-intensive or I/O-intensive workloads, compete for resources, causing response time fluctuations. Issues such as memory leaks or core dumps increase node load. A container that triggers a host kernel bug can crash the node, and faults can cascade to the entire cluster. Sandboxed containers (runV) use independent guest OS kernels and hypervisors to address fault amplification, resource contention, and performance interference in runC containers.

Scenario 3: Multi-tenant services

Enterprises with multiple lines-of-business (LOBs) or departments often require strong tenant isolation. For example, finance workloads may require dedicated environments separate from non-security-sensitive applications. Traditional runC containers cannot effectively prevent security risks from untrusted applications. Common approaches include:

• Multiple single-tenant clusters: Separate finance clusters from non-security-sensitive clusters.

• A single multi-tenant cluster: Separate LOB applications into namespaces with dedicated nodes per LOB. Multi-tenant isolation relies on resource quotas, network policies, and other features. This approach uses fewer control planes and lower management costs than multiple clusters, but does not solve wasted node resources from low utilization by some tenants.

  

Sandboxed containers (runV) isolate untrusted applications in VM sandboxes, eliminating container escape risks and enabling mixed workloads on all nodes:

• Reduces resource scheduling complexity.

• Nodes serve multiple businesses, reducing resource fragmentation, improving utilization, and lowering cluster costs.

• Sandboxed containers (runV) use lightweight VMs and deliver runC-comparable performance.

Technical exchange & Q&A

Limitations

OS support matrix