Docker安全性研究

鲁 涛，陈 杰，史 军

(江南计算技术研究所，江苏 无锡 214083)

0 引 言

云计算因为能够提供灵活的弹性服务，具备快速部署能力及便携性特点而在当今计算领域占据着大部分市场份额[1]，其中资源虚拟化技术在实现云计算基础设施服务按需分配中起到了至关重要作用[2]。Vmware、Xen、KVM和Microsoft Hyper-v等传统硬件级虚拟化由于要虚拟一个完整操作系统层，降低了资源利用率，对大规模的集群应用来说是不容忽视的缺陷。为寻求更高效的隔离化技术替代方案，Docker公司将一些现有技术进行包装整合后，于2013年3月推出了开源的容器项目Docker[3]。也得益于赶上了一场IT开发行业从SOA架构向微服务架构的变革[4]，Docker迅速取得了成功，广泛应用于各种场景。应用的广泛性使得对其安全性的研究工作也更具紧迫性和现实意义。

鉴于此，文中将从Docker安全的视角出发，针对性梳理了现阶段Docker安全方面的研究成果，总结归纳了Docker面临的安全威胁和现有的安全防护技术方法，为Docker安全的后续深入研究提供了有价值的参考。

1 Docker架构及组件

Docker是基于客户端服务器模式设计的，其主要组成可分为Docker Client、Docker Daemon、Docker Regeister三部分。Client通过tcp或unix套接字向Daemon发送请求命令获取服务。Daemon运行于宿主机中为客户端请求提供服务，并在需要时向Regeister发送请求，进行提取或推送镜像等操作。Regeister主要任务是处理客户端请求，进行用户认证，并管理存储镜像，对请求服务进行响应。三者间的具体关系如图1所示。

图1 Docker主要组件间关系

Docker Daemon是常驻后台的系统进程，其主要作用是接收并处理Docker Client请求，管理所有Docker容器。默认情形下，其仅监听本地Unix socket，这种情况下宿主机以外的客户端将无法进行远程访问，可以通过对配置文件的修改启用tcp监听，对远程访问提供支持[6]。

Docker Regeister又称为Docker仓库，其主要功能是存储镜像。根据使用范围又可以分为私有仓库和公共仓库。私有仓库一般是公司或个人自己搭建的只供内部用户使用的仓库。公共仓库一般是指可在外网上提供公共服务仓库，用户通过认证后可对镜像进行拉取、上传等系列操作。

2 Docker安全威胁

根据Docker不同组成部分，从网络、镜像、容器、仓库、Docker所依赖的Linux内核、Docker软件本身等六个角度逐类分析了其中存在的安全威胁。

2.1 Docker网络安全威胁

Docker容器网络默认使用桥接方式进行连接，其在宿主机上创建一个虚拟的网桥Dokcer0,它本身扮演了传统交换机的角色，在各个网络接口间自动地进行包转发，每创建一个新的容器，就为其增加一个虚拟网络接口，并将该网络接口连接到网桥Docker0。默认情况下，虚拟网桥并没有对转发的数据包进行任何过滤，因此这种连接方式容易遭受ARP欺骗和MAC泛洪攻击，位于同一宿主机中的容器也更易受到临近被感染容器的网络攻击。通过docker run -p命令指定对外服务端口时，操作不当可能致使暴露端口被映射到宿主机的每个网卡上监听外界连接，一些情况下会带来难以预料的安全风险[7]。

2.2 Docker镜像安全威胁

开发者在构建镜像时可能由于疏忽大意将包括数据库认证密码在内的敏感信息添加到镜像中，为生产环境中部署的应用埋下安全隐患；镜像在方便进行传输和便于部署的同时，也为含病毒后门的镜像恶意传播提供了便利。

