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