安全容器的发展与思考

9月26日云栖大会容器专场，阿里云智能刘奖和蚂蚁金服王旭两位资深技术专家进行了一场精彩纷呈的演讲，与各位观众分享探讨了安全容器技术的过去、今天和未来。以下文章根据演讲整理而成。

大家中午好，感谢大家在饥肠辘辘的中午不离不弃地来到我们的会场，我们带给大家的这段相声是关于安全容器技术的。我是王旭，半年前刚刚结束一段创业，和团队一起加入了蚂蚁金服，创业期间，2017年，我们在德州奥斯汀，和Intel OTC一起发布了Kata Containers安全容器项目，是这个项目的创始人之一；和我一起的是阿里云智能的奖哥，他是阿里云容器服务ECI的台柱子，也是rust-vmm开源项目的积极维护者。我们见证了容器安全和安全容器技术在争议中的发展，今天想要结合社区里和阿里云上安全容器的沿革，谈谈对安全容器技术未来发展的思考。

这次的分享分为四个部分：

当前容器技术应用和安全问题的现状
阿里云内外的安全容器技术发展的历程
阿里云服务中的安全容器
我们乃至整个社区正在做的技术努力

当前容器技术应用和安全问题的现状

众所周知，容器化、微服务化、云原生化是当前IT系统演进的趋势。根据Portworks和Aqua Security的调查报告显示，被调查的大多数企业都不是正在使用容器，就是考虑使用容器。

上午过来空闲时和刚才演讲的Chris聊天的时候，他也提到，今年年底San Diego的KubeCon会预计有一万两千多人来参会，他还特别提到示我一点：云原生化不仅是改变已有应用的架构，更是促进了更丰富的服务的开发，IT系统的服务规模是在加速提升的。

不过，尽管容器技术炙手可热，但挑战还是存在的。这页引用了一个tripwire调查报告，来源链接在这里，可以看到，大概有半数的企业，尤其是运行了100个以上容器的企业，认为他们的容器是有安全漏洞的，当然，还有很大比例的人表示并不确认他们的容器是否有安全漏洞。我们都知道，安全不仅是个技术问题，也是个信心问题，粉红色字的这段就是这个意思，因为对容器安全的担心，42%的受访者是无法全身心地拥抱容器生态的。

当然，我得说，关心安全问题是个好的信号，因为只有当你准备把一项技术真正用于生产环境的时候，才会从安全角度去认真审视它。和其他领域差不多，容器安全也是一项端到端的技术，从容器镜像本身的安全性和完整性，到运行容器的软硬件平台的基础设施安全性，再到容器运行时引擎的安全性都需要被照顾到，哪个都可能成为最短的那根板子。

阿里云内外的安全容器技术发展历程

说到容器的安全，我们可以回到容器的春秋战国时期了，不谈遥远的FreeBSD Jail和Solaris Zone，我们从最终进入Linux Kernel的这组Namespaces和cGroups来看，这套容器技术实际上同样是从进程调度的角度入手，对内核进行的功能扩展，优势上来说，操作界面很Linux、很方便，开销也很低，可以被用来无负担地套在已有应用外面来构建隔离的环境，并且是纯软件方案，不和其他层面已经有的物理机、虚拟机相冲突。然而，它的问题也在于它仍然是一个Linux Kernel的一个部分，已经有的Linux的隔离安全问题无法根除仍然存在，甚至可能因为新加入功能而被放大。所以，2015年西雅图的LinuxCon上，Linus在Keynote上接受访问的时候，就直接大嘴说出，Bug是没有办法的，要安全必须要有隔离层。

隔离层，这里所谓隔离层就是让应用容器运行在自己的内核之上，不和其他容器共享。这里面最简单的方案就是把容器放在虚拟机里跑（左1），这种方式不需要对软件栈做改动，只是让同一个用户的容器跑在自己的虚拟机里，但这样带来的问题，除了额外的开销之外，还有两层的维护复杂度。

另一种源远流长的独立内核的方案是unikernel（右1），让应用自己带上自己的内核，这种方式的好处是最简化的LibOS不仅可以有更小的开销，也可以有更小的攻击面，但阻止它被更广泛应用的问题在于它往往需要修改应用，兼容性永远是平台技术被采纳的最大障碍。所以，针对未修改的应用的安全容器方案就落在了中间两种方案——MicroVM和进程虚拟化上，前者是使用了轻量级虚机和裁剪过的Linux内核，在保证兼容性的前提下尽量降低运行时和维护的开销，而后者则是使用一个特定的内核来提供Linux ABI，直接虚拟化进程的运行环境，为Linux应用尽量提供最大兼容性。

