安全容器综述

【导读】容器安全很火，这个词指什么？通过什么手段达到容器安全的效果？本文做了详细介绍。

最近两年安全容器非常的火，这篇文章就带大家来看一下何谓安全容器技术，以及目前主流的安全容器都有哪些，最后还会附上很多有价值的参考链接。本文将通过如下的方式进行展开：

1. 何谓安全容器
2. 安全容器技术的思路是什么样的
3. 目前的主流安全容器有哪些

1. 何谓安全容器

显然，安全容器这个词是自解释的（self-explaining），而伴随这个词的一个更常见的问题是为什么容器是不安全的，以至于我们需要安全容器技术。

以 Docker 为例，我们来看一下容器的运行时是什么样的。简而言之，Docker 技术通过 NameSpace 技术来实现进程间的隔离，使用 CGroup 技术来实现进程的资源使用限制，通过 RootFS 技术来实现统一的容器进程视图。这里面的 NameSpace 和 CGroup 都是 Linux 内核提供的技术。容器安全的核心问题就是容器进程都共享同一个宿主机内核，一旦某个进程出现问题就会直接或者间接地影响其他容器进程。比如某个容器进程触发了操作系统 Panic，那么这台宿主机上面的所有进程都将受到影响。不要认为 Linux 操作系统很健壮，我们可以搜索一下 Linux Kernal 代码里面的类似 panic 这种字样，发现还是有很多情况下会导致内核 panic 的。我们日常使用中感觉不到是因为 panic 的概率非常小，但是一旦数量上去之前，很小的概率最后导致发生的次数可能都是不容忽视的。

我们知道 Docker Daemon 也是以 Root 权限启动的，这对于 Linux Kernel 无疑是一个不可忽视的风险。尽管 Docker 在 19.03 版本之后推出了一个实验性质的特性：容许 Docker Daemon 进程可以以非 Root 权限启动，从而来提供 Docker 的隔离性。但是由于其带来了多余的性能损耗，实际上也只能在特定的场景下使用。

其次是 Linux Kernel 也不能保证是绝对安全的。像 Linux 这种庞大的系统，我们很难通过一种完备的方法去验证它的可行性，Linux Kernel 一共提供 300 多个内核调用，基本上每个调用都有可能出现问题。Linus 在 2015 年的 LinuxCon 上面也针对 Linux 系统的安全性说过：

“The only real solution to security is to *admit that bugs happen, and then mitigate them by having multiple layers*, so if you have a hole in one component, the next layer will catch the issue.”

“Anyone that thinks that we’ll be entirely secure is just not realistic; we’ll always have issues.”

简单来说，对于系统安全，我们要承认 bug 是客观存在的，要解决安全问题只能增加隔离层。任何号称绝对安全的系统都是不现实的（欢迎对号入座）。

这也是目前主流安全容器技术的思路：隔离。

2. 安全容器技术的主流思路

在上一小节的结尾我们提到一句，目前主流安全容器技术的思路就是增加隔离层，只不过在具体的实现上更具隔离层的具体实现分为如下两种：

• lightweight virtual machine
• guest os

Lightweight virtual matchine 可以认为是传统的虚拟机技术的精简版本，或者说定制版本，典型的以 Kata 为代表。guest os 是在用户态模拟出一个 kernel 出来作为隔离层，以 gVisor 为代表。

3. 目前主流安全容器介绍

下面介绍一下目前主流的安全容器。

3.1 Kata

相信很多人接触的第一个安全容器都是 Kata Container，下面简称 Kata。

Kata Containers is an open source community working to *build a secure container runtime with lightweight virtual machines* that feel and perform like containers, but provide stronger workload isolation using hardware virtualization technology as a second layer of defense.

Kata 旨在通过一个轻量的虚拟机来构建安全容器。在 Kata 中的体感和在容器中没有区别，但是提供了更强的隔离性。

Kata 项目是由 Intel （Clear Container）和 Hyper.sh （RunV）共建，并且在 2017 年进行开源，在 2018 年 4 月份成为 OpenStack 基金会旗下的七年来第一个顶级开放基础设施项目。Kata 本质上是一个使用上像容器的轻量级的虚拟机，虚拟机的安全性已经被各大云产商，比如 AWS、国内各大云产商证明了。Hyper.sh 目前已经被蚂蚁收购，内部衍生版本叫袋鼠安全容器。

