This topic describes the advantages and application scenarios of Sandboxed-Container and provides a comparison between Sandboxed-Container and open source Kata Containers. This allows you to learn more about the benefits of Sandboxed-Container.
Background information
Sandboxed-Container provides an alternative to the Docker runtime environment. It 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
- Strong isolation based on sandboxed and lightweight virtual machines.
- Network Attached Storage (NAS) file systems and Alibaba Cloud 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 that corresponds to 90% performance of applications based on runC.
- The same user experience as runC in terms of logging, monitoring, and storage.
- Support for RuntimeClass.
- Easy to use with limited expertise that is required to use virtual machines.
- Higher stability than that provided by Kata Containers.
Comparison between Sandboxed-Container and Kata Containers
Sandboxed-Container outperforms Kata Containers in the following aspects.
| Item | Category | Sandboxed-Container | Kata Containers |
|---|---|---|---|
| Sandbox startup time consumption | About 150 ms | About 500 ms | |
| Root file system | OverlayFS over virtio-fs. Performance: ☆☆☆☆ | OverlayFS over 9pfs. Performance: ☆☆ | |
| Volume | HostPath | Disks are mounted to Sandboxed-Container over 9pfs. Performance: ☆☆ | Disks are mounted to Kata Containers over 9pfs. Performance: ☆☆ |
| EmptyDir | The volume is mounted to Sandboxed-Container over virtio-fs. | By default, the volume is mounted to Kata Containers over 9pfs. | |
| Cloud disks |
| Cloud disks are mounted to Kata Containers over 9pfs. Performance: ☆☆ | |
| NAS |
| NAS file systems are mounted to Kata Containers over 9pfs. Performance: ☆ | |
| Network Plug-in |
| Flannel | |
| Monitoring and alerting |
| Monitoring of disks and network conditions is unavailable for pods that host Sandboxed-Container. | |
| Stability | ☆☆☆☆☆ | ☆☆ | |
Applicable scenarios of Sandboxed-Container
This section describes the applicable 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 threats.
- All containers on a node share the host kernel. If a kernel vulnerability is exposed, 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 security risks of containers in runC.- Seccomp: filters system calls.
- SElinux: restricts the permissions of container processes, files, and users.
- Capability: limits the capability of container processes.
- Rootless mode: forbids users to use root permissions to run the Docker daemon and containers.
The preceding measures can enhance the security of containers in runC and reduce attacks on the host kernel by 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.
- Security risks of runC
- Scenario 2: Sandboxed-Container resolves common issues of runC containers, such as fault spreading, resource contention, and performance interference.
Kubernetes provides easy deployment of different containers on a single node. However, cgroups are not optimized to address resource contention. Resource-intensive applications (such as CPU-intensive, 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 total 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 entire system failure. Through dedicated guest OS kernels and hypervisors, Sandboxed-Container addresses 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 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 brought by 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 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 avoid resource waste on nodes caused by 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.