在构建镜像过程中，现在使用的基础镜像都比较大，如基于ubuntu和Debain构建的镜像，由于包含与实际用途不相关的库和依赖项，可能会引入额外漏洞。Rui Shu等在其《Docker Hub安全漏洞分析》一文中给出了一份详细的统计数据[8]。该数据如表1所示，由数据可以看出，无论是社区镜像或官方镜像都有较多的漏洞。在使用镜像前，必须要检测镜像中是否含有漏洞，在制作镜像过程中要尽量减少引入不相关的依赖库。在镜像的漏洞扫描方面尽管有Docker Security Scanning、Clair等安全扫描软件，但目前这些软件仍无法给出一种通用的解决方案以识别所有类型镜像中都安装了哪些软件依赖项。

经Spearman相关关系检测，SMILE组和FS-LASIK组在手术前后角膜光密度的变化量与手术前后角膜厚度、曲率、眼压、等效球镜的改变量无明显相关关系。

表1 镜像中所含漏洞数量统计

2.3 Docker容器安全威胁

容器运行时有大量的状态向量和进程信息与操作系统相关联，捕获并转移这些信息相比于虚拟机更难操作，所以目前还不能像虚拟机一样支持热迁移。而Docker这种基于Daemon为中心运行的容器，在Daemon出现运行故障或者需要升级时只能中断运行。这对需要保持持续运行的业务将是灾难性的事故。

容器运行时存在一类配置不当引起的安全问题。当容器以Privileged特权运行时，容器内用户能获得宿主机绝大部分资源支配权；配置容器重启策略时，如不限制容器重启次数，反复的重启可耗尽计算资源，引发拒绝服务攻击；将敏感文件挂载到容器，可导致难以想象的后果，若将/var/run/目录挂载到容器后，导致远程用户可不加认证对宿主机进行任意访问的后果。

2.4 Docker仓库安全威胁

为确保镜像的传输安全，Daemon和Registry通信过程启用了TLS安全连接，为防止镜像被篡改，Docker 1.8之后版本中提供了镜像签名和校验功能[9]。但这中间仍然存在一些问题，如在本地私有网络中搭建的Registry，为了便利会给Daemon配置-insecure-registry参数启用不安全通信连接，并通过传递-disable-content-trust参数禁用Daemon签名校验功能；在Docker Hub中有成千上万的开发者，每个开发者都可以利用自己的私钥对镜像进行签名，签名校验机制并不能从源头上确保开发者可信问题[10]。

Docker Hub为方便用户升级镜像，实现了镜像自动构建(automated builds)功能。该功能允许Docker Hub跟踪指定的GitHub或BitBucket项目，一旦项目发生新提交，则自动重新构建镜像，并将镜像部署到实际生产环境中。在该过程中，会自动从第三方资源平台下载依赖项，而第三方资源平台可能是不安全的链接，传输过程中依赖项极有可能被恶意篡改[11]，这对Docker也是一项不安全因素。

2.5 Linux内核支持安全威胁

大批研究者致力于发现可被用来执行任意代码或能进行本地提权攻击的内核漏洞，由此发现的大量内核漏洞对基于和宿主机共享内核机制构建的Docker容器也是非常大的威胁。另外Linux内核层面提供的支撑技术还不完全成熟，从隔离性上来看，尽管有Namespaces提供隔离防护，但是仍有很多内容并没被加入其中来保证完全隔离，这其中包括伪文件系统、系统时钟和LSMs中的一些特征等[12]。系统运行所必须的关键目录若没有实现完全的隔离是非常危险的，例如/proc、/sys下的子目录中含有系统运行的关键信息，直接暴露给容器会造成信息的泄露，并为恶意用户发起攻击创造了有利条件。Gao X等论述了如何利用/proc目录中泄露的信息，选择最佳时机，启动多个容器，以更小代价对数据中心发起电力攻击[13]。

2.6 Docker软件安全威胁

