云计算时代容器安全综述-增强容器隔离性（下）

咱们在上篇中介绍了如何限制容器可执行的系统调用来解决当容器变节后，来控制爆炸半径，接下来咱们将视角抽象一层，看看有哪些沙箱技术可以用来约束容器实例的行为。沙箱技术的驱动力主要来自于业界对VM虚拟机提供隔离机制在安全视角的认可，但是想推动技术来使虚拟机更加的轻量级，特别是让虚拟机可以适配大规模容器化部署场景下应用实例的灵活性，快速启动，临时性特征。

Docker这样的容器化部署方案天生的逻辑隔离性以及安全边界的问题对谷歌也造成了困扰，为了解决这些问题，谷歌在2018年年中发布了一款新的沙箱容器运行时gVisor，提供了比容器更安全的隔离，比VM虚拟机更加轻量级。gVisor设计的核心是：隔离。大白话讲就是解决在容器中运行的应用程序对宿主机内核的依赖，这也是容器化部署被吐槽最多的点，虽说操作系统内核（Linux操作系统）也在不断的增强其安全性，但是由于复杂性的原因（这也是笔者一直秉承的另外一个观点，复杂性和安全性有较强的关联），操作系统内核中的安全风险持续的被披露。

而谷歌gVisor基本上隔离了恶意代码对宿主机上操作系统内核的恶意访问，采用的实现方式是进程虚拟化。具体来说，gVisor在内核之外实现一个称作内核进程的组件：Sentry，提供了大部分对Linux内核调用的实现，并将容器对操作系统内核访问请求定向到这个Sentry组件。不过Sentry并不是一个完整的进程级别的内核实现，也就是说gVisor虽然截获了容器实例对操作系统的所有调用，但是部分调用还是要代理到底层宿主机上的操作系统内核来处理并返回结果给容器实例。

另外谷歌gVisor的这种实现也被称作是半虚拟化（paravirtualization），半虚拟化的含义是在用户空间中重新实现操作系统指令，以期在用户空间中满足进程某些系统调用。这样做的好处显而易见，无论是从效率还是安全性方面，都得到的极大的提升。

从上边的描述中笔者希望大家能够体会到gVisor提供了近乎虚拟机级别的隔离，但是从实现原理角度读者也能看到，gVisor只是改变了容器实例中运行的应用程序系统调用的方式，容器实例的隔离还是重度依赖于三个支柱：命名空间Namespace，CGroups以及chroot。虽然说gVisor的提升了容器实例的隔离性，由于gVisor的实现并没有包含所有的系统调用，因此并不是所有的应用程序都可以部署到gVisor中，因此这个技术可以看成是过渡，也是我们接下来要讨论的Kata容器的基础。

有了对gVisor的了解后，咱们接着来看几种真正虚拟机级别的容器实例隔离技术，先从Kata Container开始。容器实例和普通的进程没有太大的区别，笔者在介绍容器本质系列文章的时候，反复的提这个概念，容器实例本质上就是被“动过手脚”的普通进程而已。而Kata Containers的实现方式就稍微有点不同了，具体来说，Kata Container将容器实例实例运行在隔离的虚拟机中。这种方式就如同大家熟知的“中间路线”这样的概念，同时享受了将应用程序运行在OCI兼容的容器实例中，以及虚拟机带来的良好隔离性。

由于Kata Conatiners将应用程序运行在独立的虚拟机中，因此可以充分享受硬件虚拟化带来的第二层防御，安全性得到的较大的提升。Kata Containers实现原理是在容器运行时和虚拟机之间通过代理来协作，当我们创建一个新的容器实例的时候，容器运行时通过代理将运行应用程序的请求代理给QEMU这样的虚拟机管理软件来运行。这种模式能支撑云原生架构下应用程序的前提是虚拟机足够轻量级，启动速度可以接受。阿里云，AWS等厂商针对这个问题给出了解决方案，对于阿里云来说，ACK服务中包含了安全沙箱v2，这个轻量级的虚拟化技术。安全沙箱v2是阿里云全新自研的基于轻量虚拟机技术的安全容器运行时，在提供隔离性的同时，由于虚拟机的体量很小，因此资源overhead降低了90%，沙箱启动速度提升了3倍，单机密度提升了10倍。感兴趣的同学可以参考阿里云的相关文档。