3.2 gVisor

gVisor 这个项目是 2018 年发布的，相信很多人都听过 gVisor 项目，因为它有两个特别明显的标签：Google 发布、Go 语言实现。不可否认，Google 近几年的开源产品社区都发展的很不错，比如 Kubernetes。gVisor 的官方定义异常简短：为容器分配一个应用内核，其实就是用户态内核的意思。

gVisor is an application kernel for containers that provides efficient defense-in-depth anywhere.

gVisor is an application kernel, written in Go, that implements a substantial portion of the Linux system call interface. It provides an additional layer of isolation between running applications and the host operating system.

展开来说，gVisor 给每个容器进程提供一个使用 Go 语言实现的独立内核。这个内核对容器进程提供 Linux 系统调用接口，使容器进程看上去像运行在其他的 Linux Kernal 一样。怎么理解 gVisor 提供的这种 “Guest Kernel” 呢？简单来说就是容器进程的所有内核系统调用都会调用到 gVisor，gVisor 再去调用真正的系统内核。有点像网络攻击中的中间人（Man In the Middle）。

gVisor 提供了 Open Container Initiative (OCI) runtime，叫做 runsc。这里给大家解释一下 OCI，在 Kata 上一小节，我们提到了 runv，其实和这里的 runsc 是很类似的，都是一种 OCI runtime 的实现。OCI 是 2015 年由 Docker 和其他几家容器厂商共同制定的一套开放容器标准（open standards for containers）。容器其实有很多种实现，比如我们最常见的 Docker、rkt 等，为了避免 Docker 公司瞎搞，其他厂商联合起来要挟 Docker 公司一起制定了这个标准，只要容器实现了 OCI 规范，那么我们就认为它是一个可以运行的容器。

那么 OCI runtime 又是什么东西呢？容器技术主要包括两个部门：镜像和容器进程。这两项技术就分别对应 OCI 的两种规范：runtime spec 和 image spec。也就是说 runtime 的职责就是将满足 OCI 的镜像运行为一个容器。目前社区有非常多的 OCI runtime，包括：

• containerd
• lxc
• runc
• …

gVisor 提供了 runsc，我们就可以将它和其他容器生态结合起来使用，比如 Docker 和 Kubernetes（1.12 版本引入的 RuntimeClass）。

关于 gVisor 的介绍就到这里，后面我们再详诉。

3.3 Firecracker

既然已经说到了安全容器就不得不提 FireCracker。实现十倍超卖的 AWS 的 Serverless 产品函数计算 lambda 的 runtime 使用的就是 FireCracker。相信国内云厂商也都是使用或者迁移 FireCracker 的路上了。

FireCracker 最早是在 AWS re：invent 2018 上发布。与其他的安全容器不同的是，Firecracker 是专门为 Serverless Computing 打造的虚拟化技术。Firecracker 的最大优点是可以在保持虚拟机级别的安全隔离的同时，又能高效地利用系统资源。

Firecracker is an open source virtualization technology that is purpose-built for creating and managing secure, multi-tenant container and function-based services.

Firecracker enables you to deploy workloads in lightweight virtual machines, called microVMs, which provide enhanced security and workload isolation over traditional VMs, while enabling the speed and resource efficiency of containers. Firecracker was developed at Amazon Web Services to improve the customer experience of services like AWS Lambda and AWS Fargate .

Firecracker is a virtual machine monitor (VMM) that uses the Linux Kernel-based Virtual Machine (KVM) to create and manage microVMs. Firecracker has a minimalist design. It excludes unnecessary devices and guest functionality to reduce the memory footprint and attack surface area of each microVM. This improves security, decreases the startup time, and increases hardware utilization. Firecracker currently supports Intel CPUs, with AMD and Arm support in developer preview.

Firecracker 使用的是一种叫做 microVM 的轻量虚拟机技术，相比于传统的虚拟机技术强化了安全性和隔离性，同时提高了容器的启动速度和资源使用率。Firecracker 使用 KVM 技术管理 microVM。Firecracker 剔除了一些不必要的内核功能来提高内存的使用率和减少攻击面，这也是 Firecracker 效率高的核心原因。

最后值得一提的是 Firecracker 是 rust 语言编写的，star 数已经高达 12k 之多，这个是 github 地址：https://github.com/firecracker-microvm/firecracker