杭州云栖，蚂蚁和阿里云的程序员说了场“相声”

蚂蚁金服过去十五年，重塑支付改变生活，为全球超过十二亿人提供服务，这些背后离不开技术的支撑。在2019杭州云栖大会上，蚂蚁金服将十五年来的技术沉淀，以及面向将来的金融技术创新和参会者分享。咱们将其中的优秀演讲整理成文并将陆续发布在“蚂蚁金服科技”公众号上，本文为其中一篇。

本文根据云栖大会容器专场演讲内容整理。

你们中午好，感谢你们在饥肠辘辘的中午不离不弃地来到咱们的会场，咱们带给你们的这段相声是关于安全容器技术的。我是王旭，半年前刚刚结束一段创业，和团队一块儿加入了蚂蚁金服，创业期间，2017 年，咱们在德州奥斯汀，和 Intel OTC 一块儿发布了 Kata Containers 安全容器项目，是这个项目的创始人之一；和我一块儿的是阿里云智能的奖哥，他是阿里云容器服务 ECI 的台柱子，也是 rust-vmm 开源项目的积极维护者。

咱们见证了容器安全和安全容器技术在争议中的发展，今天想要结合社区里和阿里云上安全容器的沿革，谈谈对安全容器技术将来发展的思考。 此次的分享分为四个部分：

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

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

众所周知，容器化、微服务化、云原生化是当前 IT 系统演进的趋势。根据 Portworks 和 Aqua Security 的调查报告显示，被调查的大多数企业都不是正在使用容器，就是考虑使用容器。 上午过来时和刚才演讲的 Chris 聊天的时候，他也提到，今年年末 San Diego 的 KubeCon 预计会有一万两千人来参会，他还特别提到一点：云原生化不只是改变已有应用的架构，更是促进了更丰富的服务的开发，IT 系统的服务规模是在加速提高的。 不过，尽管容器技术煊赫一时，但挑战仍是存在的。

能够看到，大概有半数的企业，尤为是运行了 100 个以上容器的企业，认为他们的容器是有安全漏洞的，固然，还有很大比例的人表示并不确认他们的容器是否有安全漏洞。咱们都知道，安全不只是个技术问题，也是个信心问题，粉红色字的这段就是这个意思，由于对容器安全的担忧，42% 的受访者是没法全身心地拥抱容器生态的。

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

安全容器技术发展历程

说到容器的安全，咱们能够回到容器的春秋战国时期了，不谈遥远的 FreeBSD Jail 和 Solaris Zone，咱们从最终进入 Linux Kernel 的这组 Namespaces 和 cGroups 来看，这套容器技术实际上一样是从进程调度的角度入手，对内核进行的功能扩展，优点上来讲，操做界面很 Linux、很方便，开销也很低，能够被用来无负担地套在已有应用外面来构建隔离的环境，而且它是纯软件方案，不和其余层面的物理机、虚拟机相冲突。

然而，它的问题也在于它仍然是 Linux Kernel 的一个部分，已有的 Linux 的隔离问题没法根除，甚至可能由于新加入功能而被放大。因此，2015 年西雅图的 LinuxCon 上，Linus 在 Keynote 上接受访问的时候，就直接说出，Bug 是没有办法的，要安全必需要有隔离层。（原文为: The only real solution to security is to admit that bugs happen, and then mitigate them by having multiple layers）

隔离层，这里所谓隔离层就是让应用容器运行在本身的内核之上，不和其余容器共享。这里面最简单的方案就是把容器放在虚拟机里跑（左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 基金会旗下的七年来第一个顶级开放基础设施项目。做为一个社区化项目，这个项目还有不少阿里云和蚂蚁之外的开发者，目前项目正在讨论 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。具体的 How to 类的细节，你能够看咱们 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 等都意识到 runC 的局限性，开始基于虚拟机技术构建容器的安全运行环境。
• 通过一年的研发期，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
• runC 就相似群租房，装修简单、利用率高，可是隔音、安全和入住体验稍差
• 使用 containerd/CRI-O 接入 Kubernetes 的 Kata 1.x/gVisor 就相似合租房，每一个租户都有本身独立的卧室，可是客厅、厨房、卫生间仍是共享的
• 阿里云安全沙箱相似酒店式公寓，提供全功能的、标准化、带客房服务的入住体验
• VM + containerd 则相似租普通住房，公摊面积大，还可能须要本身装修

阿里云安全沙箱就是致力于打造酒店式公寓，为客户提供拎包入住式的容器服务。

咱们乃至整个社区正在作的技术努力

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

1. 第一种是面向公共云服务的容器服务。这种应用场景下，咱们既须要保证基础设施的安全性，也须要严格保证客户的数据安全以及租户之间的隔离性。咱们须要提供酒店式公寓而不是群租房或合租房。
2. 第二种是须要在一台服务器上同时执行可信代码和不可信代码的场景。好比，须要执行用户上传的代码、无源代码的可执行文件或未经审计的开源代码的状况。这是安全沙箱的最典型用法，经过安全沙箱构建一个带安全边界的执行环境，把不可信代码限定在这个受限的执行环境中，从而保护系统中的其它组件。
3. 第三种是多种业务混合部署的场景。为了提升资源利用率，主流技术思路之一是把在线业务和离线业务混合部署在相同的服务器上，利用在线服务的剩余资源来为离线任务服务。这是至关挑战的一个任务，传统作法是经过为在线任务预留足够的资源来保证在线服务的服务体验。那么，混部的状况下如何保证在线任务的服务体验呢？思路也很简单，给予在线业务较高的优先级。可是这还不足够，因为共享内核，内存分配、IO 调度方面，离线任务仍是会常常干扰在线任务。因此把离线任务放入独立的安全沙箱，实现资源隔离、故障隔离、环境隔离。

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

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

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

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

• 超越虚拟机的安全性
• 像本机运行同样的性能
• 像 runC 同样的兼容性和易用性

在过去，蚂蚁金服和阿里云就是安全容器的积极贡献者，在接下来的时间里，咱们仍然会继续和开源社区紧密合做。

咱们会开放地和社区共同制定 Kata Containers 2.0 的路线图，把咱们在容器和云服务领域的最佳实践反馈给社区，将通用性的技术贡献到 Kata Contaienrs 和 Rust-VMM 社区，保证阿里巴巴 CloudSandbox 和社区的一致性，和业界一块儿为广大用户打造一个安全、可靠、高效和兼容生态的容器 runtime。

---

本文做者：缪克卢汉

阅读原文

本文为云栖社区原创内容，未经容许不得转载。