在Docker 1.10之前的版本中，Daemon在创建容器时需执行很多特权操作，包括挂载文件系统、配置网络等，必须由root用户启动。这在Daemon被突破后，宿主机也将跟着沦陷[9]。虽然在新版本中，Daemon被置于新建的Docker用户组下运行，并利用安全可靠子进程来代理执行需要特权权限的操作。但在现实实践中，Docker用户组并不能很好地保证宿主机安全。

Docker Daemon对镜像、Dockerfile文件解析过程中，如不能对这些输入数据进行很好的过滤，可能导致严重的安全问题。历史上就出现过通过构造特殊Dockerfile压缩文件，在编译时触发漏洞获取执行任意代码权限的严重事件。早期版本中也出现过本地用户通过在Docker Image中构造特殊的软链接进行提权的问题。

3 Docker安全防护

3.1 Docker安全防护支撑技术

Docker提供的隔离特性大多都是通过集成先前已有技术实现的，这包括NameSpaces、Cgroups(control groups)和联合文件系统(UnionFS)特性等技术，这三项技术为Docker的安全隔离提供了基础架构支撑，具体关系如图2所示。

图2 Docker安全防护关键支撑技术

(1)NameSpaces由一组NameSpace组成，主要作用是确保处于同一NameSpaces下的进程相互之间是可见的，不同NameSpaces的进程之间则相互隔离。Docker环境中目前可支持六种不同的NameSpace，它们分别对系统资源的不同方面进行了隔离，具体资源隔离情况如表2所示。

表2 NameSpaces资源隔离

NameSpaces提供的隔离机制为容器提供了相对安全的环境。但正如前文所提到的这种隔离并不彻底，且从今后发展看，对NameSpaces的完善工作会使内核过于复杂，能否为Linux内核主线所接收也是未知数[14]，如何在不增加内核冗杂性的基础上提供更好的隔离方案，是一类亟需研究的安全防护问题。

(2)Cgroups最大特点是可通过使用其各子系统对组内进程资源供给进行灵活组合限制[15]，解决了多租户容器平台中差别化的系统资源分配问题，减少了资源耗尽型Dos攻击的攻击面。其由很多子系统组成，每个子系统实现对不同类型资源的控制[16]，具体对照关系如表3所示。

表3 Cgroups子系统功能对照表

Cgroups存在的缺陷同样是资源限制上不能涵盖全部类型系统资源，尽管Linux提供的另外两种资源限制机制rlimit(resource limit)和配额(quota)机制可弥补Cgroups的部分不足之处，但是对Cgroups的丰富和完善也是今后安全研究工作的重要方面。

(3)联合文件系统是一种分层、轻量级的高性能文件系统，它支持对文件系统的修改作为一次提交并层层叠加，并将不同目录挂载到同一个虚拟文件系统下为用户提供一个统一的视图[17]。

早期Docker产品中，镜像构建和容器运行所需层级结构、写时复制技术都依赖于联合文件系统提供的底层支持。随着Docker的发展，后添加的Device Mapper等驱动存储虽不属联合文件系统，但也可对层级结构、写时复制技术提供支持，统称这些驱动存储技术具有联合文件系统特性。Docker的这种层级结构和写时复制特性确保了运行中容器不能直接对底层镜像文件进行修改，保证了镜像的稳定性，同时建立于其上的内容寻址保证了镜像中的每个层级都有一个唯一的校验ID,从而确保镜像的完整性[18]。

3.2 Docker内核安全防护

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

(1)能力机制将Linux权限进行了更细粒度的划分，改变了过去root用户拥有全部特权现象。能力机制将特权细分为37种不同的能力[14]，涵盖了对文件、进程、网络、系统、设备等各方面的操作权限。Docker默认情况下为容器提供了有限能力权限，用户也可根据实际需要在运行时添加或减少能力特权。能力机制方面仍存在的问题是，权能的划分在一些方面仍不够细致，不能很好地满足对容器的限制要求，CAP-SYS-ADMIN就覆盖了很多的特权，需要进一步细分。为容器分配权限时，很难知道容器内应用需要哪些特权。为兼顾此问题，Docker提供的默认能力权限列表包含了较宽泛的范围，从安全的角度考虑则并不是个好策略。

