Docker是目前最具代表性的容器平台之一，它的安全问题引起了产业界和学术界的广泛关注。首先，对Docker架构以及基本安全特性进行介绍，分析了Docker面临的安全威胁。其次，对Docker增强、安全检测、瘦身等方面的安全技术进行了分析梳理。最后，对Docker安全的未来发展进行总结和展望，帮助和激励研究人员开始对Docker领域的研究。
内容目录
1 背景知识
1.1 Docker 架构
1.2 Docker 安全机制
2 容器 Docker 安全风险2.1 镜像安全风险
2.1 镜像安全风险
2.2 容器虚拟化安全风险
2.3 容器网络安全风险
3 Docker 安全增强技术
4 Docker 安全检测
4.1 检测容器安全工具
4.2 基于机器学习的容器安全检测
4.3 基于溯源图的容器安全检测
4.4 基于镜像标签的容器安全检测
5 Docker 镜像瘦身
6 结 语
Docker是一种轻量级的虚拟化方式，将应用程序和运行环境打包成容器镜像，使得应用程序能够直接在容器中独立地运行。由于Docker拥有轻量化、高效率和易部署的特点，目前已被广泛应用于云计算和微服务架构中。
根据国家安全漏洞库统计，Docker自2013年正式发布以来，截至2022年8月，累计发现124个相关漏洞，其中高危以上漏洞占71%，这对应用生态安全和用户信心都带来了不利影响。因此，Docker的安全性得到了产业界和学术界的广泛关注，许多研究思路和方法被不断提出。本文对Docker安全相关的研究思路、方法和工具进行比较和分析，并指出未来可能的研究方向。
图1为Docker架构图。容器在宿主机上工作，并和其他容器共享宿主机内核。其中Docker客户端和Docker守护进程通过REST API进行通信，发送拉取镜像之类的命令行请求；Docker守护进程用来处理Docker客户端发送的请求；Docker引擎是Docker架构中的运行引擎；Docker 容器是容器服务的交付实体。
Docker采用了多种Linux内核安全机制来约束容器内的进程，如表1所示。
Docker利用Linux的命名空间(Namespaces)为容器提供独立的工作空间，与其他容器进行资源隔离；Docker利用Cgroups机制，限制每个容器可以访问哪些资源，确保多容器环境下能正常使用系统资源；Capabilities定义了CAP_CHOWN、CAP_KILL等多种权限(不同版本略有不同，5.16-rc6版本中定义了40个权限)，将超级用户权限进行细分，容器默认只有其中的14种权限；Docker基于Seccomp机制，限制容器内系统调用；SElinux和AppArmor属于强制访问控制，限制可执行程序的访问控制权限，如读写功能；内容信任机制通过发布者签名和使用者校验的方式确认镜像的完整性。
狴犴安全团队将Docker安全问题分为镜像安全风险、容器虚拟化安全风险和容器网络安全风险3个方面，本文在此基础上对Docker安全问题进一步补充分析，为后续Docker安全增强提供研究方向。
镜像安全决定了生成容器的安全性，一直 是学术界关注的热点。表 2 是近几年研究镜像 包含漏洞的情况。随着时间的推移，镜像中的 漏洞数并没有明显减少，说明镜像仓库中的镜像安全问题一直没有得到很好的解决。
(1)镜像安全威胁模型如图2所示，Docker Hub平台用户面临两种不同的威胁：一是攻击者可以发布包含恶意执行命令的镜像，一旦用户下载运行镜像，就可能遭受攻击；二是开发者发布包含漏洞的镜像，攻击者有可能利用漏洞对使用镜像的用户进行攻击。
(2)镜像仓库安全风险。主要包含两个方面的风险：一是如果私有镜像仓库的配置不当，攻击者可利用漏洞直接通过公网访问私有仓库并随意篡改仓库镜像；二是用户以明文形式下载镜像，容易遭遇中间人攻击，攻击者能够篡改镜像内容或者冒名发布恶意镜像。
(3)构建镜像安全风险。两种Docker镜像的构建方式：一是使用Docker commit命令行方式构建，直接提交容器并生成镜像；二是编写Dockerfile指令，按照指令构建一个新镜像。文献[5]研究表明，Docker Hub平台上的Dockerfiles文件存在两个问题：一是构建过程违背Dockerfile最佳实践，如未明确标记镜像版本等；二是Dockerfiles文件包含恶意代码脚本，导致存在主机文件泄露等安全问题。
容器是一种轻量级的虚拟化方式，且不拥有独立的资源配置，没有做到系统内核层面的隔离。
(1)容器隔离安全风险。与虚拟机相比，Docker缺少虚拟化层，在文件隔离方面并不完善，如容器仍然可以访问主机系统的/proc和/sys目录，攻击者可以获取/proc/kallsyms中的内核符号来构建针对内核漏洞的攻击。针对存储资源，Cgroups未对主机存储资源进行限制。若容器不断向存储空间写入数据直至耗尽，将造成主机或容器的拒绝服务。
(2)容器逃逸攻击。容器逃逸是指容器“逃出”自身权限，能够对宿主机和其他容器进行非法访问。容器逃逸的方式有很多种：一是利用容器的配置不当，如Docker高危启动参数等；二是利用Docker软件本身存在的安全漏洞，如容器逃逸著名案例Shocker攻击通过调用open_by_handle_at函数来获取宿主机的资源；三是利用内核漏洞进行容器逃逸，如通过内核漏洞非法进入内核上下文，获取当前进程的有关数据，切换当前命名空间来获取root shell，实现容器逃逸。
Docker网络驱动包含桥接网络、MacVLAN和Overlay这3种模式，如图3所示。Docker默认的网络驱动是桥接网络。
桥接网络的容器之间共用未过滤的Docker0网桥来进行通信；MacVLAN与主机的网络接口连接，容器之间没有访问权限限制；Overlay主要利用虚拟扩展局域网(Virtual eXtensible Local Area Network，VXLAN)技术，在主机之间的网络上构建出新的虚拟网络，但未实现流量加密。3种组网模式都存在一定的安全风险，容器易遭受地址解析协议(Address Resolution Protocol，ARP)欺骗、嗅探、广播风暴和拒绝服务等攻击，造成敏感信息泄露和网络服务功能受限等危害。
容器之间的网络流量控制主要利用Iptables命令进行基于IP的访问控制。但是容器的IP是动态的，创建或重新启动容器会分配一个新IP，Iptables命令都需要调整。因此，从性能和安全性两方面为容器指定安全策略是一个挑战，因为每当重新创建容器时，必须更新这些策略，并且在策略更新期间也应锁定Iptables的策略表。此外，Iptables的限制范围有限，容器网络仍然容易受到数据链路层攻击，如ARP欺骗等。每个容器需要不同的网络策略，策略的总数将随着容器数量的增加而增加，容易产生网络策略爆炸，容器生态系统的性能和安全性都将受到影响。
Docker安全增强技术主要包括利用Linux内核安全机制、可信计算的单容器安全增强，以及基于访问控制策略容器间运行安全控制等。
(1)基于命名空间和内核模块(Linux Kernel Module，LKM)来缓解容器隔离安全风险。Jian等人通过动态检查主机命名空间的方式，实现了对异常进程的有效检测，防止逃逸行为。陈莉君等人提出了基于LKM的Docker资源信息隔离方法，利用系统调用劫持技术来覆写进程文件内容，建立有效的资源隔离机制。
(2)基于AppArmor机制增强容器安全，缓解了容器逃逸和特权提升等攻击。在AppArmor的默认配置文件中并没有限制网络和capability规则，攻击者可以通过受损容器危害宿主机。Loukidisandreou等人提出Docker-Sec方法，通过静态分析容器执行参数和动态监测运行状态来生成AppArmor配置文件，但该方法无法防御用户空间攻击。Mattetti等人提出了LiCShield框架，利用SystemTap方法跟踪系统内核操作并生成包含5种规则的AppArmor配置文件，但LiCShield生成的文件作用范围只在Docker守护进程。Zhu等人提出的Lic-Sec将Docker-Sec与LiCShield相结合，动态分析生成AppArmor配置文件。其能够提供更高级别的保护，防止所有的特权提升攻击，包括Docker-Sec无法防御的用户空间攻击。Lic–Sec的流程如图4所示。
(3)基于Seccomp机制增强容器安全。在Linux的300多个可用系统调用中，Seccomp默认会在配置文件中阻止其中44个系统调用，但剩余的系统调用仍有可能被滥用从而对系统造成安全威胁。Lei等人提出了分阶段执行应用程序容器SPEAKER，将容器分成启动阶段和运行阶段，使用strace工具对系统调用进行跟踪并生成Seccomp配置文件，但是动态分析无法覆盖容器全部的系统调用。Wan等人提出了一种基于自动测试的沙箱容器挖掘方案(Mining Sandboxes)，使用测试套件对容器进行测试并跟踪系统调用，分析日志生成Seccomp配置文件，同样动态分析无法覆盖容器全部的系统调用。Ghavamnia等人提出Confine工具，使用静态和动态分析来检测出容器内的应用程序及其所有依赖项，识别容器正确操作所需的系统调用，并生成Seccomp配置文件。基于AppArmor机制和Seccomp机制的6种方法的具体比较如表3所示。
(4)基于可信计算增强容器安全。2015年，Intel推出指令集扩展(Software Guard Extensions，SGX)，可用于保护不受信任主机上运行的容器和其他应用程序。Arnautov等人提出了基于SGX机制增强Linux容器安全(Secure Linux Containers with Intel SGX，SCONE)来保护容器免受外部攻击，但是该方法对于硬件设备的限制过高，无法进行大范围推广。王鹃等人 利 用可信计算技术，提出了 Docker 安全增强系统DockerGuard，构造了一条从底层硬件到容器的信任链，增强运行过程的安全。但该方案牺牲 了 Docker 容器原有的便捷、快速部署的特性，并且难以根据Docker版本的更新进行实时更新。
(5)微服务环境中的容器间访问控制。云服务应用程序通常由许多微服务组成，而73%的微服务部署在容器当中。为了防止正常的微服务被其他恶意的微服务随意访问，需要有细粒度的访问控制策略来支撑。Li等人提出了自动增强访问控制工具AUTOARMOR，具有以下特点：一是利用基于静态分析的请求提取机制，从微服务源码中自动获取微服务间的调用逻辑；二是利用基于图形的策略管理机制，通过权限图来实现策略的更新。实验表明，AUTOARMOR能够以较小的开销有效地生成微服务间的访问控制策略，成功阻止了访问未经授权的微服务、访问未经授权的资源和执行未经授权的操作3种未经授权请求攻击，缓解了容器网络安全风险。但该方法仍存在以下问题：
服务应用程序通常由许多微服务组成，而73%的微服务部署在容器当中。为了防止正常的微服务被其他恶意的微服务随意访问，需要有细粒度的访问控制策略来支撑。Li等人提出了自动增强访问控制工具AUTOARMOR，具有以下特点：一是利用基于静态分析的请求提取机制，从微服务源码中自动获取微服务间的调用逻辑；二是利用基于图形的策略管理机制，通过权限图来实现策略的更新。实验表明，AUTOARMOR能够以较小的开销有效地生成微服务间的访问控制策略，成功阻止了访问未经授权的微服务、访问未经授权的资源和执行未经授权的操作3种未经授权请求攻击，缓解了容器网络安全风险。但该方法仍存在以下问题：一是请求识别依赖于服务间通信库的建立和语义模型，当通信库的建模不完整时，会导致请求不被识别；二是即使通信库建模是正确的，无用代码也会带来误报。
镜像安全风险一直是学术界的研究热点。目前的镜像安全检测工具主要分为开源工具和商用工具。本文对代表性的开源工具进行性能对比，如表4所示。
Javed等人使用Clair、Anchore和Microscanner这3种扫描工具对59个承载Java应用程序的容器进行扫描，发现现有的工具准确性普遍不高，准确率最高的Anchore漏掉了34%的漏洞，原因是只有Anchore能够扫描非系统包，同时准确率依赖于现有的漏洞数据库和漏洞检测方式。Zheng等人介绍了一种基于继承图的安全检测系统ZeroDVS，通过2 000个镜像的rootfs配置信息，建立有镜像继承关系的图形数据库，并预先存储父镜像信息。在扫描镜像漏洞时，与数据库匹配批量识别父镜像源的漏洞，此时只需扫描未匹配的子镜像层的安全漏洞，提高了安全扫描效率。
容器安全检测工具大多是针对镜像进行静态扫描检测。基于机器学习的检测技术主要是对容器运行时的状态(系统调用、文件输入/输出、网络输入/输出、调度程序和内存等)进行特征提取，然后使用分类器进行训练检测。检测技术分为无监督学习检测方法和有监督学习检测方法。
(1)无监督学习检测方法。Tunde-onadele等人发现仅对容器进行静态漏洞扫描是不够的，于是提出了4种无监督机器学习方法，包括K近邻法(K–Nearest Neighbor，KNN)、主成分分析(Principal Component Analysis，PCA)结合KNN、K均值(K–Means)、自组织映射算法(Self–Organizing Map，SOM)，把系统调用频率作为特征向量，通过实验比较，SOM的检测准确率最好，达到78.57%，但都没有达到较高的准确率。Srinivasan等人提出了一种实时入侵检测系统模型，利用N–grams系统调用计算概率，然后使用最大似然估计器和简单良好的图灵平滑技术来处理跟踪，检测异常的准确率可达到87%~97%。
(2)有监督学习检测方法。Abed等人将系统调用包(Bag of System Calls，BoSC)与滑动窗口技术结合，只跟踪当前窗口中系统调用的频率，把规定窗口内不同的系统调用的频率映射成序号，并作为特征向量来进行判别训练。该方法具有较高的检测率，真阳性率达到100%，但该方法对训练要求高。Tien等人提出KubAnomaly系统，使用4层全连接层构造神经网络，利用系统调用作为特征向量来创建分类模型，实现了高达96%的检测准确率，并成功识别了4次真实环境下的攻击。但应用该系统需要在客户机上安装代理软件，可能会面临通过代理软件进行攻击的威胁。季一木等人利用基于系统调用序列和系统调用频率的入侵检测方法，结合滑动窗口与优化后的词的逆文档频率(Term Frequency–Inverse Document Frequency，TF-IDF)算法提取系统调用特征，通过对比特征相似度进行分类。得出的实验结果表明，该方法检测准确率高达99.71%。但该方法只能预测容器内是否出现异常操作，未能对异常进行分类和规避。
溯源图技术能够细粒度地跟踪系统的数据流，是全面安全监控和对历史攻击行为建模的有效手段。但容器的命名空间机制使数据流中引入了碎片和模糊性。碎片是指顶点分裂，导致溯源图中的节点错误连接。模糊性是指顶点合并，其中一个顶点表示溯源图中的多个不同对象。
Hassan等人提出Winnower工具能够将进程从不同的容器中区分开来，但是缺少命名空间感知，导致容器内的溯源图连接断开。Pasquier等人[34]提出CamFlow工具能够生成命名空间感知的溯源图，但是不能有效地捕获基本的容器语义(即容器边界)，无法判断溯源子图属于哪一个容器。
Chen等人提出利用CLARION工具来解决命名空间带来的挑战。针对PID命名空间带来的影响，可以使用内核数据结构获取主机与容器之间PID的映射；针对Mount命名空间带来的影响，可以使用与chdir关联的当前工作目录查找容器根目录的主机路径，在文件路径上建立主机容器映射；针对Network命名空间带来的影响，设计了一个基于Netfilter的解决方案，用于跟踪主机容器IP/端口映射；针对IPC命名空间带来的影响，向每个IPC对象添加一个IPC命名空间ID，可以唯一区分来自不同容器的IPC对象。实验表明，该工具能够生成正确的容器溯源图，在容器内的攻击能够被准确地检测和溯源。
2018年殷康的研究表明在镜像仓库中，大部分镜像标签并没有指定版本号，导致用户可能下载同一个镜像名的不同版本的恶意镜像。基于此，作者设计出一种面向Docker镜像的标签自动推荐方法，该方法基于Dockerfile相似度和基于标签的隐含狄利克雷分布(Labeled Latent Dirichlet Allocation，L-LDA)模型，实现了一种多模型融合的镜像标签推荐方法。针对10万个Dockerfile文件，该方法能够提升25.6%的镜像构建成功率，同时能识别正确的镜像版本号并完成下载，提高了用户使用镜像的安全性。
2022年Liu等人研究了关于容器注册中心的注册表拼写的安全问题。作者通过精心构造镜像的标签，并将该镜像上传至镜像仓库，实验表明，用户确实存在因标签拼写错误而拉取作者上传的镜像。因此，作者提出了CRYSTAL工具，利用收集到的镜像标签数据打包成文件供CRYSTAL查询，帮助容器注册中心发现潜在的拼写错误的镜像标签，在用户下载镜像时，提醒用户是否存在拼写错误并提供正确的标签选项。作者实现了CRYSTAL的原型，达到了97.5%以上的检测率，提高了用户使用镜像的安全性。由于CRYSTAL工具在Docker命令行上实现，所以对于其他拉取镜像的方式，如使用Dockerfile文件拉取镜像，CRYSTAL工具无法检测使用，下一步将CRYSTAL工具扩展到注册表，进一步缓解因拼写错误而下载恶意镜像的风险。
容器镜像通常被构建在其他镜像上，使得镜像代码量逐步增加，软件规模不断扩大且复杂性显著增加，导致容器性能下降，安全漏洞增加。优化镜像大小常用的方法是在构建Dockerfile时通过命令来缩减镜像体积大小，如多阶段构建等。Docker官方推出了一款开源的缩减工具Docker-Slim。Docker-Slim通过镜像的历史信息，来获取生成镜像的Dockerfile文件及相关的配置信息。通过内核工具解析出镜像中必要的文件和文件依赖，将这些必要文件重新构建成新镜像，其体积最大程度能够缩减30倍。Rastogi等人提出Cimplifier工具，根据最小权限原则将一个容器划分成若干个小容器，每个小容器只运行一个简单应用程序。利用系统调用日志映射出所需的资源，在可执行文件级别上对其进行分区，容器大小可减少58%~95%。减少不必要的文件就相应地减少了攻击者能够利用的攻击面，缓解了容器镜像安全风险。
本文对Docker架构以及基本安全特性进行介绍，分析了Docker面临的安全威胁，对Docker增强、安全检测、瘦身等方面的安全技术进行了分析梳理。但Docker安全问题还有许多待解决的问题值得深入研究：一是研究漏洞评估工具的可用性，研究和对比容器的漏洞扫描器性能、可用性、自动化性以及与当前部署和编排工具的集成问题，需解决0-day、1-day带给Docker的重大安全威胁；二是开发有效、实用和在线的安全补丁解决方案，因为容器在打补丁后需要重启，导致服务器(如Web服务器)产生业务断开；三是关注物联网等资源共享和受限场景下的容器安全问题。
罗汉新,王金双.Docker 容器安全风险和防御综述 [J]. 信息安全与通信保密 ,2022(8):83-93.
作者简介 >>>
罗汉新，男，硕士研究生，主要研究方向为 Docker容器安全；
王金双，男，博士，副教授，主要研究方向为系统安全。
选自《信息安全与通信保密》2022年第8期（为便于排版，已省去原文参考文献）
原文始发于微信公众号（信息安全与通信保密杂志社）：Docker 容器安全风险和防御综述
