一种私有仓库Docker镜像信息采集系统及其采集方法

技术领域

本申请涉及私有仓库Docker镜像信息漏洞扫描技术领域，尤其涉及一种私 有仓库Docker镜像信息采集系统及其采集方法。

背景技术

随着虚拟化技术的高速发展，容器技术逐渐成为各类行业和业务的主流 部署方式，但是其打包和叠加层存储的形式使得对其进行信息采集和深度分 析的难度增加。开发人员的不规范使用、开源软件漏洞、恶意软件注入等在 镜像中的打包注入让基于镜像的容器环境和业务环境存在很多安全隐患。同 时，容器镜像通过容器镜像仓库服务器进行管理和维护已经成为业内的事实 标准，针对其进行的镜像采集和分析成为行业内的重点方向。

面对这样的情况，通常对于远程镜像仓库服务器上的远程镜像的信息采 集和分析方式通过分层解析和合并分析的方式实现。如开源软件Clair通过分 层的方式解析容器镜像，在调用其接口时需要传入镜像层地址及其与父层的 关联关系，以进行解析和扫描，在返回结果时则根据层来返回其与其父层链 的聚合分析结果。然而这样的方式在层的解析时需要人工解析，无法做到自 动化，并且在层分析结果聚合时无法消除层之间相同结果的覆盖性问题，即 上层解决了父层的问题无法在总体结果中体现，并且Clair需要集中式的存储 和分析镜像，在分析中心需要消耗大量的计算和存储性能。

专利CN109918911A提供了一种针对远程仓库的镜像信息采集方式，从 远程仓库中读取镜像的manifest并逐层进行下载扫描，这样的方式同样以层 为单位进行扫描，并对层之间的关系进行聚合反馈，然而该发明没有提及在 层关联时对覆盖性内容的处理方式。通常在镜像分析时更注重以镜像为整体 的分析结果，该发明同样根据单层分析结果进行聚合分析，在扫描分析结果 呈现关系中带来额外的分析和资源消耗，并且可能进行覆盖性检测。

综上，现有镜像扫描方式大多以层扫描并提供镜像层的聚合扫描结果， 带来额外的计算消耗和资源消耗，而少数以镜像为单位的扫描需要适配不同 的叠加存储引擎，通过外部构建叠加存储的方式进行信息镜像信息还原，这 样的方式带来额外的适配和更多的故障点，对原有系统和业务可能带来稳定 性影响，具有一定缺陷。

发明内容

本申请的提供一种私有仓库Docker镜像信息采集系统，包括Docker镜 像采集中心和私有仓库服务器；所述私有仓库服务器包括镜像仓库，所述镜 像仓库由Docker镜像组成；

所述Docker镜像采集中心包括配置模块、采集任务模块、存储模块和网 络模块；

所述配置模块包括配置Docker镜像采集中心的网络通信地址以及配置 私有仓库服务器的权限认证信息；

所述采集任务模块用于获取私有仓库服务器中的镜像列表，根据获取的 镜像列表创建采集任务，向私有仓库服务器下发采集任务，待私有仓库服务 器完成采集任务后收集采集结果；其中，所述镜像列表至少包括镜像仓库名、 镜像标签和镜像ID；

存储模块用于提供系统底层存储以支撑整体系统；

网络模块用于提供网络通讯，实现远程网络交互；

其中，所述Docker镜像采集中心在待采集镜像的私有仓库服务器上设置 采集代理；采集代理能够获取Docker镜像采集中心的配置模块的信息；通过 获得私有仓库服务器的权限认证信息，采集代理获得对本地私有仓库服务器 读写和调用的权限；通过获得的Docker镜像采集中心的网络通信地址，采集 代理能够将采集到的镜像信息发送至Docker镜像采集中心；

采集代理包括本地采集模块和远程任务执行模块；本地采集模块用于获 取本地私有仓库服务器上待采集的镜像列表；远程任务执行模块用于执行 Docker镜像采集中心下发的采集任务，通过编译文件创建具有采集功能的新 镜像和创建以新镜像为运行基础的容器。

其中，远程任务执行模块至少包括任务解析单元、任务执行单元和资源 清理单元；其中，任务解析单元用于解析Docker镜像采集中心下发的采集任 务；任务执行单元用于对解析后的采集任务进行逻辑组织和执行；资源清理 单元用于清理采集任务结束后的各项资源，包括收集容器运行结果和容器运 行日志、删除容器和镜像文件。

其中，所述Docker镜像采集中心的网络通信地址包括IP地址和服务端口。

