Docker笔记（10）：Docker安全防护与配置

Docker是基于 Linux操作系统实现的应用虚拟化。运行在容器内的进程，与运行在本地系统中的进程在本质上并无区别，因此，配置的安全策略不合适将可能给本地系统带来安全风险。Docker的安全性在生产环境中是十分关键的衡量因素。Docker容器的安全性，在很大程度上依赖于 Linux系统自身。目前，在评估 Docker的安全性时，主要考虑下面几个方面：

• Linux内核的命名空间机制提供的容器隔离安全；
• Linux控制组机制对容器资源的控制能力安全；
• Linux内核的能力机制所带来的操作权限安全；
• Docker程序（特别是服务端）本身的抗攻击性；
• 其他安全增强机制（包括 AppArmor、SELinux等）对容器安全性的影响；
• 通过第三方工具（如 Docker Bench工具）对 Docker环境的安全性进行评估。

1.命名空间隔离的安全

当用 docker run 命令启动一个容器时， Docker 将在后台为容器创建一个独立的命名空间。 命

名空间提供了最基础也是最直接的隔离， 在容器中运行的进程不会被运行在本地主机上的进

程和其他容器通过正常渠道发现和影响。

通过命名空间机制，每个容器都有自己独有的网络栈，意味着它们不能访问其他容器的套接字(socket)或接口。从网络架构的角度来看， 所有的容器实际上是通过本地主机的网桥接口(docker0)进行相互通信， 就像物理机器通过物理交换机通信一样。

与虚拟机方式相比，通过命名空间来实现的隔离并不是那么绝对。运行在容器中的应用可以直接访问系统内核和部分系统文件。因此，用户必须保证容器中应用是安全可信的（这跟保证运行在系统中的软件是可信的一个道理），否则本地系统将可能受到威胁，即必须保证镜像的来源和自身可靠。Docker自1.3.0版本起对镜像管理引入了签名系统，加强了对镜像安全性的防护，用户可以通过签名来验证镜像的完整性和正确性。

2.控制组资源控制的安全

控制组是 Linux容器机制中的一个关键组件，它负责实现资源的审计和限制。当用户执行 docker run命令启动一个 Docker容器时，Docker将通过Linux相关的调用，在后台为容器创建一个独立的控制组策略集合，该集合将限制容器内应用对资源的消耗。

控制组提供了很多有用的特性。它可以确保各个容器公平地分享主机的内存、CPU、磁盘IO等资源；更重要的是，通过控制组可以限制容器对资源的占用，确保了当某个容器对资源消耗过大时，不会影响到本地主机系统和其他容器。

尽管控制组不负责隔离容器之间相互访问、处理数据和进程，但是它在防止恶意攻击特别是拒绝服务攻击（DDoS）方面是十分有效的。

对于支持多用户的服务平台（比如公有的各种PaS、容器云）上，控制组尤其重要。例如，当个别应用容器出现异常的时候，可以保证本地系统和其他容器正常运行而不受影响从而避免引发“雪崩”灾难

3.内核能力机制

能力机制(capability)是Linux内核一个强大的特性， 可以提供细粒度的权限访间控制。传统的 Unix 系统对进程权限只有根权限（用户 id 为 0, 即为 root 用户）和非根权限（非root 用户）两种粗粒度的区别。Linux 内核自2.2版本起支持能力机制， 将权限划分为更加细粒度的操作能力， 既可以作用在进程上， 也可以作用在文件上。

大部分情况下，容器并不需要root 权限，只需要少数的能力即可。默认情况下，Docker 启动的容器有严格限制，Docker 采用白名单机制，禁用了必需的一些能力之外的其他权限，用户也可以根据自身需求为 Docker 容器启用额外的权限。

为了加强安全， 容器可以禁用一些没必要的权限，就算攻击者在容器中取得了 root 权限， 也不能获得本地主机的较高权限， 能进行的破坏也有限。不恰当地给容器分配了内核能力， 会导致容器内应用获取破坏本地系统的权限。

