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