其中，私有仓库服务器的权限认证信息包括私有仓库服务器类型、私有仓 库服务器认证类型和私有仓库服务器认证信息；其中，私有仓库服务器认证 类型包括但不限于账号密码方式和Token方式，其对应的私有仓库服务器认 证信息包括用户名、密码和Token。

其中，Docker镜像采集中心和采集代理通过容器指令接口或通过私有仓 库服务器API获取私有仓库服务器中镜像列表。

本申请还提供一种使用如上述的私有仓库Docker镜像信息采集系统的 Docker镜像信息采集方法，步骤具体包括：

S10，配置Docker镜像采集中心的网络通信地址以及私有仓库服务器的 权限认证信息；

S20，Docker镜像采集中心获取远程私有仓库服务器中的镜像列表；其 中，镜像列表至少包括镜像仓库名、镜像标签以及镜像ID；

S30，Docker镜像采集中心根据获得的镜像列表建立采集任务，在待采 集的镜像所在的私有仓库服务器上设置采集代理；将采集任务发送至对应采 集代理；其中，所述采集任务至少包括采集任务编号和待采集的镜像；

S40，采集代理获得Docker镜像采集中心的本地私有仓库服务器的权限 认证信息，采集代理获取本地私有仓库服务器上待采集的镜像列表，为待采 集的镜像增加用于信息采集的镜像层以构建新镜像：其中，增加的镜像层具 有能够将镜像内容压缩放入采集文件夹中，并向Docker镜像采集中心发送采 集文件夹中的镜像文件压缩包的功能；根据增加镜像层后的新镜像，建立以 新镜像为运行基础的容器；

S50，在安全环境下启动容器，同时提供Docker镜像采集中心的网络通 讯地址，容器自动将采集文件夹中的镜像文件压缩包发送给Docker镜像采集 中心；

S60，采集代理持续管理容器的状态，并在镜像采集任务结束时回收资 源；当所有采集任务完成时，采集代理向Docker镜像采集中心反馈采集任务 的结果。

其中，在步骤S20中，还包括步骤S21，在建立采集任务时，当相同ID 的镜像已经在采集任务列表中时，跳过该镜像的采集任务。

其中，Docker镜像采集中心和采集代理使用Docker API或者容器指令获 取私有仓库Docker镜像列表。

其中，在步骤S40中，使用Dockerfile编译文件为基础镜像添加新镜像 层，在基础镜像的相同目录下添加采集文件夹和压缩工具文件夹；增加的镜 像层具有将基础镜像压缩成的压缩包放入采集文件夹中，并向Docker镜像采 集中心发送采集文件夹中的镜像文件压缩包的功能。

其中，Docker镜像采集中心向采集代理发送的采集任务和采集代理向 Docker镜像采集中心反馈的采集任务的结果都以JSON表示。

本申请实现的有益效果如下：

本发明基于镜像为单位进行信息采集与扫描，从而减少分层采集时带来 的存储消耗，同时以镜像为单位进行信息采集还可以去除不同层相同文件名 文件的重复扫描消耗，提高扫描效率，降低扫描中计算消耗。另外，本发明 基于容器本身特性，通过对镜像增加具有采集功能的新镜像层的方式构建新 镜像，并通过构建新镜像对应的容器以此自动完成采集，对比现有技术，本 发明没有适配不同的容器存储驱动和容器存储类型，通过容器原生方式降低 错误平面，提高系统稳定性。同时，通过采集代理进行采集任务的具体执行， 以此可以将原本采集中心统一执行的镜像拉取和镜像分析任务分散在各私有 仓库服务器宿主机上，降低分析中心的计算和存储压力，提高整体效能和并 发处理能力。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实 施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面 描述中的附图仅仅是本申请中记载的一些实施例，对于本领域技术人员来讲， 还可以根据这些附图获得其他的附图。

图1a、1b为Docker镜像的内容进行更改时镜像层文件的逻辑结构图。

图1c为容器运行时将镜像作为一个整体进行读取时的逻辑结构图。

图2为本申请私有仓库Docker镜像信息采集系统的逻辑结构图。

图3为本申请私有仓库Docker镜像信息采集方法的步骤流程图。

图4为本申请私有仓库Docker镜像信息采集系统的网络分布结构图。

具体实施方式

下面结合本申请实施例中的附图，对本申请实施例中的技术方案进行清 楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全 部的实施例。基于本申请中的实施例，本领域技术人员在没有做出创造性劳 动前提下所获得的所有其他实施例，都属于本申请保护的范围。

Docker是一个开源的应用容器引擎，让开发者可以打包应用以及依赖 包到一个可移植的容器中，然后发布到任何流行的Linux或Windows机器 上，也可以实现虚拟化，容器是完全使用沙箱机制，相互之间不会有任何接 口。