Kata Containers就是这样一个MicroVM的安全容器方案，首先，对应用来说，这是一个兼容runC的容器运行时引擎，可以被kubernetes通过containerd/CRI-O调用，可以直接运行任何Docker Image或OCI Image。但与runC不同它使用了硬件虚拟化能力，直接面对用户应用的不再是宿主机的内核，而是一个独立的装在虚拟机里的内核，即使有未知的安全漏洞导致这个内核被攻击，攻击者仍然无法轻易突破虚拟化技术构建的沙箱。Kata Containers项目由我们和Intel一起在2017年开源，去年4月份成为OpenStack基金会旗下的7年来第一个顶级OpenInfra开放基础设施项目。作为一个社区化项目，这个项目还有很多阿里云和蚂蚁以外的开发者，目前项目正在讨论2.0版本的路线图，也欢迎大家为项目贡献代码和需求。

从技术上说，在Kubernetes生态里，Kata Containers可以和runC一样对接containerd和CRI-O这样的CRI Daemon，目前我们推荐的接口是去年暑假在containerd社区首先引入的Shim V2 API，这个API目前也被CRI-O所支持里，Kata 是第一个正式支持这个新接口的容器引擎，通过这个接口，每个Pod的额外Kata辅助进程只有一个，不论Pod里面有多少容器，这对宿主机调度器也是比较友好的。Shim会通过vsock控制MicroVM里面的agent来管理Pod里面的OCI容器，这里，社区版本的Kata支持的VMM包括了Qemu和AWS开源的FireCracker，前者功能更丰富、兼容性更好，后者更轻小，根据我们阿里巴巴的“既要、又要、还要”的精神，你不需要舍弃哪一个，用上Kubernetes的RuntimeClass，你可以为每个Pod指定要用的VMM。具体的Howto类的细节，你可以看我们github上的文档也可以在slack channel里讨论，遇到问题别忘了开issue，这也是对社区的巨大支持，不是只有写代码才算贡献开源的。

类似的基于MicroVM类技术的容器方案实际还有不少，耳熟能详的还有微软的Hyper-V Container和最近在Windows里集成的WSL2，从数量上说，这类方案是目前的主流，最重要的原因就是对一般Docker Image的完美兼容性，而这种方案里最正统的开源方案当然就是我们Kata了。当然基于进程虚拟化的方案有很多亮点的，其中最亮的当然是Google开源的gVisor了，因为它开源的时候的Google的项目技术Leader就是现在我的老板，何征宇。

阿里云安全沙箱的历史、现状以及未来

从2013年到2019年的6年时间里，容器技术及生态每年都往前迈进一大步，经历了从提出技术理念、构建合作生态到商业落地应用的飞速发展周期，到达了论坛开篇演讲中所提到的“拐点已至”的阶段。

让我们一起简要回顾一下阿里云安全容器与安全沙箱技术的发展历史。

Docker理念被提出一年多之后，2015年产业界开始共同推进容器技术及生态。阿里云、Hyper.sh和Intel等都意识到runCc的局限性，开始基于虚拟机技术构建容器的安全运行环境。
经过一年的研发期，2016年安全容器技术开始进入生产环境。阿里云研发的vLinux技术在MaxCompute场景落地应用，Hyper.sh也基于runV对外提供容器服务。这一年还发生一个非常重要的事情，k8s定义了CRI接口规范，用于对接多种形态的容器运行环境，从而为安全容器和k8s生态的融合提供坚实的基础。

2017年微软开放了ACI容器服务，阿里云也研发了基于虚拟机的容器服务。2017年12月，Hyper.sh runV项目和Intel Clear Container项目宣布合并成立Kata Container项目，共同推进基于硬件虚拟化的安全容器运行环境，实现“虚拟机的安全，容器的速度”。

2018年阿里云开放基于虚拟机的容器服务，同时开始研发基于MicroVM路线的安全沙箱技术。这一年Google开源了gVisor，AWS开源了firecracker。

2019年，阿里云安全沙箱技术商用上线，支持ECI、ACK、SAE边缘计算等多种业务。Intel创立了Cloud Hypervisor项目，致力于为云原生场景打造专用的hypervisor。

从2017年底开始，Kata、gVisor、Firecracker、Nabla、Cloud Hypervisor等开源安全容器技术不断涌现，技术进入井喷期。
非常高兴的是Hyper团队今年加盟阿里数字经济体，一起为我们的客户打造安全可靠的容器运行环境。