(2)Seccomp可以限制用户进程的系统调用，对系统调用参数进行筛选。系统调用是用户态和内核态间最重要的接口，通过限定它可在很大程度上确保进程在安全可控范围内运行。Docker默认基于白名单机制使用Seccomp配置文件规定允许进行哪些系统调用，有50多种系统将会被阻止，部分系统调用在特定参数的情况下也会被阻止。该配置文件下，大部分容器都可正常运行。

(3)强制访问控制相对于自主访问控制(discretionary access control，DAC)可提供更严格的保护，用户由于不能改变他们的安全级别和对象的安全属性，只能由MAC根据事先定义好的用户及数据安全等级匹配结果做出客观的具体决策，这样就能屏蔽掉用户主观因素而更好地保障系统安全。在Linux系统中，强制访问控制一般会和DAC配合使用，并在LSM(linux security module)框架下实现具体安全模块[19]。已经实现并合并到内核主线的安全模块有SELinux、AppArmor、Yama、SMACK、Tomoyo，这些安全模块都可为Docker容器提供增强的安全防护。各模块间除Yama外，同时使用会存在互斥现象，一般会根据Linux发行版本的不同而选择不同的安全模块。Debain系列一般使用自带的AppArmor,Redhat系列发行版本则选择自带的SELinux安全模块。

其中SELinux的问题主要是操作过于复杂，开发者和实际生产环节对启用SELinux都持抵制态度,而且在使用上和BTRFS驱动也不兼容。AppArmor的独特之处在于它并不关注全系统的安全，只会为特别标明进程提供强制访问控制，其他进程都工作在不受控制的状态。Mattetti M等介绍了一种LiCShield安全框架用于加固Linux容器，该框架通过跟踪分析容器运行所需权限，有针对性地自动生成一个AppArmor配置文件，来确保容器后续运行的安全可控[20]。除这些安全模块外，用户也可根据LSM框架设计更适合自己的安全模块，李平平等做了相关方面研究[21]。

(4)在Linux内核中有一些网络框架可用来解决Docker网络安全问题，这包括Netfilter框架和TC(tracfic controller)框架。Netfilter侧重于防火墙数据过滤，而TC则侧重流量带宽控制。Docker可通过修改配置文件启用Iptable防火墙，配置防火墙策略来控制容器间的通信[22]，可通过TC限制容器在宿主机上的虚拟网络接口流量而达到限制容器带宽的目的[18]，或者结合Cgroups子系统标记网络数据包，利用TC中的分类队列限制容器的通信流量，有效防止独占网络带宽类型拒绝服务攻击。

(5)Linux内核中的完整性保护相关技术可很好地应用到Docker中，确保镜像和容器运行过程中的完整性。涉及到的技术包括可信计算开放标准(trusted computing group,TCG)在Linux具体实施的部分模块及Device Mapper下实现完整性校验功能的dm-verity子模块。这些技术都可以用来实现Docker镜像的完整性保护，其中王鹃等利用TCG中的TPM做基础支撑，实现了镜像的完整性度量[23]，Hosseinzadeh S等也提出了两种基于vTPM实现容器可信度量的方法[24]，而目前利用dm-verity来实现镜像的完整性校验的研究则较少。

3.3 Docker数据中心安全防护

Docker数据中心产品中有两个重要组成部分：DTR(Docker trusted registry)、UCP(Docker universal control plane)。为确保数据中心的安全性，它们增加了许多新的安全特性，在启用DCT(Docker content trust)框架的情况下可很大程度上保障数据中心的安全。

