高度安全环境下的Docker和Kubernetes

这是笔者研究生论文的 部分 内容和基于此得出的结论的一个简要总结。本文侧重于探讨 容器化应用程序的隔离问题 。论文里还介绍了 Kubernetes集群网络的部分 ，这里不做讨论。

你可以在这里找到笔者完整的论文，它是公开可以访问的：http://kth.diva-portal.org/smash/record.jsf?pid=diva2:1231856。

近年来，容器编排和云原生计算获得了许多人的关注。行业内的采用率甚至已经高到金融、银行和国企单位都感兴趣的程度。与其他企业相比，他们在信息安全和IT安全方面有着更为广泛的要求。

其中一个重点在于如何在生产环境中使用容器的同时保持应用程序之间的系统隔离性。由于这类企业以前使用的是由裸金属虚拟化驱动的私有云，迁移到容器编排环境造成的隔离方面的损失不容忽视。这也正是笔者论文研究的范畴，它是以瑞典警察局为目标客户编写的。

论文里具体研究的问题如下：

相比于通过裸金属hypervisor ESXi驱动的虚拟机而言，Docker和Kubernetes是如何实现瑞典警察局应用程序之间的系统隔离？

这个问题有很多需要展开的地方。首先，我们先来看一下它们共同关注的对象 - 应用程序。

混乱的Web应用

Web应用程序里的漏洞就像是攻击者的游乐园，OWASP Top 10（2013[1]，2017[2]揭示了这里面最突出的十个安全风险。这类资源有助于引导开发人员规避一些常见的安全风险。然而，即便假设开发人员编写的所有代码都是完美无瑕的，应用程序仍然可能遭受攻击，例如，代码包依赖导致的安全问题。

David Gilbertson[3]撰写了一篇关于如何通过分发恶意软件包（以Node.js应用为例的话就是NPM）来实现代码注入的精彩故事。尽管依赖扫描程序能够用来发现漏洞，但是它只能降低风险，并不能完全消除这一风险。

即便用户构建了一个没有第三方依赖的应用程序，但是想要做到应用程序永远不会受到攻击仍然是不现实的。

由于这些风险的客观存在，我们无法假定Web应用是安全的。

相反，我们必须采取纵深防御策略[4]。那么，让我们一起来看看应用的下一层——容器和虚拟机！

容器与虚拟机——一个关于隔离的故事

容器是一个隔离的用户态环境，一般通过内核的功能来实现。比如，Docker通过Linux namespace，cgroup和capability来达成这一目标。在这方面，相比于通过裸金属hypervisor驱动的虚拟机而言，Docker容器的隔离效果 有很大差别 。

在虚拟机的世界里，隔离可以通过像Intel VT这样的实际硬件实现。另外一方面，Docker容器依赖于 Linux 内核进行隔离。在考虑底层攻击（ layer-below attacks ）时，它们之间的这一差异就显得尤为突出。

如果攻击者能够在虚拟机或容器中执行代码，那么攻击者可以通过攻击底层实现 逃逸攻击 。 

图1 根据使用的是容器还是裸金属虚拟机，隔离的实现层次也各不相同

在Pwn2Own 2017黑客大赛以及GeekPwn2018大会期间，裸金属hypervisor VMware ESXi验证了这类攻击。结果便是爆出了好几个CVE（例如CVE-2017-4902[5]，CVE-2018-6981[6]），它们可用于底层攻击以实现 虚拟机逃逸 。尽管裸金属虚拟机使用的是硬件级别的隔离技术，但是它并不能确保它们是绝对安全可靠的。

另外一方面，如果我们考虑裸金属 hypversior 与 Linux 内核相比，谁的攻击面更广的话，很显然是后者，因为它更为庞大，涉及的功能范围也更广。而更大的攻击面则意味着依赖于容器隔离的云存在更多潜在的攻击目标。这反映在对 容器逃逸攻击 的日益关注，这类攻击已经通过一些内核漏洞被验证是可行的（例如CVE-2016-5195[7]，CVE-2017-1000405[8]）。