一个完整的Docker有以下几个部分组成：客户端(Client)、守护进程(Daemon)、镜像(Image)以及容器(Container)。

其中，Docker镜像类似于虚拟机中的镜像，是一个包含有文件系统的面 向Docker引擎的只读模板，任何应用程序运行都需要环境，而镜像就是用来 提供这种运行环境的，Docker镜像是一种多层文件结构，每一层都被称为一 个镜像层(Layers)，我们可以将Docker镜像的多层结构看成一个统一文件系 统(联合文件系统)，Docker进程认为整个文件系统是以读写方式挂载的。 所有的Docker镜像都起始于一个基础镜像层，也就是父层。当对镜像进行 修改或者增加新的内容时，就会在当前所有镜像层之上，创建新的镜像层。也及时说，当产生变更时，属于下层的原始的镜像文件不会发生变化，所有 的变更都发生在顶层，一个镜像层的内容如果修改、替换，也不是发生在该 镜像层上，而是在上层镜像层中进行。

Docker容器，是Docker镜像的一个应用实例，容器可以被创建、启动、 停止、删除，各个容器之间是是相互隔离的，互不影响。Docker容器类似于 一个轻量级的沙盒，可以将其看作一个极简的Linux系统环境(包括root权 限、进程空间、用户空间和网络空间等)，以及运行在其中的应用程序。

当Docker容器从Docker镜像启动时，Docker在所有的镜像层之上创建 一个可写层，Docker镜像本身不变，这样如果要删除容器时，直接删除容器 可写层即可。

Docker镜像仓库(Reposity)是保存Docker镜像的地方，注册服务器是 存放镜像仓库的具体服务器；注册服务器可有多个镜像仓库，每个仓库可以 有多个镜像；镜像仓库相当于一个具体的项目或目录，具有自己的访问地址， 例如镜像仓库地址为d1.dickerpool.com/ubuntu，其中，d1.dickerpool.com是 注册服务器地址，ubuntu是仓库名。

其中，Docker镜像仓库的按照访问权限类型分为公共仓库和私有仓库。 公有仓库是开放的，允许所有用户匿名下载镜像。私有仓库是其他用户不可 见的，只有有权限的账户登录才能下载镜像，存放私有仓库的服务器即为私 有服务器，常用的私有仓库服务器一般为Registry和Harbor。

镜像仓库(Reposity)作为镜像的集合，一般是将应用不同版本的同一 镜像放置在同一个仓库中，仓库名即为镜像名，版本号以标签号(Tag)来 表示，镜像还具有自己本身唯一标识ID。根据仓库名、标签和ID，能够具 体定位一个镜像(仓库名、标签之间采用“:”分隔)。

Dockerfile是一个用来构建镜像的文本文件，文本内容包含了构建镜像 所需的指令和说明。比如，Dockerfile从FROM命令开始，紧接着跟随各种 方法、命令和参数，可以使用docker build指令建立镜像，使用指令docker run 启动容器。

API(Application Programming Interface,应用程序编程接口)是一些预先 定义的函数，能够提供应用程序与开发人员基于某软件或硬件得以访问一组 例程的能力，而又无需访问源码，或理解内部工作机制的细节。Docker API 就是Docker给应用程序的调用接口。

使用Docker API时，由系统识别本地主机容器环境，并适配不同容器版 本进行API调用获取信息；使用容器指令时，则是使用Docker系统指令获取 信息。

对远程服务器获取交互信息的通讯方式采用JSON,JSON(JavaScript ObjectNotation,JS对象简谱)是一种轻量级的数据交换格式。它基于 ECMAScript(欧洲计算机协会制定的js规范)的一个子集，采用完全独立于编 程语言的文本格式来存储和表示数据，层次结构简洁清晰，易于人阅读和编 写，同时也易于机器解析和生成，并有效地提升网络传输效率。

Docker镜像所使用的分层存储的概念，除当前层外，之前的每一层都是 不会发生改变的，换句话说，任何修改的结果仅仅是在当前层进行标记、添 加、修改，而不会改动当前层下面的其他层，如图1a、图1b所示，镜像Image 的第一层镜像层(Lay1)包括文件1、文件2和文件3，在第一层之上的第二 层(Lay2)包括文件4、文件5和文件6，在第二层之上的第三层(Lay3) 对文件5做出了更改，使用文件7替换了文件5，由于镜像是用上层的层文 件对下层的层文件做出修改，因此第二层中的文件5在第二层上不会被直接 替换，而是在第三层上做出替换的更改。

