iSulad 与 Kuasar 双剑合璧：让你单节点轻松运行 10w+ 个 WASM 沙箱

沙箱技术背景介绍
不管是 VM、Container，还是 WASM 沙箱，它们本质都是利用了沙箱技术，实现将不信任程序隔离在沙箱环境中执行，避免影响其他应用和服务。沙箱技术大致可以分为两类[1]：

基于隔离的沙箱：该类型的沙箱将应用的执行环境从操作系统环境中隔离出来，形成一个独立的执行环境。

图 1 基于隔离的沙箱

基于规则的沙箱：该类型的沙箱并不是完全关注对于应用程序的隔离，而是用规则的方式控制每个应用的权限，基于规则的沙箱之间可以分享操作系统的逻辑资源。

图 2 基于规则的沙箱

沙箱安全隔离能力对比分析

图 3 VM 安全隔离架构

虚拟机的安全隔离能力可以简单总结为水平和垂直方向的多维度隔离。在水平维度上看，虚拟机 Hypervisor 层水平分隔不同的 Guest OS，保证 Guest OS 的漏洞不会影响其他的 Guest OS；在垂直维度上看，Hypervisor 层分隔不同的操作系统（ Guest OS 和 Host OS 的内核不共享）和物理硬件，控制 Guest OS 中漏洞不会影响到宿主机上的操作系统和物理硬件。

Container

图 4 Container 安全隔离架构

容器的安全隔离能力也是借鉴了 VM 的这种分隔的思想，将不同的应用水平分隔在不同容器环境中运行，如果容器中的应用存在漏洞，它是不会直接影响到其他应用。

但是在垂直分隔的维度上，容器和容器之间共享同一个内核，没有带来完全意义上的隔离，因此如果一个容器触发了一个内核漏洞导致内核崩溃，就会导致整个系统上的其他容器中的应用也会受到影响。

WASM沙箱

图 5 WASM/WASI 安全隔离设计

WASM 从语言设计上就利用了 SFI 软件故障隔离的概念（前面介绍的第一种基于隔离的沙箱技术），将 WASM 应用程序的故障都隔离约束在自己单独的线性地址空间中，确保应用程序不会跳转到故障域之外的地址空间，实现安全隔离的目的。并且 WASM 的虚拟指令集都是纯计算指令集，不会像 VM 或 Container 需要涉及到对内核或者硬件资源的访问，因此通过 SFI 机制就可以保障程序的漏洞不会逃逸和扩散。

WASI[2] 概念则是基于前面提到的第二种基于规则的沙箱技术或者说 capability-based 的安全模型，用规则的方式控制每个 WASM 应用的权限，需要什么能力，就需要显示地为应用配置对应的规则。

所以说 WASM+WASI 的沙箱技术是双剑合璧，汲取了基于隔离沙箱技术和基于规则沙箱技术的优点，提供的轻量级沙箱技术。

WASM沙箱接入云原生生态
WASM 沙箱在保证安全隔离的前提下，可以获得毫秒级冷启动速度，如果接入到云原生生态中，容器运行时首先要考虑的问题是