Docker安全性分析及安全防护

李俊灏

【摘 要】伴随着云计算的发展，Docker容器技术以其轻量级和高性能的优势迅速取得了广泛的市场应用。Docker具有共享内核的特性，这带来了一些安全上的问题。本文从安全隔离、资源限制、内容信任和内核安全防护四个维度对Docker的固有安全特性进行了阐述，分析实际应用过程中可能存在的七大安全风险，并提出针对性的防护建议。

【关键字】虚拟化;容器;Docker;安全;风险;威胁;安全防护

中图分类号： TP309 文献标识码： A 文章编号： 2095-2457（2019）20-0240-002

DOI：10.19694/j.cnki.issn2095-2457.2019.20.112

0 引言

近年來，伴随着云计算的迅猛发展，虚拟化技术得到了广泛的应用，以满足云计算环境对密集计算、灵活扩展以及安全可靠的需求。当前主流的虚拟化技术可以分为两类，分别是基于虚拟机的虚拟化技术（hypervisor-based）和基于容器的虚拟化技术（container-based）。相较而言，虚拟机技术在安全隔离方面更胜一筹，而容器技术则具备轻量而高效的优势。

Docker开源容器项目在2013年一经推出便备受瞩目，短短几年里迅速成为了容器虚拟化领域的主流方案。本文从安全角度出发，详细分析了Docker本身的安全特性，并对可能存在的安全风险提出了针对性的安全防护建议。

1 Docker概述

Docker致力于提供一整套从开发、交付到运行的一体化应用解决方案。Docker的成功绝非偶然，2013年Docker项目启动的时候，容器技术已经有了十余年的发展，在前辈LXC（Linux container）的基础上，Docker带来了全新的特性：提供了能够简单而安全的创建和控制容器的接口，提供了一次打包、随处运行的便利，实现了相比其它技术更高的硬件资源利用效率，以及与第三方工具配合工作以简化管理部署流程的能力。

Docker基于CS架构设计，主要组件包括Docker client、Docker daemon、Docker registry三部分。

Docker daemon是Docker的功能核心，它负责侦听Docker API请求并管理Docker对象，比如镜像（image）、容器（container）、网络和卷（volume）。一个Docker daemon还可以与其它Docker daemon通信来实现服务管理。

Docker client是Docker为用户提供的操作接口，可通过该接口输入命令完成对镜像、容器、仓库的操作。一个Docker client可同时与多个Docker daemon进行通信。

Docker registry用于存储Docker镜像。Docker Hub是一个公开的Docker registry，默认配置下，Docker会在Docker Hub上查找所需的镜像。通过使用Docker Datacenter（DDC）内含的Docker Trusted Registry（DTR）组件，任何人都可以搭建私有的Docker registry。

2 Docker安全特性

2.1 安全隔离

虚拟化技术在多租户环境下必须首先解决安全隔离的问题，Docker借助Linux内核的namespace（命名空间）功能和Cgroups机制来实现安全隔离。以下从进程、文件系统、设备、进程间通信（IPC）、网络等5个方面来评估Docker安全隔离的实现程度。

2.1.1 进程隔离

Docker通过PID namespace来实现进程隔离，从而让运行中的容器无法感知到运行在其它容器或者宿主机上的进程。PID namespace具有层次结构，父namespace可以感知到子namespace中的进程，反之或平级之间则不行，这就保证了宿主机系统进程可以控制容器进程，但容器进程却无法感知宿主机或者其它容器上的进程。另外，容器中的进程编号（PID）都是独立的，这样每个容器都可以有PID为1的类init进程，当发现异常时，只要管理员结束掉这个类init进程，这个容器就被彻底的关闭了。

2.1.2 文件系统隔离

Docker通过mount namespace来实现容器间的文件系统隔离，让各个容器以及宿主机上的文件系统挂载操作保持独立且互不干扰。但需要注意的是，为了保证容器内的正常操作，宿主机上的一些特殊目录（例如/sys、/proc/sys、/proc/sysrq-trigger、/proc/irq以及/proc/bus等）并不受namespace限制，换句话说，容器内可以直接访问这些宿主机目录。为了降低该问题导致的风险，Docker做了两点限制：（1）容器对这些特殊的目录没有写入权限。（2）移除容器的CAP_SYS_ADMIN能力，从而使容器内无法重新挂载这些特殊目录。

