linux沙箱隔离_为容器提供更好的隔离：沙箱容器技术概览

摘要

既然主流 IT 工业都在采用基于容器的基础设施(云原生方案)，那么了解这一技术的短板就很重要了。Docker、LXC 以及 RKT 等传统容器都是共享主机操作系统核心的，因此不能称之为真正的沙箱。这些技术的资源利用率很高，但是受攻击面积和潜在的攻击影响都很大，在多租户的云环境中，不同客户的容器会被同样的进行编排，这种威胁就尤其明显。主机操作系统在为每个容器创建虚拟的用户空间时，不同容器之间的隔离是很薄弱的，这是造成上述问题的根本原因。基于这样的现状，真正的沙箱式容器，成为很多研发工作的焦点。多数方案都对容器之间的边界进行了重新架构，以增强隔离。本文覆盖了四个项目，分别来自于 IBM、Google、Amazon 以及 OpenStack，几个方案的目标是一致的：为容器提供更强的隔离。IBM Nabla 在 Unikernel 的基础上构建容器；Google 的 gVisor 为运行的容器创建一个特定的内核；Amazon 的 Firecracker 是一个超轻量级的沙箱应用管理程序；OpenStack 将容器置入特定的为容器编排平台优化的虚拟机之中。下面对几个方案的概述，有助于读者应对即将到来的转型机会。

目前的容器技术

容器是一种对应用进行打包、分享和部署的现代化方式。与把所有功能打包为单一软件的单体应用相反，容器化应用或微服务的设计目标是专注于单一任务。容器中包含要完成这一任务所需的所有依赖项目(包、库和一些二进制文件)。正因如此，容器化应用是平台无关的，能够在任何操作系统上运行，并不在意其版本或者已部署软件。这给开发人员带来了极大的方便，再也不用为不同的客户和平台准备不同版本的软件了。因此也有了一个不太准确的想法：把容器当成了“轻量级虚拟机”。当容器在主机上完成部署之后，每个容器的资源，例如文件系统、进程和网络栈都会被安置在一个虚拟的隔离环境之中，其它容器无法访问这一隔离环境。这个技术能够在一个集群内同时运行几百或几千个容器，容器化应用能够轻松的通过复制容器实例的方式进行伸缩。

目前容器技术的发展，得益于两项技术的进步：Linux 命名空间以及 Linux Control Group(cgroup)。命名空间虚拟隔离的用户空间，并且给应用分配独立的系统资源，例如文件系统、网络栈、进程号以及用户编号等。在这个隔离的用户空间中，PID = 1 的应用程序控制了文件系统的根，并可以用 root 的身份运行。这个抽象的用户空间允许每个应用都不受同一主机上运行的其它应用的影响。目前有六个可用的命名空间：mount、inter-process communication (ipc)、UNIX time-sharing system (uts)、process id (pid)、network 以及 user。另外还提议了两个额外的命名空间，分别是 time 和 syslog，但是 Linux 社区还在对其规范进行定义。Cgroups 为应用进行硬件的限制、优先级、审计和控制。CPU、内存、设备和网络都是硬件资源。当把命名空间和 cgroup 组合起来，我们就可以在单一主机上，安全的运行多个应用，并且其中的每个应用都有各自的隔离环境，这是容器的的根本。

虚拟机和容器之间的区别是，虚拟机是硬件层的虚拟化，而容器是操作系统级的。虚拟机管理器(VMM)为每个虚拟机模拟一个硬件环境，容器运行时则为每个容器模拟一个操作系统。虚拟机共享主机的物理硬件，容器会共享主机操作系统的内核以及物理硬件。因为容器从主机上共享的资源更多，它们对存储、内存以及 CPU 的利用比虚拟机更加有效。然而共享越多，其代价就是容器之间、容器和主机之间的信任边界就越模糊。图 1 中描述了虚拟机和容器的架构差异。

相对于命名空间隔离技术而言，虚拟化硬件隔离通常会有更好的安全边界。容器(进程)中逃出的攻击者，往往比虚拟机中逃出的攻击者具有更大的威胁。命名空间和 cgroup 的弱隔离是造成这种风险的原因。Linux 为每个进程中加入新的属性字段，通