(1)Docker content trust的主要功能是对从Docker registry传送进来的Docker镜像进行完整性和发布者真实性校验，为要推送到Docker registry中的镜像进行数字签名。DCT在功能实现上采用了Docker notary及其封装的TUF(the update framework)框架。在配置了Docker notary服务的Docker registry环境下，DCT还可以实现更为高级的功能，比如门限签名(threshold signing)功能。

(2)Docker trusted registry是Docker容器云的核心组件，它允许企业在本地或私有云中存储及管理它们的镜像资源。相比Docker registry，除了提供更好的易用性外也增加了额外的安全特性，包括镜像签名、基于角色的访问控制(role based access control)、LDAP/AD的身份认证机制、镜像扫描功能[25]。

(3)和DTR相比，UCP的主要功能则是侧重于本地及私有云环境中容器集群的管理和部署，而不是镜像存储。在安全方面同样集成了基于角色的访问控制、LDAP/AD的身份认证机制，除此之外，还提供了增强的TLS安全机制、Secrets机制及日志记录集中管控功能。

3.4 其他相关安全防护

(1)Docker尽管在日志的可视化审计方面有比较系统的实施方案[7]，但在大规模日志数据深入挖掘，自动化分析方面，仍有待进一步研究[26]；在运行环境审计方面，可参考Docker公司和CIS(center for Internet security)合作制定的一份安全性评估文档，其相应的具体评估实施工具为Docker bench for security。

(2)在针对Docker的安全威胁检测方面，尽管可采用传统基于主机的威胁检测与基于数据流的威胁检测技术，但如何结合Docker自身的特点进行针对化应用还有待进一步加强。Abed A S等详细介绍了如何通过检测Docker中进程的系统调用，对定义的调用频度进行聚类分析，识别出异常入侵行为[27]。该方法就属于将传统基于主机威胁检测技术应用于Docker具体环境中的一个实例。

(3)从不同的视角出发，对Docker的安全问题进行研究的内容还有很多。比如，为提供更安全的容器运行环境，先后出现了一批致力于改造出更适合容器运行的精简操作系统项目，包括CoreOS、Ubuntu Core等；一些研究者则从剔除容器对宿主内核依赖性的角度出发，提出了一种新型的更轻量级架构方案，该方案将借助定制的内核使应用能够直接在裸机上运行，相互之间不再共享内核系统，代表性的解决方案有Unikernels等；也有研究者致力于容器系统安全模型标准界定的研究，Catuogno对CCRA(common criteria recognition arrangement)界定的容器安全标准模型和Reshetova等提出的一种安全模型在Docker环境下进行了对照比较，并指出了两种安全模型实质上的等价性[28]；Sharath N等则介绍了如何利用斯坦克尔伯格模型(Stackelberg model)通过线性规划方法寻求一个可同时兼顾Docker安全性和确保运行效率的最佳结合点[29]。

4 结束语

随着容器应用的日益普及，将有越来越多的敏感应用迁移到容器中，在提供便利部署、高资源利用率的同时，如何加强容器的安全性也成为一个日益引人关注的问题。文中首先简要介绍了Docker的主要架构；接下来对Docker面临的安全威胁进行了梳理，指出了其存在的脆弱性；然后对Docker的安全防护技术进行了归纳，汇总了现阶段的研究方向，指出了一些亟待研究和解决的关键问题。与传统虚拟技术相比，Docker容器的安全性还有差距，但两者并不是相对立的，在同样起到虚拟隔离效果的同时也存在优势互补的作用，尽力补足Docker安全性上的短板将能更好地发挥其优势。

参考文献：

[1] 王 斌.云计算IaaS体系架构面向中小企业的商业模式研究[D].北京：北京邮电大学,2014.

[2] 罗军舟,金嘉晖,宋爱波,等.云计算:体系架构与关键技术[J].通信学报,2011,32(7):3-21.

[3] 李在弘,武传海.Docker基础与实战[M].北京:人民邮电出版社,2016.

[4] 王 磊.微服务架构与实践[M].北京:电子工业出版社,2016.

