淺析Docker容器安全管控方法
一、前言
毫無疑問，容器是當(dāng)前云計算的熱門主流技術(shù)之一。
Docker 通過把應(yīng)用的運(yùn)行時環(huán)境和應(yīng)用打包在一起，解決了部署環(huán)境依賴等問題;它消除了編譯、打包與部署、運(yùn)維之間的鴻溝，有助于提高應(yīng)用開發(fā)、運(yùn)維效率：總之，它與 DevOps 理念不謀而合，受到了很多企業(yè)的推崇。
當(dāng)然 Docker 容器的生命周期中也存在著不少安全隱患，比如容器自身的問題、容器鏡像的問題，還有容器在運(yùn)行時暴露的問題等等。因此，本文將對 Docker 容器生命周期的安全問題及相應(yīng)的改善方法進(jìn)行若干探討，掛一漏萬，拋磚引玉，希望各位讀者予以批評指正!
二、Docker容器生命周期安全問題
在 Docker 容器生命周期內(nèi)的多個階段均可能引入安全問題，本章將分模塊對這些安全問題進(jìn)行淺析，綱舉目張，我們先了解一下 Docker 容器全生命周期安全管控的架構(gòu)，如圖1所示。
圖1. Docker 容器全生命周期安全管控架構(gòu)
這張圖片可以反映 Docker 對其核心——“鏡像” 的 “Build, Ship and Run”(構(gòu)建鏡像、傳輸鏡像與運(yùn)行容器)操作;Docker的應(yīng)用環(huán)境可被分為“非生產(chǎn)環(huán)境”和 “生產(chǎn)環(huán)境” 這兩類。
非生產(chǎn)環(huán)境與 Dev(開發(fā))強(qiáng)相關(guān)，而生產(chǎn)環(huán)境則與Ops(運(yùn)維)強(qiáng)相關(guān)。非生產(chǎn)環(huán)境內(nèi)的主要管控點是鏡像深度掃描，在生產(chǎn)環(huán)境做容器編排時需要從非生產(chǎn)環(huán)境拉取并運(yùn)行Docker鏡像，因此鏡像運(yùn)行控制也是一個主要管控點。
生產(chǎn)環(huán)境內(nèi)的主要管控點是容器系統(tǒng)入侵檢測與防護(hù)以及容器網(wǎng)絡(luò)入侵檢測與防護(hù)。同時，應(yīng)在Docker容器全生命周期中的各個階段將合規(guī)基線問題作為重要的管控點。
下面從Docker容器安全的各個主要管控點出發(fā)，列舉部分它們所應(yīng)對的安全問題。
1. 鏡像深度掃描
在做鏡像深度掃描時，應(yīng)重視的安全問題包括但不限于：
- 鏡像中的操作系統(tǒng)軟件包與應(yīng)用程序依賴項包含已知CVE漏洞
- 鏡像的應(yīng)用目錄被植入Webshell
- 鏡像敏感信息泄露
- 鏡像完整性校驗問題
Dockerfile中存在不安全的寫法(Dockerfile是Docker鏡像的構(gòu)建腳本)
2. 鏡像運(yùn)行控制
在做鏡像運(yùn)行控制時，應(yīng)重視的安全問題包括但不限于：
- 鏡像完整性校驗問題
- 特權(quán)模式共享root權(quán)限
- 內(nèi)存配額未被限制
- CPU優(yōu)先級未被限制
- 存儲空間配額未被限制
- 在啟用容器時使用Host網(wǎng)絡(luò)模式
3. 容器系統(tǒng)入侵檢測與防護(hù)
在做容器系統(tǒng)入侵檢測與防護(hù)時，應(yīng)重視的安全問題包括但不限于：
- 未隔離文件系統(tǒng)
- 調(diào)用有漏洞的系統(tǒng)內(nèi)核函數(shù)
- 拒絕服務(wù)攻擊
4. 容器網(wǎng)絡(luò)入侵檢測與防護(hù)
在做容器網(wǎng)絡(luò)入侵檢測與防護(hù)時，應(yīng)重視的安全問題包括但不限于：
- 容器間的局域網(wǎng)攻擊
- Remote API接口安全
- Docker缺陷架構(gòu)與安全機(jī)制紕漏
- 微服務(wù)架構(gòu)Web應(yīng)用安全問題
5. 安全合規(guī)基線
為了應(yīng)對Docker安全問題，應(yīng)重視的安全問題包括但不限于：
- 內(nèi)核級別
- 網(wǎng)絡(luò)級別
- 鏡像級別
- 容器級別
- 文件限制
- 能力限制
6. Docker及其配套軟件漏洞
在使用Docker及其配套軟件時，應(yīng)重視的安全問題包括但不限于：
- Docker自身漏洞
- K8S(Kubernetes)等編排應(yīng)用自身漏洞
- 鏡像倉庫自身漏洞
注：Docker及其配套軟件漏洞對Docker容器安全問題有著較深的影響，因而將之獨立成一個管控點點?？蓪?ldquo;所使用的Docker及其配套軟件的版本不受已知漏洞影響”作為一條“安全合規(guī)基線”。
三、淺談Docker容器安全現(xiàn)狀改善方法
面對 Docker 容器安全的挑戰(zhàn)，可以 “分而治之”，對各個階段的安全管控點進(jìn)行管控。在實施管控時，也可劃分優(yōu)先級，優(yōu)先考慮較為重要的管控點，推遲考慮較為次要的管控點(例如，“鏡像運(yùn)行控制” 管控點與用戶對 Docker 的使用方式有較大關(guān)聯(lián)?？梢栽诎踩a(chǎn)品中對用戶的危險操作進(jìn)行告警，但不一定要進(jìn)行阻斷。Docker 容器安全產(chǎn)品應(yīng)注重對由用戶的不安全使用方式催生的安全問題進(jìn)行防御)。
下面，結(jié)合行業(yè)實踐經(jīng)驗梳理針對 “鏡像深度掃描”、“容器系統(tǒng)入侵檢測與防護(hù)”、“容器網(wǎng)絡(luò)入侵檢測與防護(hù)” 與 “安全合規(guī)基線” 的管控方法。
1. “鏡像深度掃描” 管控方法
在使用 Docker 鏡像之前使用 Docker 鏡像掃描器有助于發(fā)現(xiàn) Docker 鏡像的安全性問題。基于此，知名的開源鏡像倉庫 Harbor 就集成了鏡像掃描器，如圖 2 所示。
圖2. 知名開源鏡像倉庫Harbor集成了鏡像掃描器
現(xiàn)有鏡像掃描工具基本都具備了 “對軟件漏洞進(jìn)行掃描” 的基礎(chǔ)功能。部分開源項目或商業(yè)平臺具備如下特殊功能：
- 對木馬、病毒、惡意軟件或其他惡意威脅進(jìn)行靜態(tài)分析
- 對主流編程語言的代碼安全問題進(jìn)行靜態(tài)發(fā)現(xiàn)(與開發(fā)工作流緊密結(jié)合)
- 對Dockerfile進(jìn)行檢查
- 對憑據(jù)泄露進(jìn)行檢查
因為 Docker 鏡像是 Docker 容器的模板，所涉及的攻擊面較大，并且有的安全風(fēng)險不易被掃描器所發(fā)現(xiàn)，所以現(xiàn)階段的 “Docker鏡像掃描”的做法仍不能保障 Docker 鏡像的安全性，建議人工介入檢查(可結(jié)合“docker inspect” 與 “docker history” 等命令查看鏡像的部分信息)。
2. “容器系統(tǒng)入侵檢測與防護(hù)” 管控方法
加強(qiáng) Docker 容器與內(nèi)核層面的隔離性有助于強(qiáng)化 “容器系統(tǒng)入侵檢測與防護(hù)”。比如 Docker 社區(qū)開發(fā)的安全特性、Linux 運(yùn)行時方案、異常行為檢測應(yīng)用以及 “容器+全虛擬化” 方案，如圖 3 所示。
圖3. “容器系統(tǒng)入侵檢測與防護(hù)” 管控方法
Docker 社區(qū)開發(fā)了針對 Linux 的 Cgroup 和 Namespce 的安全特性(Cgroup可用于限制CPU、內(nèi)存、塊設(shè)備I/O(具體可參考“docker run”命令的參數(shù));Namespace 可用于對 PID、mount、network、UTS、IPC、user 等內(nèi)核資源進(jìn)行隔離;Cgroup 對系統(tǒng)資源的隔離已經(jīng)比較完善了，而 Namespace 的隔離還不夠完善(甚至不可能完善，因為這是共享內(nèi)核導(dǎo)致的固有缺陷)。
部分可借鑒的Linux運(yùn)行時方案如下：
- Capability：令某程序擁有哪些能力;
- Selinux：定義了系統(tǒng)中每一個用戶、進(jìn)程、應(yīng)用、文件訪問及轉(zhuǎn)變的權(quán)限，然后使用一個安全策略來控制這些實體(即用戶、進(jìn)程、應(yīng)用和文件)之間的交互，安全策略指定了如何嚴(yán)格或者寬松地進(jìn)行檢查;
- Apparmor：設(shè)置執(zhí)行程序的訪問控制權(quán)限(可限制程序讀/寫某個目錄文件，打開/讀/寫網(wǎng)絡(luò)端口等);
- Secomp：應(yīng)用程序的沙盒機(jī)制，以白名單、黑名單方式限定進(jìn)程對系統(tǒng)進(jìn)行調(diào)用;
- Grsecurity：linux 內(nèi)核補(bǔ)丁，增強(qiáng)內(nèi)核安全性。
部分可借鑒的容器環(huán)境異常行為檢測開源應(yīng)用如下：
- Sysdig Falco：一款為云原生平臺設(shè)計的進(jìn)程異常行為檢測工具，支持接入系統(tǒng)調(diào)用事件和 Kubernetes 審計日志;
- cAdvisor：可以對節(jié)點機(jī)器上的資源及容器進(jìn)行實時監(jiān)控和性能數(shù)據(jù)采集，包括 CPU 使用情況、內(nèi)存使用情況、網(wǎng)絡(luò)吞吐量及文件系統(tǒng)使用情況。
“容器+全虛擬化” 方案也是 “容器系統(tǒng)入侵防護(hù)” 的有效方案，如果將容器運(yùn)行在全虛擬化環(huán)境中(例如在虛擬機(jī)中運(yùn)行容器)，這樣就算容器被攻破，也還有虛擬機(jī)的保護(hù)作用(目前一些安全需求很高的應(yīng)用場景采用的就是這種方式)。
3. “容器網(wǎng)絡(luò)入侵檢測與防護(hù)” 管控方法
Docker 容器網(wǎng)絡(luò)的安全問題可被劃分為 “網(wǎng)絡(luò)安全防護(hù)” 與 “微服務(wù)Web應(yīng)用安全” 兩類，“隔離” 和 “訪問控制” 等主要思路均有助于管控二者的安全問題。此外，仍可將部分現(xiàn)階段較為成熟的安全技術(shù)應(yīng)用到 Docker 場景中。在具體實施時，可依據(jù) Docker 應(yīng)用規(guī)模與實際的網(wǎng)絡(luò)部署情況進(jìn)行管控。
Docker 網(wǎng)絡(luò)本身具備 “隔離” 和 “訪問控制” 功能的網(wǎng)絡(luò)安全機(jī)制，但存在 “粒度較大” 與 “對安全威脅的感知能力不足” 等缺陷，如圖4所示。
圖4. Docker 網(wǎng)絡(luò)自身安全機(jī)制
為了彌補(bǔ) Docker 網(wǎng)絡(luò)的安全缺陷，一些商業(yè)化的端對端的 Docker 安全產(chǎn)品對網(wǎng)絡(luò)集群進(jìn)行了縱深防御，它們具備的功能特點包括了：
- 容器防火墻
- 運(yùn)行時保護(hù)
- 網(wǎng)絡(luò)深度數(shù)據(jù)包檢測
- 攻擊行為、異常行為告警
- 日志監(jiān)控
- 多編排平臺支持
- 網(wǎng)絡(luò)流量可視化
部分廠商在實現(xiàn)上述功能點時，在產(chǎn)品中引入了機(jī)器學(xué)習(xí)方法，用于生成行為模式與容器感知網(wǎng)絡(luò)規(guī)則。
Docker 網(wǎng)絡(luò)具有組網(wǎng)方案多樣化、容器生命周期長短不一、應(yīng)用場景多樣化等特點。因而，應(yīng)參照組網(wǎng)方案特點制定管控方法。筆者梳理的針對 “類傳統(tǒng)單體應(yīng)用”和 “微服務(wù)架構(gòu)應(yīng)用” 的入侵檢測與防御思路如圖5所示。
圖5. Docker 網(wǎng)絡(luò)入侵檢測與防護(hù)思路
首先來看 “類傳統(tǒng)單體應(yīng)用” 的 Docker 網(wǎng)絡(luò)集群的入侵檢測和防護(hù)思路。以圖 6 所示的微服務(wù)集群為例進(jìn)行介紹。該集群里只有 Nginx、Tomcat 以及 MySQL 的 3 個容器。
圖6. “類傳統(tǒng)單體應(yīng)用”的Docker網(wǎng)絡(luò)集群的入侵檢測和防護(hù)思路
注：圖中的綠色虛線表示文件掛載或者Docker的cp命令等方式，通過這兩種方式可以更便捷地在宿主機(jī)實時修改Nginx容器里的配置文件，調(diào)整Tomcat容器里的應(yīng)用程序文件，或者對MySQL容器里的數(shù)據(jù)進(jìn)行持久化。
為了對這套 Docker Web 應(yīng)用進(jìn)行入侵檢測與防御，可考慮以下 9 點方法：
(1) Iptables隔離
通過在宿主機(jī)側(cè)對Docker網(wǎng)絡(luò)集群外部做基于Iptables的隔離策略，可以限制攻擊者對“容器在宿主機(jī)所映射端口”的訪問，縮小受攻擊面。
(2) 部署軟WAF
通過在Docker網(wǎng)絡(luò)集群的流量入口處做軟WAF的部署(形態(tài)可以是宿主機(jī)軟件或者Docker容器)，可以在此處阻斷、發(fā)現(xiàn)部分惡意流量。
(3) 部署RASP
通過在Java、PHP服務(wù)器Docker容器內(nèi)部部署RASP產(chǎn)品，可以用之作為保護(hù)的最后一環(huán)，作為網(wǎng)絡(luò)治理的一個補(bǔ)充小點。
(4) Webshell掃描
通過在宿主機(jī)側(cè)通過Webshell掃描引擎掃描來自Docker容器的“Web應(yīng)用程序文件”(這些文件可通過“docker cp”命令或者“動態(tài)掛載”機(jī)制獲得)，有助于發(fā)現(xiàn)攻擊者植入的Webshell。
(5) 日志分析
通過在宿主機(jī)側(cè)通過ELK等日志分析分析來自Docker容器的日志文件(這些日志文件同樣可通過“docker cp”或“動態(tài)掛載”等方式獲得)。此外，單獨運(yùn)行Sidekick日志容器等做法有助于發(fā)現(xiàn)安全威脅。
(6) 識別中間人攻擊
通過在Docker網(wǎng)絡(luò)集群內(nèi)部通過網(wǎng)絡(luò)隔離是防止此類基于網(wǎng)絡(luò)的攻擊的有效方法，此方法可使得攻擊者無法操縱或竊聽主機(jī)及其他容器的網(wǎng)絡(luò)流量;在這種情況下，OpenVPN(開放虛擬專用網(wǎng)絡(luò))提供了一種通過TLS(傳輸層安全協(xié)議)加密實現(xiàn)虛擬專用網(wǎng)絡(luò)(VPN)的方法。
(7) 識別、阻斷流向異常的流量
通過在Docker網(wǎng)絡(luò)集群內(nèi)部依據(jù)實際的網(wǎng)絡(luò)拓?fù)鋱D對網(wǎng)絡(luò)進(jìn)行 “微分段” 隔離(在“微服務(wù)架構(gòu)”下，IP地址可能變換頻繁，但是預(yù)先劃分的網(wǎng)段不會變換頻繁)，或者對指定的網(wǎng)橋、網(wǎng)卡進(jìn)行流量的DPI分析，有助于識別、阻斷流向異常的流量。
(8)識別拒絕服務(wù)攻擊
通過在宿主機(jī)側(cè)讀取和Docker容器對應(yīng)的cgroup文件系統(tǒng)相關(guān)文件的實時內(nèi)容(網(wǎng)絡(luò)、CPU、內(nèi)存、磁盤)，可以識別出拒絕服務(wù)攻擊。
(9) 網(wǎng)絡(luò)流量可視化
“網(wǎng)絡(luò)流量可視化” 是現(xiàn)有的 “容器安全產(chǎn)品”的常見附加功能。該功能的功能可能依托于 “對指定的網(wǎng)橋、網(wǎng)卡進(jìn)行流量的DPI分析”。
接著來看 “微服務(wù)架構(gòu)應(yīng)用” 的 Docker 網(wǎng)絡(luò)集群的入侵檢測和防護(hù)思路。“微服務(wù)架構(gòu)應(yīng)用” 與 “類傳統(tǒng)單體應(yīng)用” 的顯著區(qū)別包括了 Docker 容器數(shù)量較多、網(wǎng)絡(luò)拓?fù)漭^復(fù)雜等方面。在這種生產(chǎn)場景下，K8S 等平臺可幫助用戶進(jìn)行大規(guī)模容器編排?？煽紤]使用的入侵檢測和防護(hù)思路如下：
(1) 運(yùn)用 K8S 原生或其第三方網(wǎng)絡(luò)插件的網(wǎng)絡(luò)策略
K8S原生的網(wǎng)絡(luò)策略 “NetworkPolicy” 可為 K8S 的最基本操作單位 “Pod” 提供 “IP地址/端口號” 級別的網(wǎng)絡(luò)隔離。
注：K8S支持以“第三方網(wǎng)絡(luò)插件”的形式選擇網(wǎng)絡(luò)方案，進(jìn)而會影響網(wǎng)絡(luò)策略的選擇。例如，
NetworkPolicy須由實現(xiàn)了CNI接口的網(wǎng)絡(luò)插件提供(如Calico、Cilium、Kube-route、Weave Net等等)。
(2) 關(guān)注微服務(wù)架構(gòu)Web應(yīng)用的接口“認(rèn)證鑒權(quán)”問題
開發(fā)方應(yīng)對微服務(wù)架構(gòu)Web應(yīng)用的認(rèn)證鑒權(quán)等問題予以重視，降低接口被網(wǎng)絡(luò)可互通的容器惡意訪問的風(fēng)險。常見的“認(rèn)證鑒權(quán)”方案可包括：網(wǎng)關(guān)鑒權(quán)模式、服務(wù)自主鑒權(quán)模式、API Token模式。
(3) 以“組件化”的形式在微服務(wù)集群中部署Web安全應(yīng)用
為了增加 Docker 網(wǎng)絡(luò)集群的安全能力，可在 Docker 集群中部署 Web 安全應(yīng)用(針對 “類單體Web應(yīng)用” 的做法仍可繼續(xù)使用。比如，我司的網(wǎng)站安全狗可用于保護(hù)部署在 Docker 容器里的 Web 應(yīng)用，如圖 7 所示)，此外也可考慮在容器集群中部署API網(wǎng)關(guān)容器(基于Nginx+Lua)、蜜罐容器或者資產(chǎn)發(fā)現(xiàn)與漏洞掃描器。
圖7. 網(wǎng)站安全狗可以用于保護(hù) Docker 容器
(4) 運(yùn)用 “Service Mesh” 技術(shù)
Service Mesh(服務(wù)網(wǎng)格)技術(shù)彌補(bǔ)了 K8S 在微服務(wù)通信的短板，有助于對應(yīng)用層做訪問限制。服務(wù)網(wǎng)格是一個基礎(chǔ)設(shè)施層，功能在于處理服務(wù)間通信，其主要職責(zé)在于負(fù)責(zé)實現(xiàn)請求的可靠傳輸。在實踐中，服務(wù)網(wǎng)格通常實現(xiàn)為輕量級網(wǎng)絡(luò)代理，通常與應(yīng)用程序部署在一起，但是對應(yīng)用程序透明。以開源應(yīng)用 Istio 為例，它通過為整個服務(wù)網(wǎng)格提供行為洞察和操作控制滿足微服務(wù)應(yīng)用程序的多樣化需求。它在服務(wù)網(wǎng)絡(luò)中統(tǒng)一提供了流量管理、策略執(zhí)行、服務(wù)身份和安全等關(guān)鍵功能。同時，Istio還可集成已有的 ACL、日志、監(jiān)控、配額、審計等功能。未來 Service Mesh 的融合架構(gòu)模型如圖8所示。
圖8. 未來 Service Mesh 融合架構(gòu)
4. “安全合規(guī)基線” 管控方法
為了應(yīng)對 Docker 容器生命周期里的全問題，需要可操作、可執(zhí)行的 Docker 安全基線檢查清單，這個清單要清晰、可查、可維護(hù)，以供在生產(chǎn)環(huán)境中執(zhí)行基礎(chǔ)架構(gòu)的安全檢查和審計。
以下安全合規(guī)檢查工具有較好的參考性：
(1) docker-bench-security(與Docker官方及CIS推出的安全標(biāo)準(zhǔn)相配套，如圖9所示)。
(2) Kube-bench(運(yùn)行 CIS Kubernetes 基準(zhǔn)測試，來檢查 Kubernetes 部署的安全程度)。
(3) OpenPolicyAgent(將安全策略和最佳實踐從特定的運(yùn)行時平臺解耦)。
圖9. Docker-Bench-Security 與官方白皮書配套
四、總結(jié)
經(jīng)過多年發(fā)展，Docker 容器技術(shù)逐漸被接受并應(yīng)用于 DevOps 和微服務(wù)等領(lǐng)域，在未來還有很大的潛力。本文探討了若干容器生命周期內(nèi)的安全問題，不難發(fā)現(xiàn)，要做好 Docker 容器安全管控工作，不應(yīng)忽視鏡像深度掃描、容器系統(tǒng)與容器網(wǎng)絡(luò)的入侵檢測與防護(hù)以及安全合規(guī)問題等環(huán)節(jié)。在面對上述環(huán)節(jié)時，可考慮借鑒、改造現(xiàn)有的網(wǎng)絡(luò)安全技術(shù)。
由于不同組織機(jī)構(gòu)有著不同的 Docker 應(yīng)用級別和技術(shù)選型，因而具體的實施方法會有不同。不同組織機(jī)構(gòu)應(yīng)結(jié)合自身情況，分階段、分層(容器引擎層、編排調(diào)度層)選擇適合的解決方案，以更好地保護(hù) Docker 容器環(huán)境。
【本文是51CTO專欄作者“李少鵬”的原創(chuàng)文章，轉(zhuǎn)載請通過安全牛（微信公眾號id:gooann-sectv）獲取授權(quán)】