4.Docker服务端的防护

Docker服务端是Docker容器的核心，Docker服务的运行目前还需要root权限的支持，因此服务端的安全性十分关键。

首先，必须确保只有可信的用户才能访问到 Docker服务。Docker允许用户在主机和容器间共享文件夹，同时不需要限制容器的访问权限，这就容易让容器突破资源限制。例如，恶意用户启动容器的时候将主机的根目录/映射到容器的/host目录中，那么容器理论上就可以对主机的文件系统进行任意修改了。事实上，几乎所有虚拟化系统都允许类似的资源共享，而没法阻止恶意用户共享主机根文件系统到虚拟机系统将会造成很严重的安全后果。因此，当提供容器创建服务时（例如通过一个Web服务器），要更加注意进行参数的安全检查，防止恶意用户用特定参数来创建一些破坏性的容器。

此外，在将文件系统挂载到容器内部时候，可以通过配置只读（read-only）模式来避免容器内的应用通过文件系统破坏外部环境，特别是一些系统运行状态相关的目录，这样，容器内应用进程可以获取所需要的系统信息但无法对它们进行修改，同时，对于应用容器场景下，Docker内启动应用的用户都应为非特权用户（可以进一步禁用用户权限，如访问Shell），避免出现故障时对容器内其他资源造成损害。

最近改进的 Linux命名空间机制将可以实现使用非root用户来运行全功能的容器。这将从根本上解决了容器和主机之间共享文件系统而引起的安全问题。目前，Docker自身改进安全防护的目标是实现以下两个重要安全特性：

• 将容器的root用户映射到本地主机上的非root用户，减轻容器和主机之间因权限提升而引起的安全问题；
• 允许 Docker服务端在非root权限下运行，利用安全可靠的子进程来代理执行需要特权权限的操作。这些子进程将只允许在限定范围内进行操作，例如仅仅负责虚拟网络设定或文件系统管理、配置操作等。

5.安全检测工具

进行自动化检查的开源工具， 比较出名的有Docker Bench和 clair。

Docker Bench是一个开源项目，可发现当前Docker部署在配置、 安全等方面的潜在问题。 CIS

Docker规范在主机配置、 Docker引擎、配置文件权限、 镜像管理、容器运行时环境、安全项等六大方面都进行了相关的约束和规定， 推荐大家在生产环境中使用Docker时， 采用该规范作为部署的安全标准。Docker Bench的安全检查结果中， 带有不同的级别， 说明问题的严重程度， 最后会给出整体检查结果和评分。 一般要尽量避免出现WAR或以上的间题。

6.小结

技术层面实现的安全只是理论上的，需要配合一系列安全的执行流程与合规的使用手段。特别是对于生产系统来说，影响安全的维度比较复杂，发生风险的位置很多。除了通过安全监测来减少服务正常运行的安全风险外，还要配合完善的安全监控系统，在出现问题时能及时进行响应。

在使用 Docker的过程中，尤其需要注意如下几方面：

• 首先要牢记容器自身所提供的隔离性只是相对的，并没有虚拟机那样完善。因此，必须对容器内应用进行严格的安全审查。同时从容器层面来看，容器即应用，原先保障应用安全的各种手段，都可以合理地借鉴利用；
• 采用专用的服务器来运行Docker服务端和相关的管理服务（比如sh监控和进程监控、管理工具nrpe、collectd等），并对该服务器启用最高级別的安全机制。而把其他业务服务都放到容器中去运行，确保即便个别容器出现问题，也不会影响到其他容器资源；
• 将运行 Docker容器的机器划分为不同的组，互相信任的机器放到同一个组内；组之间进行资源隔离；同时进行定期的安全检查；
• 大规模运营场景下，需要考虑在容器网络上进行必备的安全防护，避免诸如DDoS、ARP攻击、规则表攻击等网络安全威胁，这也是生产环境需要关注的重要问题。