第 1 课 容器安全威胁建模

0x00 前言

这些年来，随着容器的使用率大幅度增长，很多人将 Docker 和容器简单地画上了等号，但早在 Docker 崛起之前，容器的概念就已经存在了很多年……

0x01 Docker 问世让容器再次“翻红”

2013年3月15日，Docker 的创始人Solomon Hykes在 PyCon 上首次向全世界公开展示了 Docker^[1]。他指出了，对于开发人员来说，将应用程序部署到服务器上非常困难，因此他和他的早期团队设计了 Docker，以帮助开发者更方便地在任何地方构建、共享和运行应用程序。

正如 Docker 最初的标语“一处构建，处处运行”所说的那样，容器可以将应用程序及其依赖等一切所需要的东西都打包到容器中，然后将容器和宿主机的其他部分隔离开来。这一来，我们就可以在各自的个人电脑或者服务器上运行着相同的应用程序的镜像了。Docker 这种简单易用的命令行工具的问世导致容器再次“翻红”，在开发者社区中迅速风靡起来了。

Kubernetes 社区资深成员与项目维护者张磊在他的书《深入剖析 Kubernetes^[2]》中说道：“Docker 项目给 PaaS 世界带来的‘降维打击’，其实是提供了一种非常便利的打包机制。这种机制直接打包了应用运行所需要的整个操作系统，从而保证了本地环境和云端环境的高度一致，避免了用户通过‘试错’来匹配两种不同运行环境之间差异的痛苦过程。”

0x02 容器解决了应用程序的依赖问题

在容器出现之前，你很容易会陷入依赖关系的噩梦中去，即：同一主机上的两个应用程序需要依赖相同的软件包的不同版本。要解决这个问题其实很简单，你只要将应用程序部署到不同的主机上就可以了，但这样未免会造成资源的浪费。

但只要有了容器，你可以用更加高效的方案来解决这个问题，那就是：将应用程序容器化，部署到同一宿主机的不同容器中。容器的隔离机制可以让依赖关系彼此隔离，即：你在同一宿主机上同时运行多个不同的容器而不受干扰。

0x03 容器编排改变了应用程序的部署方式

“容器就从一个开发者手里的小工具，一跃成为了云计算领域的绝对主角；而能够定义容器组织和管理规范的‘容器编排’技术，则当仁不让地坐上了容器技术领域的‘头把交椅’。”

像 Kubernetes 这样的容器编排工具完美解决了：如何自动化地将容器部署到服务器集群中。你只需告诉编排工具，你想要运行哪些容器，它就会为每一个容器找到一个非常合适的位置，而无须你手动地在特定的主机中安装应用程序了。

0x04 安全研究员的思考

容器和容器编排的出现彻底改变了开发者的开发流程，但作为安全人员，我们该如何看待这个科技的浪潮呢？

从安全的角度上来讲，容器的部署环境和传统的部署环境所面临风险情况相同。例如，数据窃取、修改系统行为和挖矿（使用他人的计算资源来挖掘自己的加密货币）等等。

虽然这些在容器化的环境中并不会有什么改变，但容器确确实实地改变了应用程序的许多方面的状况，因此还产生了一套不同的风险机制。

接下来，我们从以下 5 个方面来总览容器所面临的风险，以及如何对容器进行威胁建模：

1. 风险、威胁和缓解措施
2. 容器威胁建模
3. 安全边界
4. 多租户
5. 安全原则

0x05 总结

本文，我们简述了Docker基于容器的概念，为开发者解决了应用程序的依赖关系的问题，提供了一种便捷的打包机制，从而在开发者社区中爆火。

不久后，容器编排改变了应用程序的部署方式，当仁不让地坐上了容器技术领域的“头把交椅”。

从安全的角度看待这次变革，我们需要思考容器部署环境与传统部署环境所面临的风险点有哪些异同点，以及如何建立一个适用于容器环境的威胁模型。

接下来，我们从一个较高的层次来总览容器所面临的风险，以便建立起一个全局的防护观。