This topic describes the benefits and use scenarios of Sandboxed-Container. This topic also compares Sandboxed-Container of Container Service for Kubernetes (ACK) with open source Kata Containers. This helps you understand the benefits of Sandboxed-Container.
Background information
Sandboxed-Container is an alternative to the Docker runtime environment. Sandboxed-Container supports the following features:
Sandboxed-Container allows your applications to run in a sandboxed and lightweight virtual machine. This virtual machine is equipped with a dedicated kernel and provides better isolation and enhanced security.
Compared with open source Kata Containers, Sandboxed-Container is optimized in terms of storage, networking, and stability.
You can use Sandboxed-Container to isolate untrusted applications and applications of different tenants for higher security. You can also use Sandboxed-Container to isolate applications with faults and applications with degraded performance. This minimizes the negative impact on your service. In addition, Sandboxed-Container offers the same user experience as Docker in terms of logging, monitoring, and elastic scaling.
Benefits
Compared with Docker, Sandboxed-Container has the following benefits:
Strong isolation based on sandboxed and lightweight virtual machines.
File Storage NAS (NAS) file systems and disks can be mounted to Sandboxed-Container. This provides the same storage performance as storage volumes that are mounted to the host.
Compatibility with runC in terms of application management.
High performance, which is up to 90% performance of runC.
The same user experience as runC in terms of logging, monitoring, and storage.
Supports RuntimeClass.
Fewer requirements on technical expertise and skills of using virtual machines.
Higher stability than Kata Containers.
Comparison between Sandboxed-Container and Kata Containers
Sandboxed-Container outperforms Kata Containers. The following table describes the differences between Sandboxed-Container and Kata Containers.
Item | Category | Sandboxed-Container V2 | Kata Containers |
Amount of time consumed to start a sandbox | About 150 ms | About 500 ms | |
Additional overhead of sandboxes | Low | High | |
Root file system | virtio-fs. Performance: ☆☆☆☆ | 9pfs. Performance: ☆ | |
Volume | HostPath/EmptyDir | virtio-fs. Performance: ☆☆☆☆ | |
Disks with block storage | virtio-fs. Performance: ☆☆☆☆ | ||
NAS |
| ||
Object Storage Service (OSS) | virtio-fs. Performance: ☆☆☆☆ | ||
Network plug-in |
| Flannel | |
Monitoring and alerting |
| Monitoring of disks and network conditions is unavailable for pods that use Sandboxed-Container. | |
Stability | ☆☆☆☆☆ | ☆☆ | |
Use scenarios of Sandboxed-Container
This section describes the use scenarios of Sandboxed-Container.
Scenario 1: Sandboxed-Container can run untrusted code and applications in isolated containers. This is not supported by containers in runC.
Security risks of runC
runC isolates containers by using namespaces and control groups (cgroups). This exposes containers to security risks.
All containers on a node share the host kernel. If the kernel has a vulnerability, malicious code may escape to the host and then infiltrate the backend network. Malicious code execution may cause privilege escalation, compromise sensitive data, and destroy system services and other applications.
Attackers may also exploit application vulnerabilities to infiltrate the internal network.
You can implement the following measures to reduce the security risks of containers in runC.
Seccomp: filters system calls.
SElinux: limits the permissions of container processes, files, and users.
Capability: limits the capability of container processes.
Rootless mode: prohibits users from running container runtimes and containers as the root role.
The preceding measures can enhance the security of containers in runC and reduce attacks on the host kernel by using malicious containers. However, container escapes and host kernel vulnerabilities remain unresolved.
Sandboxed-Container prevents potential risks based on container isolation
In a Sandboxed-Container runtime environment, applications that have potential security risks are deployed on sandboxed and lightweight virtual machines. Each of the virtual machines has a dedicated guest OS kernel. If a security vulnerability is detected on a guest OS kernel, the attack is limited to one sandbox and does not affect the host kernel or other containers. The Terway network plug-in allows you to define networking policies for pods. This enables system isolation, data isolation, and network isolation for sandboxed containers.
Scenario 2: Sandboxed-Container resolves common issues of runC containers, such as fault spreading, resource contention, and performance interference.
Kubernetes allows you to deploy different containers on a single node with ease. However, cgroups are not optimized to address resource contention. Resource-intensive applications such as CPU-intensive and I/O-intensive applications may compete for the same resources. This causes significant fluctuations in response time and increases the overall response time. Exceptions or faults on an application may spread to the hosting node and disrupt the running of the cluster. For example, memory leaks and frequent core dumps of an application may overload the node, and exceptions on a container may trigger a host kernel bug that results in an entire system failure. Through dedicated guest OS kernels and hypervisors, Sandboxed-Container resolves the issues that are common with runC containers. The issues include failure spreading, resource contention, and performance interference.
Scenario 3: Sandboxed-Container supports multi-tenant services.
You may need to isolate the applications of an enterprise that consists of multiple business lines or departments. For example, a financial department requires high security applications. However, other non-security-sensitive applications do not have high security requirements. Containers in runC fail to eliminate the potential risks that occur in untrusted applications. In this scenario, you can implement the following counter measures:
Deploy multiple independent single-tenant clusters. For example, deploy financial business and other non-security-sensitive business in different clusters.
Deploy a multi-tenant cluster and separate applications of different business lines by using namespaces. The resource of a node is exclusive to a single business line. This solution provides data isolation for coordination with the resource quotas and network policies to implement multi-tenant isolation. Compared with multiple single-tenant clusters, this solution focuses on fewer management planes and thus reduces management costs. However, this solution cannot prevent resource waste on nodes caused by the low resource utilization of some tenants.
Sandboxed-Container allows you to isolate untrusted applications by using sandboxed virtual machines. This prevents the risks of container escapes. This also allows you to deploy different containerized applications on each node, which brings the following benefits:
Resource scheduling is simplified.
A node is no longer exclusive to a service. This improves node resource usage and reduces resource fragments and cluster resource costs.
Sandboxed containers use lightweight virtual machines to provide almost the same performance as containers in runC.