此外，由于多个容器可以共用同一个镜像，每个容器在运行过程中都会生成私有的数据，为了最大化的重用资源，Docker使用了COW（写时拷贝）技术和unionFS文件系统，在只读文件系统上为每个容器叠加一层可写入文件系统，保证不同容器的数据操作完全独立，互不影响。

2.1.3 设备隔离

Docker利用Cgroups来控制容器可访问的设备，并阻止容器内的进程创建新的设备节点。另外，Docker在挂载时使用了nodev选项，这样即便在镜像中创建了设备节点，容器中也同样无法使用这些节点来与内核通信。需要指出的是，以上均假设容器未运行在“特权模式”下，以“特权模式”启动的容器可以访问所有设备。

2.1.4 进程间通信隔离

Docker通过IPC namespace来实现进程间通信隔离，不同的IPC namespace中的进程无法互相通信，Docker为每个容器都分配了一个IPC namespace，以此来保证容器之间的进程通信隔离。

2.1.5 网络隔离

Docker通过network namespace来为每个容器分配了一块独立的网络协议栈，使每个容器都有自己的IP地址、路由表以及网络设备等。

为了实现容器间以及容器与宿主机间的网络通信，默认情况下Docker会在宿主机上创建一个虚拟以太网网桥docker0，所有容器的eth0接口均通过一定的方式与该虚拟网桥相连，以此来实现网络通信。由于默认情况下虚拟网桥不进行包过滤，这会造成一定的安全风险。

2.2 資源限制

拒绝服务（DoS）是最常见的攻击方式之一，通过控制某些进程去消耗系统的所有资源，从而破坏其他进程的正常运行。在容器环境下，所有容器共享内核资源，如果未作限制，一旦某个容器被攻击者以一定方式控制，宿主机资源将很可能被消耗殆尽。为了防范DoS，每个容器的可用资源必须受到合理的限制。

Docker借助linux的Cgroups来实现这种限制，以控制单个容器可用的CPU、内存和磁盘I/O等资源，从而确保每个容器获得公平的资源份额，并防止任何容器消耗所有资源。

2.3 内容信任

Docker内容信任（DCT）提供了在与远程Docker registry数据通信过程中使用数字签名的能力，这些签名可被用来验证镜像的发行方以及数据的完整性。通过DCT，镜像发布者可以对其镜像进行签名，而镜像使用者可以确保他们使用的镜像已签名。

2.4 内核安全防护

确保内核安全和利用内核提供的安全技术进行自身安全加强都是Docker安全的重要方面，Docker在这方面也做了很多整合工作，主要是通过采用能力机制（capabilities）、Seccomp（secure computing mode）安全特性、强制访问控制（MAC）对容器的权能和系统调用进行限制;通过利用内核相关安全模块Iptables、Trafic、controller来加强自身网络安全，以及通过利用内核相关完整性保护技术确保镜像和系统的完整性等;通过已有安全框架Grsecurity/PAX等对内核进行安全强化。

3 安全风险及防护建议

3.1 宿主机及内核安全

3.1.1 风险描述

Docker引擎及容器都运行在宿主机上，一旦宿主机被攻破，Docker的安全便无从谈起。

3.1.2 防护建议

（1）做好访问控制及通信加密。

（2）保证系统和软件（包括docker本身）能够得到及时的更新。

（3）尽量使用最小化系统，比如CoreOS、Red Hat Atomic、RancherOS等。

（4）启用强制访问控制（MAC），如Seccomp、AppArmor、SELinux等。

3.2 容器逃逸

3.2.1 风险描述

容器逃逸指的是某个Docker容器绕过了隔离检查，访问到了宿主机的敏感信息或者取得了宿主机的控制权限。

3.2.2 防护建议

（1）去除非必要的能力（capabilities），例如CAP_SYS_ADMIN。

（2）如无必要，不要以特权模式运行容器，必须这样做的情况下，要确认镜像来源可信。

3.3 镜像认证

3.3.1 风险描述

