基于自建知识库的容器方法与流程

文档序号:28492090发布日期:2022-01-15 02:59阅读:87来源:国知局
基于自建知识库的容器方法与流程

1.本发明涉及一种容器建立方法,尤其涉及一种基于自建知识库的容器方法。


背景技术:

2.随着越来越多的企业将数据和工作负载迁移到云上,很多企业都依赖与容器——将代码及其相关项封装在一起的软件单元,以便应用程序在不同的计算环境之间迁移时能够可靠运行。clemson大学云架构师colemcknight表示,容器化被认为是一种以安全方式部署应用程序和服务的强大技术。
3.容器提供了将应用程序的代码、配置、依赖项打包到单个对象的标准方法。容器建立在两项关键技术之上:linux namespace和linux cgroups。
4.常见的容器一共有7个攻击面:linux kernel、namespace/cgroups/aufs、seccomp-bpf、libs、language vm、user code、container(docker)engine。容器的内核与宿主内核共享,使用namespace与cgroups这两项技术,使容器内的资源与宿主机隔离,所以linux内核产生的漏洞能导致容器逃逸。因此,容器的安全检测尤为重要。
5.现有容器检测如clair,可以对本地容器进行检测,依赖于nvd漏洞知识库。clair定期从配置的源获取漏洞元数据然后存进数据库。客户端使用clair api处理镜像,获取镜像的特征并存进数据库。客户端使用clair api从数据库查询特定镜像的漏洞情况,为每个请求关联漏洞和特征,避免需要重新扫描镜像。当更新漏洞元数据时,将会有系统通知产生。
6.另外,还有webhook用于配置将受影响的镜像记录起来或者拦截其部署。clair可以直接集成到容器仓库中,以便仓库负责代表用户与clair进行交互。这种类型的设置避免了手动扫描,并创建了一个合理的接收端以便clair的漏洞通知到位。仓库还可用于授权,以避免泄露用户不应当访问的镜像漏洞信息。clair可以集成到ci/cd管道中,如此一来当生成镜像时,将镜像推送到仓库之后触发clair扫描该镜像的请求。
7.但是,现有的知识库扫描建立时存在如下的缺陷:
8.1、使用如clair等工具扫描,因涉及到知识库更新,解析前需更新知识库解析速度慢。
9.2、目前主流镜像扫描工具都是用的nvd(美国国家漏洞库),不支持其他漏洞来源,对国内软件、漏洞支持不到位。同时,不能支持未公开的漏洞。
10.3、若使用clair等工具扫描,只能扫描本地的镜像仓库,对代码中dockerfile里配置的镜像,不能自动扫描。同时,不能扫描远端镜像仓库里的镜像。
11.4、无法支持自定义策略,对特定漏洞、依赖包没有黑白名单等检测机制。
12.5、操作及界面均为英文,本地化支持差。
13.有鉴于上述的缺陷,本设计人,积极加以研究创新,以期创设一种基于自建知识库的容器方法,使其更具有产业上的利用价值。


技术实现要素:

14.为解决上述技术问题,本发明的目的是提供一种基于自建知识库的容器方法。
15.本发明的基于自建知识库的容器方法,其包括以下步骤:步骤一,对漏洞发布平台进行漏洞信息获取,建立知识库;步骤二,提取镜像至本地;步骤三,扫描镜像包;步骤四,结果展示。
16.进一步地,上述的基于自建知识库的容器方法,其中,所述步骤一中,漏洞发布平台包括nvd平台、cnnvd平台、cnvd平台中的一种或是多种,通过爬虫对漏洞发布平台进行爬取,将爬取后的信息建立知识库。
17.更进一步地,上述的基于自建知识库的容器方法,其中,所述爬取的预设为关联项目版本和漏洞关系,所述知识库包含漏洞、软件版本关联表。
18.更进一步地,上述的基于自建知识库的容器方法,其中,所述步骤二中,通过docker构建依赖分层,创建基础镜像、复制文件、编译文件以及入口文件,对docker镜像的扫描,分别获取代码包、镜像包、远程镜像。
19.更进一步地,上述的基于自建知识库的容器方法,其中,所述代码包的获取方式为,提取代码包中的dockerfile文件,获取dockerfile文件中的基础镜像名称、版本,使用docker pull命令拉取所有镜像到本地。
20.更进一步地,上述的基于自建知识库的容器方法,其中,所述镜像包的获取方式为,直接上传镜像包至服务器。
21.更进一步地,上述的基于自建知识库的容器方法,其中,所述远程镜像的获取方式为,提前配置好远程仓库连接方式,利用docker pull命令拉取镜像到本地,利用docker save命令输出镜像二进制文件。
22.更进一步地,上述的基于自建知识库的容器方法,其中,所述步骤三中包括以下步骤:1)解压镜像包,得到分层的镜像文件夹;2)遍历不同层级的文件夹,扫描文件夹中的文件列表,得到文件路径md5值的映射表;3)通过md5值到漏洞知识库检索,若无法得到检索结果,则再利用文件名到知识库中检索,最终得到漏洞列表;4)将扫描结果保存至数据库中。
23.更进一步地,上述的基于自建知识库的容器方法,其中,所述步骤4)中,将解析好的数据以json字符串形式存入数据库。
24.再进一步地,上述的基于自建知识库的容器方法,其中,所述结果展示为取出数据库中的解析结果,以依赖包为单位去重展示。实施期间,可取出数据库中的树形结构json字符串,利用树形结构展示插件进行展示。或是,所述结果展示为表格展示,所述表格展示中包含序号、镜像名、版本、风险等级、推荐修复版本、漏洞内容。
25.借由上述方案,本发明至少具有以下优点:
26.1、能够实现镜像包的扫描,并脱离本地私有仓库环境、网络环境等依赖约束。
27.2、弥补了镜像扫描的缺陷,支持cnnvd/nvd等国内漏洞库。
28.3、能够实现镜像的持续管理,当出现了新的漏洞后,能够及时进行检测解析。
29.上述说明仅是本发明技术方案的概述,为了能够更清楚了解本发明的技术手段,并可依照说明书的内容予以实施,以下以本发明的较佳实施例并配合附图详细说明如后。
附图说明
30.图1是扫描镜像包的实施示意图。
具体实施方式
31.下面结合附图和实施例,对本发明的具体实施方式作进一步详细描述。以下实施例用于说明本发明,但不用来限制本发明的范围。
32.如图1的基于自建知识库的容器方法,其与众不同之处在于包括以下步骤:
33.步骤一,对漏洞发布平台进行漏洞信息获取,建立知识库。实施期间,漏洞发布平台包括nvd平台、cnnvd平台、cnvd平台中的一种或是多种,通过爬虫对漏洞发布平台进行爬取,将爬取后的信息建立知识库。建立期间,可包含去重、翻译、关联项目、关联组件、人工审核等等步骤。这样,可以实现多平台的涵盖,获取较为健全的知识库。同时,爬取的预设为关联项目版本和漏洞关系,知识库包含漏洞、软件版本关联表。
34.步骤二,提取镜像至本地。实施期间,通过docker构建依赖分层,创建基础镜像、复制文件、编译文件以及入口文件,对docker镜像的扫描,分别获取代码包、镜像包、远程镜像。具体来说,代码包的获取方式为,提取代码包中的dockerfile文件,获取dockerfile文件中的基础镜像名称、版本,使用docker pull命令拉取所有镜像到本地。同时,本发明采用的镜像包的获取方式为,直接上传镜像包至服务器。并且,远程镜像的获取方式为,提前配置好远程仓库连接方式,利用docker pull命令拉取镜像到本地,利用docker save命令输出镜像二进制文件。
35.docker构建依赖分层技术,dockerfile中每一条命令都会新建一层,如dockerfile的分层如下:
36.from ubuntu:18.04;
37.copy./app;
38.run make/app;
39.cmd python/app/app.py。
40.以上四条指令会创建四层,分别对应基础镜像、复制文件、编译文件以及入口文件,每层只记录本层所做的更改,而这些层都是只读层。当你启动一个容器,docker会在最顶部添加读写层,你在容器内做的所有更改,如写日志、修改、删除文件等,都保存到了读写层内,一般称该层为容器层。所以对docker镜像的扫描,主要集中在对其镜像层面(image layers)进行扫描。
41.步骤三,扫描镜像包,其包括以下步骤:
42.1、在服务器上通过解压缩命令解压镜像包,得到分层的镜像文件夹。
43.2、利用深度遍历方法遍历镜像各文件夹,扫描文件夹中的文件列表,得到文件路径md5值的映射表。
44.3、通过md5值到漏洞知识库检索,若无法得到检索结果,则再利用文件名到知识库中检索,最终得到漏洞列表。
45.4、将扫描结果保存至数据库中。考虑到实施的便利,可将解析好的数据以json字符串形式存入数据库。
46.步骤四,结果展示。结果展示为取出数据库中的解析结果,以依赖包为单位去重展
示。同时,为了便于实现较为直观的展示,本发明还可以采用表格展示。实施期间,表格展示中包含序号、镜像名、版本、风险等级、推荐修复版本、漏洞内容。
47.在实施期间,将解析好的依赖树以json字符串形式存入数据库。
48.通过上述的文字表述并结合附图可以看出,采用本发明后,拥有如下优点:
49.1、能够实现镜像包的扫描,并脱离本地私有仓库环境、网络环境等依赖约束。
50.2、弥补了镜像扫描的缺陷,支持cnnvd/nvd等国内漏洞库。
51.3、能够实现镜像的持续管理,当出现了新的漏洞后,能够及时进行检测解析。
52.此外,本发明所描述的指示方位或位置关系,均为基于附图所示的方位或位置关系,仅是为了便于描述本发明和简化描述,而不是指示或暗示所指的装置或构造必须具有特定的方位,或是以特定的方位构造来进行操作,因此不能理解为对本发明的限制。
53.术语“主”、“副”仅用于描述目的,而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此,限定有“主”、“副”的特征可以明示或者隐含地包括一个或者更多个该特征。在本发明的描述中,“若干”的含义是两个或两个以上,除非另有明确具体的限定。
54.同样,术语“第一”、“第二”仅用于描述目的,而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此,限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本发明的描述中,“多个”的含义是两个或两个以上,除非另有明确具体的限定。
55.在本发明中,除非另有明确的规定和限定,术语“连接”、“设置”等术语应做广义理解,例如,可以是固定连接,也可以是可拆卸连接,或成一体;可以是机械连接,也可以是电连接;可以是直接相连,也可以通过中间媒介间接相连,可以是两个组件内部的连通或两个组件的相互作用关系。对于本领域的普通技术人员而言,可以根据具体情况理解上述术语在本发明中的具体含义。并且它可以直接在另一个组件上或者间接在该另一个组件上。当一个组件被称为是“连接于”另一个组件,它可以是直接连接到另一个组件或间接连接至该另一个组件上。
56.需要理解的是,术语“长度”、“宽度”、“上”、“下”、“前”、“后”、“左”、“右”、“竖直”、“水平”、“顶”、“底”“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系,仅是为了便于描述本发明和简化描述,而不是指示或暗示所指的装置或组件必须具有特定的方位、以特定的方位构造和操作,因此不能理解为对本发明的限制。
57.以上所述仅是本发明的优选实施方式,并不用于限制本发明,应当指出,对于本技术领域的普通技术人员来说,在不脱离本发明技术原理的前提下,还可以做出若干改进和变型,这些改进和变型也应视为本发明的保护范围。
当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1