而以这个Docker镜像为基础，启动镜像对应的容器后，在docker服务 的帮助下，能够以单层的方式读取镜像的内容，如图1c所示，容器启动后， 虽然Docker镜像的层文件在基本存储方式上没有改变，但容器运行起来以后， 从用户的角度上来看，docker对镜像的读取就是在读一个整体，也就是说， 把镜像的多层结构在逻辑上合并为一层，逻辑结构上的合并状态如图1c所示， 得到的是原有的镜像文件经过多层更改后最终的状态。

根据以上的技术，本申请提供一种私有仓库Docker镜像信息采集系统， 包括Docker镜像采集中心和私有仓库服务器；

其中，所述Docker镜像采集中心在私有仓库服务器上设置有采集代理；

所述Docker镜像采集中心包括配置模块、采集任务模块、存储模块和网 络模块；

配置模块用于对所述Docker镜像采集中心的网络地址和服务端口进行 配置，和对远程私有仓库服务器的基本信息进行配置；通过Docker镜像采集 中心的网络地址和服务端口，采集代理能够向Docker镜像采集中心发送压缩 过后的镜像文件。

其中，私有仓库服务器的基本信息包括私有仓库服务器类型、私有仓库 服务器认证类型、私有仓库服务器认证信息。

所述采集任务模块用于获取私有仓库服务器中的镜像列表，根据获取的 镜像列表创建采集任务，向私有仓库服务器下发采集任务，待私有仓库服务 器完成采集任务后收集采集结果；其中，所述镜像列表至少包括镜像仓库名、 镜像标签和镜像ID；

存储模块用于提供系统底层存储以支撑整体系统，包括文件存储、数据 存储、存储监控能力，具体可供镜像信息存储、采集任务存储、采集结果存 储以及其他存储等功能使用。

网络模块用于管理系统网络，提供基本网络联通能力，并使系统能够对 远程进行实现网络互联和交互。

其中，所述Docker镜像采集中心在待采集镜像的私有仓库服务器上设置 采集代理；采集代理能够获取Docker镜像采集中心的配置模块的信息；通过 获得私有仓库服务器的权限认证信息，采集代理获得对本地私有仓库服务器 读写和调用的权限；通过获得的Docker镜像采集中心的网络通信地址，采集 代理能够将采集到的镜像信息发送至Docker镜像采集中心；

采集代理包括本地采集模块和远程任务执行模块；本地采集模块用于获 取本地私有仓库服务器的镜像列表；远程任务执行模块用于执行Docker镜像 采集中心下发的采集任务，通过编译文件创建具有采集功能的新镜像和创建 以新镜像为运行基础的容器。

其中，远程任务执行模块至少包括任务解析单元、任务执行单元和资源 清理单元。

任务解析单元用于解析Docker镜像采集中心下发的采集任务。

任务执行单元用于对解析后的采集任务进行逻辑组织和执行采集任务。

资源清理单元用于清理采集任务结束后的各项资源，包括收集采集容器 运行结果、采集容器运行日志、删除容器以及删除镜像文件。

本申请还提供了一种使用上述的私有仓库Docker镜像信息采集方法，所 述方法的步骤具体包括：

对Docker镜像采集中心的网络地址和服务端口进行配置，对远程私有仓 库服务器的基本信息进行配置；

私有仓库服务器的基本信息包括私有仓库服务器类型、私有仓库服务器 认证类型、私有仓库服务器认证信息。

其中，私有仓库服务器认证类型包括但不限于账号密码方式和Token方 式，其对应的私有仓库服务器认证信息包括用户名、密码和Token。

Docker镜像采集中心获取各远程私有仓库服务器中的镜像列表；

其中，镜像列表包括镜像仓库服务器上所有镜像的基础信息，或根据需 要下载特定镜像的基础信息；镜像基础信息至少包括镜像ID、仓库(Reposity)、 标签(Tag)；

其中，Docker镜像采集中心获取各远程私有仓库服务器中镜像列表的方 式，可以通过容器指令接口获取，也可以通过私有仓库服务器API获取。

例如，在具体操作中，Docker镜像采集中心通过Registry私有仓库服务 器的API接口获取该私有仓库服务器上的镜像仓库，具体接口如下：

GET/v2/_catalog

通过如下接口获取镜像标签和镜像ID：

GET/v2//tags/list

该Registry私有仓库服务器收到指令后，则会将镜像列表以JSON的形 式发送至Docker镜像采集中心。

Docker镜像采集中心获得镜像列表后，建立采集任务，在待采集镜像的 私有仓库服务器宿主机上部署采集代理；Docker镜像采集中心向采集代理发 送其本地私有仓库服务器的基本信息，同时将采集任务发送至对应采集代理；