AWS也提供了一种叫Firecracker的轻量级虚拟机技术，专门用来运行容器化应用，当然启动速度相比传统的虚拟机，有了数量级级别的提升。可能大家会问，启动速度真的那么重要吗？对于需要支持高并发的应用来说，启动速度是系统弹性的前提。咱们来举个例子，假设我们基于阿里云的ACK部署了一套电商系统，核心的服务购物车和交易中心为独立部署的服务。由于微博出现某种热点事件，导致访问系统的用户数量快速增加，作为系统的负责人，你通过ARMS，日志服务等监控手段第一时间收到通知后，决定对系统进行临时扩容。而扩容的速度其实很大一部分取决于实例的启动速度。如果我们拉起新应用的速度在分钟级别，那么很厚可能就会造成现有系统被打垮（没有使用AHAS做限流降级的前提下），或者很多用于收到系统返回的错误，导致商机白白的流失。

由于虚拟机本身的技术限制因素，包括启动操作系统，初始化操作系统等，那么阿里云安全沙箱v2和AWS的Firecracker是如何做到极致的启动速度呢？这里边关键还是在内核，因为对于运行在容器中的应用程序，内核中的大部分功能都使用不到。因此阿里云安全沙箱v2和AWS的Firecracker使用的镜像中，操作系统内核都是做过定制，清除了还运行容器应用无关的部分，只留下运行容器应用有关的功能，因此这种类型的轻量级虚拟机可以把启动时间做到100ms。并且这种轻量级的虚拟机已经经过阿里云多年的生产系统验证，无论是从安全性还是稳定性方面，都可以得到保障。读到这里好奇心强的同学可能会问，具体把内核中的哪些功能给清除了呢？我们都知道模拟系统硬件是整个虚拟化机制中最耗时最复杂的部分，而这些轻量级的虚拟机技术主要是围绕这部分做了优化，由于大部分容器化部署的应用都只使用部分硬件，比如存储和网络，因此简化的硬件虚拟化模型大大加速了虚拟机的尺寸和启动时间。

最后我们了解一下一种应用和操作系统结合的机制：Unikernels。这种机制的驱动力还是来自于操作系统本身，我们运行一个购物车服务，操作系统中大量的功能和模块本质上都不太需要，从资源使用率的角度来看，属于浪费。如果我们能够为应用程序定制特制的操作系统，比如只包含支持购物车应用运行的功能，那么不光是减小了资源使用，提升了应用的启动时间，同时也缩小了攻击面，一举三得，何乐而不为啊。而Unikernels就是这种思路的具体实现，通过创建包含应用和特定操作系统模块的软件机器镜像，来在Hypervisor上直接启动操作系统和之上的应用程序。这种模式的好处就是隔离性，和普通的虚拟机完全一致，并且由于对操作系统的模块做了精简，因此启动速度（轻量级的程度）简直可以和阿里云的安全沙箱v2想媲美。在将应用部署到Unikernels之前，我们需要将应用程序打包成兼容的机器镜像，这样虚拟机软件的Hypervisor就可以像拉起标准的Linux操作系统那样，启动应用程序。

好了，今天这篇文章就这么多了，希望通过这篇文章，大家对隔离性更好（安全性更高）的技术有全面的了解，特别是阿里云提供的安全沙箱v2轻量化虚拟机机制，是很多对安全性要求高企业的首选，如果读者的企业有这方面的需求，可以访问阿里云ACK服务的官方文档详细了解：https://help.aliyun.com/document_detail/142151.html。