要提高容器 内部 的隔离性的话，我们可以使用SELinux或AppArmor等安全模块。不幸的是，这种基于内核的安全机制并不能阻止基于内核的逃逸攻击。即便没有逃脱，它也只会限制攻击者的行为。如果我们想要真正解决容器逃逸攻击问题的话，我们需要在容器 外部 甚至内核中使用一些隔离机制。比如一个沙盒！

gVisor是一个由Google开源的容器运行时沙盒，它在容器和操作系统内核之间添加了一个额外的内核。这种类型的沙盒可以缓解基于内核的容器逃逸攻击。但是对于攻击者而言，内核漏洞攻击只是 工具 箱里的其中一个手段而已。

要了解攻击者的其他手段，我们必须站在更高层面看待容器在云原生时代的使用方式。

集装箱编排对隔离的影响

为了管理在多节点环境中运行的容器，我们采用了容器编排系统，其中 Kubernetes 占据主导地位。事实证明，编排器中的错误也会影响容器隔离。

Tim Allclair在KubeCon 2018大会上给我们做了一次精彩的演讲，这里面他着重提到了几个攻击面。在他的演讲中，他提到了一个关于编排错误如何影响隔离的案例（CVE-2017-1002101[9]），在这种情况下，攻击者通过在Pod外部挂载存储卷实现逃逸攻击。这一类型的漏洞很有问题，因为它也可能会绕过包装容器的沙盒。

在引入Kubernetes之后，我们又多了一个被攻击的对象。Kubernetes Master的几个系统服务就是其中之一。一个例子便是Kubernetes APIServer，最近发现存在一个权限提升的漏洞（CVE-2018-1002105[10]）。由于 Kubernetes Master 的攻击面超出笔者论文讨论的范畴，这里先不考虑这类特定的漏洞。

那么，为什么说逃逸攻击是一个大问题呢？容器引入了在同一个宿主操作系统上运行多个共址应用程序的能力。这带来了应用程序隔离的风险。如果一个关键业务的应用程序和另一个易受攻击的应用程序运行在同一台宿主机上，那么攻击者可以通过攻击易受攻击的应用程序来获取对关键应用程序的访问权限。

根据企业处理的数据类型的不同，数据泄露可能还会损害除了企业自身以外的个人和国家。别忘了，我们的客户都是一些国企单位、金融、银行等，如果出现异常可能会严重影响人们的生活。

那么，在这样的环境下还能使用容器编排吗？在我们进一步研究这个思路之前，我们需要先做一些风险评估。

什么是可接受的风险？

裸金属hypervisor

在瑞典国防研究局发布的一份报告[11]中，他们对瑞典武装部队使用虚拟化技术的风险进行了评估。报告的结论是，尽管安全性方面存在一些苛刻要求，而且虚拟化可能会带来一些潜在的风险，但是对于武装部队而言引入虚拟化技术仍然是有用的。

在这方面，我们不妨假定我们在国防工业中（在某种程度上）已经使用了虚拟化技术，因为它带来的风险是 可以接受的 。由于国防工业中的代理商和企业是IT安全领域里要求最苛刻的客户之一，我们也可以说，对他们来说可接受的风险，也是本论文范畴内的其他客户可以接受的。我们之前也讨论过虚拟机逃逸的可能性，它其实也是这样。

如果我们决定将容器搭配这种类型的沙盒一起使用的话，我们还需要将一些因素考虑在内，让它变得更具备云原生的特性。

虚拟机沙盒节点

表达共址需求

对于PG类应用程序，关联规则将和具有组标识符 class-pg-group-1的pod和没有标识符的pod的节点共同寻址。

这使得我们可以通过基于分类的系统，根据容器化应用程序的隔离需求来分离容器。

那么这又为我们带来了什么呢？

小结

Kubernetes入门与进阶实战培训

Kubernetes入门与进阶实战培训将于2019年6月14日在北京开课，3天时间带你系统掌握Kubernetes， 学习效果不好可以继续学习。 本次培训包括：Docker基础、容器技术、Docker镜像、数据共享与持久化、Docker三驾马车、Docker实践、Kubernetes基础、Pod基础与进阶、常用对象操作、服务发现、Helm、Kubernetes核心组件原理分析、Kubernetes服务质量保证、调度详解与应用场景、网络、基于Kubernetes的CI/CD、基于Kubernetes的配置管理等，点击下方图片或者点击阅读原文了解详情。