This topic describes the benefits and applicable scenarios of Sandboxed-Container and provides a comparison between Sandboxed-Container and open-source Kata Containers to help you better understand Sandboxed-Container.
Sandboxed-Container allows you to run applications in a sandboxed and lightweight virtual machine that has a dedicated kernel. This enhances resource isolation and improves security.
Compared with open-source Kata Containers, Sandboxed-Container is optimized in terms of storage, networking, and stability.
Sandboxed-Container can isolate untrusted applications, applications with faults, applications with degraded performance, and applications of different tenants. Sandboxed-Container provides enhanced security. Sandboxed-Container has minor impacts on application performance, and offers the same user experience as Docker in terms of logging, monitoring, and elastic scaling.
- Strong isolation based on sandboxed and lightweight virtual machines.
- Network Attached Storage (NAS) file systems and Alibaba Cloud disks can be directly mounted. This offers the same storage performance as when storage volumes are mounted to the host.
- Good compatibility with runC in terms of application management.
- High performance that corresponds to 90% the performance of applications based on runC.
- The same user experience as that provided by containers in runC in terms of monitoring, logging, and storage.
- Support for RuntimeClass.
- Less requirements on technical expertise and skills of using 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.
|Root file system||Device Mapper. Performance: ☆☆☆☆☆||OverlayFS over 9pfs. Performance: ☆☆|
|Volume||HostPath||over 9PFS||over 9PFS|
|EmptyDir||By default, the volume is mounted over 9pfs. We recommend that you specify a Memory type storage medium to mount a tmpfs (RAM-backed filesystem). This allows you to store data in volatile memory (non-persistent storage device).||By default, the volume is mounted over 9pfs. We recommend that you specify a Memory type storage medium to mount a tmpfs (RAM-backed filesystem). This allows you to store data in volatile memory (non-persistent storage device).|
|Disk||Disks are directly mounted to sandboxed containers. Performance: ☆☆☆☆☆||Disks are mounted to Kata containers over 9PFS. Performance: ☆☆|
|NAS||NAS file systems are directly mounted to sandboxed containers. Performance: ☆☆☆☆☆||NAS file systems are mounted to Kata containers over 9pfs. Performance: ☆|
|Monitoring and alerting||
||Lack of disk and network monitoring for pods that host sandboxed containers.|
Applicable scenarios of Sandboxed-Container
This section describes the applicable scenarios of Sandboxed-Container.
- Scenario 1: Sandboxed containers can run untrusted code and applications in isolated
containers. This is not supported by containers in runC.<?oxy_comment_end?>
- Security risks of runC
You can implement the following measures to reduce security risks of containers in 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, destroy system services and other applications, and compromise sensitive data.
- Attackers may also exploit application vulnerabilities to infiltrate the internal network.
- Seccomp: filters system calls.
- SElinux: restricts the permissions of container processes, files, and users.
- Capability: limits the capability of container processes.
- dockerd rootless mode: forbids users to run the Docker daemon and containers as root users.
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 through 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 access 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 makes it easy to deploy different containers on a single node. However, cgroups cannot address resource contention properly. 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 even disrupt the running of the entire 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, including failure spreading, resource contention, and performance interference.
- Scenario 3: Sandboxed-Container supports multi-tenant services.
An enterprise may have multiple business lines or departments where they want to isolate their own applications from other applications. For example, a financial department does not expect other non-security-sensitive applications to run in its own physical environment. Containers in runC fail to eliminate the potential risks brought by untrusted applications. In this scenario, you may implement the following common measures:
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:
- 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.
- 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.