默认情况下，Docker并不对镜像做认证和校验，从任何渠道获取的镜像都可以直接运行。如果无法保证镜像的发布者是可信的，并且镜像在传递的过程中内容没有被篡改，那么就存在着镜像内容被恶意植入的风险。

3.3.2 防护建议

（1）不使用未经验证的软件，不使用未在信任列表中的源。

（2）强制使用镜像的签名验证机制。

3.4 容器资源滥用

3.4.1 风险描述

一台宿主机上往往会同时运行数量庞大的容器群，虽然这是充分利用资源的一种表现，但同时也意味着更激烈的资源竞争。如果资源使用上不加限制，那么很容易就能够发起一次拒绝服务（DoS）攻击。常见的资源类型包括CPU、内存、存储、网络带宽、I/O带宽、交换文件等。

3.4.2 防护建议

（1）虽然Docker默认情况下不做资源限制，但只要按需添加命令行参数就可以做到这一点。试着通过一系列的测试来确定正常情况下一个容器需要的资源量范围，并以此为标准进行限制。

（2）如果决定暂时不做实际限制，至少应该配置相关的监控和告警，在资源使用量超限时第一时间得到通知。

3.5 镜像内漏洞

3.5.1 风险描述

每个Docker镜像常常被设计为实现某一功能的黑盒，在这种情况下如果容器运行时功能正常，使用者往往会忽略镜像中存在的安全问题。举例而言，一个Apache服务器镜像内包含的Apache版本可能非常老旧，以至于存在大量的未修补漏洞，攻击者很容易利用这些已知的漏洞对服务器发动攻击，并有可能进一步影响到整个容器甚至整个宿主机的安全。

3.5.2 防护建议

（1）定期为镜像中的软件升级安全补丁，然后重新编译和发布新版本镜像。

（2）尽量保持镜像功能单一，如果有可能，将复杂功能的镜像拆分为多个单一功能的镜像。

（3）定期进行安全扫描，并及时对扫描出的漏洞进行修补。

3.6 敏感信息

3.6.1 风险描述

在Docker容器运行过程中，不可避免的会接收、保存和传递一些敏感信息，比如密钥、凭据和证书等。如果处理不得当的话，非常容易造成敏感信息的泄露。

3.6.2 防护建议

（1）不通过环境变量传递敏感信息。

（2）不将任何敏感信息保存在镜像中。

（3）如有必要，部署一套Docker凭据管理软件。

3.7 运行时安全监控

3.7.1 风险描述

即便做到了以上说到的每一条，安全风险仍然存在，比如攻击者利用的是使用者自身代码的漏洞或者0day漏洞。运行时的安全风险千变万化，必须要有动态的风险监测机制来发现问题并及时处置。

3.7.2 防护建议

（1）做好运行时安全的监控和告警。例如借助态势感知系统进行综合性的攻击和入侵预判。

（2）非本地化的保存运行日志信息，以供事后追溯分析。

4 结束语

通过对Docker固有安全特性的分析，能看到Docker的设计者为Docker创建了一整套的安全防护体系，能够较好的覆盖整个Docker应用生命周期。当然，默认配置下，Docker是存在一定的安全隐患的，通过启用镜像签名机制、限制容器资源使用、以非特权模式运行容器以及启用MAC方案等，Docker的安全能力将得到极大的提升。安全和效率在生产实践中始终是一对矛盾体，如何采取有效的管理手段，将Docker环境的风险暴露面降低到一个合理可接受的水平，这将是一个需要长期探讨和研究的课题。

【参考文献】

[1]谢超群.高校数据中心Docker容器应用的安全体系设计[J].网络安全技术与应用，2019（05）：53-55.

[2]艾明振.基于Docker平台的安全信息管理的研究与实现[D].北京邮电大学，2018.

[3]魯涛，陈杰，史军.Docker安全性研究[J].计算机技术与发展，2018，28（06）：115-120.

[4]张遥，王森林.Docker安全性研究[J].网络安全技术与应用，2017（08）：32-33.

[5]胡家发.Docker容器安全隔离机制研究[D].西安建筑科技大学，2017.

[6]杨文林，谭曦，郭俊廷，王硕.Docker脆弱性分析与安全增强[J].信息安全与技术，2016，7（04）：21-23+55.