刚才介绍中提到了不同的容器runtime技术，可能大家心中会有个疑问，这些技术的关系和区别是什么了？我以生活中的常见租房为例来打个比方，方便大家理解容器runtime的区别。

首先聊聊Fircracker，Firecracker并不是一个container runtime，而是一个轻量化的VMM。

rRunCc就类似群租房，装修简单、利用率高，但是隔音、安全和入住体验稍差。
使用containerd/CRI-O接入kubernetes的Kata 1.x/gVisor就类似合租房，每个租户都有自己独立的卧室，但是客厅、厨房、卫生间还是共享的。

- 阿里云安全沙箱类似酒店式公寓，提供全功能的、标准化、带客房服务的入住体验。
-VM + containerd则类似租普通住房，公摊面积大，还可能需要自己装修。
-神龙裸金属则类似豪华别墅，极致的入住体验。
-阿里云安全沙箱就是致力于打造酒店式公寓，为客户提供拎包入住式的容器服务。

我们乃至整个社区正在做的技术努力

正如大家所了解的，阿里巴巴既有像淘宝、天猫、高德等众多面向个人消费领域的业务，也有阿里云、钉钉等面向企业服务的业务。作为底层基础技术的安全沙箱技术，需要支持多种应用场景。综合各种业务场景，大致能归纳出三种典型的应用模式：

第一种是面向公共云服务的容器服务。这种应用场景下，我们既需要保证基础设施的安全性，也需要严格保证客户的数据安全以及租户之间的隔离性。我们需要提供酒店是公寓和不是群租房或合租房。

第二种是需要在一台服务器上同时执行可信代码和不可信代码的场景。比如，需要执行用户上传的代码、无源代码的可执行文件或未经审计的开源代码的情况。这是安全沙箱的最典型用法，通过安全沙箱构建一个带安全边界的执行环境，把不可信代码限定在这个受限的执行环境中，从而保护系统中的其它组件。

第三种是多种业务混合部署的场景。为了提高资源利用率，主流技术思路之一是把在线业务和离线业务混合部署在相同的服务器上，利用在线服务的剩余资源来为离线任务服务。这是相当挑战的一个任务，传统做法是通过为在线任务预留足够的资源来保证在线服务的服务体验。那么，混部的情况下如何保证在线任务的服务体验呢？思路也很简单，给予在线业务较高的优先级。但是这还不足够，由于共享内核，内存分配、IO调度方面，离线任务还是会经常干扰在线任务。所以把离线任务放入独立的安全沙箱，实现资源隔离、故障隔离、环境隔离。

基于以上的业务需求，我们研发了阿里云安全沙箱技术，立足于阿里云成熟稳定的基础设施、基于MicroVM技术路线，为业务构建安全、可靠、轻量、生态兼容的容器runtime。

阿里云安全沙箱是基于MicroVM构建的安全容器runtime。首先它是一个基于硬件虚拟化技术的MicroVM，采用了深度定制优化hypervisor，极简的虚拟机设备模型，VMM基本上不访问guest memory。其次阿里云安全沙箱也是一个容器runtime，提供镜像分发、镜像管理、容器网络、容器存储，完全兼容OCI和CRI规范。

阿里云安全沙箱的安全来源于新型安全系统语言、极小而可控的源代码、极简的设备模型、深度定制的Hypervisor以及安全加固的阿里云Linux for Sandbox系统。

那么，阿里云安全沙箱能给客户带来什么价值呢？除了安全可靠外，阿里云安全沙箱还会给客户带来极速启动、极致弹性和低资源开销。实际测试数据表明，去掉下载容器镜像的时间，阿里云安全沙箱启动容器实例耗时小于500毫秒，在96CPU的系统上每秒启动实例数量大于200个，平均每个microvm的内存资源好用小于2.5M。

那么安全容器的下一步挑战是什么呢？用户理想中的容器运行runtime是什么样的呢？
1）超越虚拟机的安全性。
2）像Native本机运行一样的性能。
3）像runC一样的兼容性和易用性。

在过去，蚂蚁金服和阿里云就是安全容器的积极贡献者，在接下来的时间里，我们仍然会继续和开源社区紧密合作，我们会开放地和社区共同制定Kata Containers 2.0的路线图，把我们的在容器和云服务领域的最佳实践反馈给社区，将通用性的技术贡献到Kata Contaienrs和Rust-VMM社区，保证阿里巴巴CloudSandbox和社区的一致性，我们期望通过拥抱开源、融入开源和回馈开源的方式，和业界一起为广大用户打造一个安全、可靠、高效和兼容生态的容器runtime。