其中，Docker镜像采集中心向采集代理发送的采集任务至少包括采集任 务编号和待采集的镜像；

例如，在具体实施中，Docker镜像采集中心向采集代理发送的采集任务 以如下JSON形式表示：

也就是说，Docker镜像采集中心向采集代理发送的任务编号为231，有 两个待采集的镜像，分别是仓库名为mysql、标签为5.3、ID为 e4247c08758ef42f3f7d1079d20718eea6c414015a86950d748745a60ad73fd4的镜 像和仓库名为python、标签为3.7.1-alpine、ID为 020295c920c635bbb25e4c73e026834e1bbfc5225955d0ecd63016c5d78bc0ca的＝ 镜像。

其中，由于镜像能够以镜像本身的镜像ID唯一区分，因此具有相同ID 的镜像仅需采集一次，当相同ID的镜像已经被采集时，无需进行该镜像的采 集任务。

采集代理为采集任务中待采集的镜像增加用于信息采集的镜像层以构建 新镜像：

其中，采集代理根据采集任务，获取本地私有仓库服务器上所需采集的 镜像，获取的方式可以使用镜像仓库API接口的方式，也可以使用容器指令 获取。

其中，为待采集的镜像增加用于信息采集的镜像层以构建新镜像，需要 构造基础镜像编译文件，本实施例中，以mysql:5.3镜像为例，其基础 Dockerfile如下所示：

FROM mysql:5.3

RUN mkdir-p/scan

RUN mkdir-p/scantools

COPY/tools//scantools

RUN/scantools/tar-zcvf../scan/scaninfo_mysql_5.3.tar.gz`find/-path /scantools-path'/scan'-o-path/tar-a-prune-maxdepth 1-o-print|sed 1d`scanscantools

CMD[“/scantools/push$CIP$CPORT../scan/scaninfo_mysql_5.3.tar.gz”]

docker build-t mysql:5.3-scan.

docker run-itd-e CIP＝10.10.10.10-e CPORT＝8080--name

mysql:2.175.3-scan-container mysql:2.175.3-scan

所述Dockerfile文件中，将mysql:5.3作为基础镜像，在基础镜像的相同 目录下添加采集文件夹scan和压缩工具文件夹scantools；使用指令在基础镜 像上增加镜像层，增加的镜像层具有将基础镜像的文件内容通过scantools内 的压缩工具压缩形成镜像文件压缩包scaninfo_mysql_5.3.tar.gz， scaninfo_mysql_5.3.tar.gz放入采集文件夹scan中，向Docker镜像采集中心发 送采集文件夹中的镜像文件压缩包scaninfo_mysql_5.3.tar.gz的功能，根据 Dockerfile编译增加镜像层后的新镜像，建立以新镜像为运行基础的mysql: 5.3-scan的容器mysql:2.175.3-scan-container；启动容器的同时提供Docker镜 像采集中心的网络ip地址10.10.10.10和服务端口8080，容器能够自动将采 集文件中的镜像文件压缩包scaninfo_mysql_5.3.tar.gz通过网络地址和服务端 口发送给Docker镜像采集中心。

其中，由于新镜像容器也会执行原始镜像容器所有的指令操作，因此为 了保证运行安全，新镜像容器需要在安全环境中运行。

当新镜像构建成功后，docker会返回一个镜像的整体id，运行容器时， 就可以通过这个id读写容器的方式，将所有镜像当做一个整体来进行读写， 在整体的底层指向多层内容。

在Dockerfile命令语句中，CMD语句是最后执行的，也就是说，容器 运行以后，会将压缩后的镜像文件发送到Docker镜像采集中心。在容器启动 后，我们能够得到镜像文件压缩包的多层镜像文件形式以单层结构的读取， 从而得到逻辑结构上合并后的镜像文件，对其进行漏洞扫描，就相当于是对 合并成一层的的最终状态的镜像进行扫描，此时不需要分层解析，也不需要 使用多个引擎，直接进行漏洞扫描即可。

采集代理持续管理以新镜像为运行基础的容器的状态，并在镜像采集任 务结束时回收资源；

其中，在构建并启动容器后，持续监控该容器，当容器停止运行时，记 录容器日志和停止结果，并删除容器，删除镜像，回收资源。

当所有采集任务完成时，采集代理向Docker镜像采集中心反馈采集任务 的结果，

采集任务结果包括采集任务ID和对每个采集任务中镜像的采集结果，在 本实施例中以JSON表示如下。

私有仓库容器镜像信息采集中心接收采集任务结果后结束采集任务。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了 基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权 利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。 显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请 的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及 其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。