[5] 孙宏亮.Docker源码分析[M].北京:机械工业出版社,2015.

[6] 张 涛.Docker全攻略[M].北京:电子工业出版社,2016.

[7] GOASGUEN S. Docker cookbook[M]. [s.l.]:O'Reilly Media,Inc.,2015.

[8] SHU Rui,GU Xiaohui,ENCK W.A study of security vulnerabilities on Docker Hub[C]//Proceedings of the seventh ACM on conference on data and application security and privacy.Scottsdale,Arizona,USA:ACM,2017:269-280.

[9] 华为Docker实践小组.Docker进阶与实战[M].北京:机械工业出版社,2016：313-354.

[10] COMBE T,MARTIN A,PIETRO R D.Containers:vulnerability analysis[R].[s.l.]:[s.n.],2015.

[11] COMBE T,MARTIN A,PIETRO R D.To Docker or not to Docker:a security perspective[J].IEEE Cloud Computing,2016,3(5):54-62.

[12] GRATTAFIORI A.Understanding and hardening Linux containers[M].[s.l.]:NCC Group,2016.

[13] GAO Xing,GU Zhongshu,KAYAALP M,et al.ContainerLeaks:emerging security threats of information leakages in container clouds[C]//Proceedings of the 47th IEEE/IFIP international conference on dependable systems and networks.Denver,CO,USA:IEEE,2017:3-15.

[14] 李 志.Linux内核安全模块深入剖析[M].北京：机械工业出版社,2016.

[15] MATTHIAS K,KANE S P.Docker:up & running[M].[s.l.]:O'Reilly Media,Inc.,2015.

[16] 汪 恺,张功萱,周秀敏.基于容器虚拟化技术研究[J].计算机技术与发展,2015,25(8):138-141.

[17] 杨保华,戴王剑,曹亚仑.Docker技术入门与实战[M].北京:机械工业出版社,2017.

[18] 浙江大学SEL实验室.Docker容器与容器云[M].北京:人民邮电出版社,2016.

[19] 刘威鹏,胡 俊,吕辉军,等.LSM框架下可执行程序的强制访问控制机制[J].计算机工程,2008,34(7):160-162.

[20] MATTETTI M,SHULMAN-PELEG A,ALLOUCHE Y,et al.Automatic security hardening and protection of Linux containers[C]//Workshop on security and privacy in the cloud.Florence,Italy:Curran Associates,2015.

[21] 李平平,陈莉君.基于LSM的Docker访问控制机制研究[J].信息技术,2016,40(11):134-138.

[22] DUA R,KOHLI V,KONDURI S K.Learning Docker networking[M].[s.l.]:Packet Publishing Ltd,2016.

[23] 王 鹃,胡 威,张雨菡,等.基于Docker的可信容器[J].武汉大学学报：理学版,2017,63(2)：102-108.

[24] HOSSEINZADEH S,LAURÉN S,LEPPNEN V.Security in container-based virtualization through vTPM[C]//Proceedings of the 9th international conference on utility and cloud computing.[s.l.]:[s.n.],2016:214-219.

[25] GALLAGHER S.Securing Docker[M].[s.l.]:Packet Publishing Ltd,2016.

[26] 褚瓦金.日志管理与分析权威指南[M].北京:机械工业出版社,2014.

[27] ABED A S,CLANCY C,LEVY D S.Intrusion detection system for applications using Linux containers[C]//International workshop on security and trust management.[s.l.]:[s.n.],2015:123-135.

[28] CATUOGNO L,GALDI C.On the evaluation of security properties of containerized systems[C]//International conference on ubiquitous computing and communications and 2016 international symposium on cyberspace and security.Granada,Spain:IEEE,2016:69-76.

[29] SHARATH N,KUMAR V,CHANDRASEKARAN K.Solving security issues in Docker using Stackelberg games[J].IJCTA,2016,9(16):8275-8285.