Docker 容器安全風險和防御綜述

摘要

Docker是目前最具代表性的容器平臺之一，它的安全問題引起了產業界和學術界的廣泛關注。首先，對Docker架構以及基本安全特性進行介紹，分析了Docker面臨的安全威脅。其次，對Docker增強、安全檢測、瘦身等方面的安全技術進行了分析梳理。最后，對Docker安全的未來發展進行總結和展望，幫助和激勵研究人員開始對Docker領域的研究。

內容目錄

1　背景知識

1.1　Docker 架構

1.2　Docker 安全機制

2　容器 Docker 安全風險2.1 鏡像安全風險

2.1　鏡像安全風險

2.2　容器虛擬化安全風險

2.3　容器網絡安全風險

3　Docker 安全增強技術

4　Docker 安全檢測

4.1　檢測容器安全工具

4.2　基于機器學習的容器安全檢測

4.3　基于溯源圖的容器安全檢測

4.4　基于鏡像標簽的容器安全檢測

5　Docker 鏡像瘦身

6　結　語

Docker是一種輕量級的虛擬化方式，將應用程序和運行環境打包成容器鏡像，使得應用程序能夠直接在容器中獨立地運行。由于Docker擁有輕量化、高效率和易部署的特點，目前已被廣泛應用于云計算和微服務架構中。

根據國家安全漏洞庫統計，Docker自2013年正式發布以來，截至2022年8月，累計發現124個相關漏洞，其中高危以上漏洞占71%，這對應用生態安全和用戶信心都帶來了不利影響。因此，Docker的安全性得到了產業界和學術界的廣泛關注，許多研究思路和方法被不斷提出。本文對Docker安全相關的研究思路、方法和工具進行比較和分析，并指出未來可能的研究方向。

1　背景知識

1.1　Docker架構

圖1為Docker架構圖。容器在宿主機上工作，并和其他容器共享宿主機內核。其中Docker客戶端和Docker守護進程通過REST API進行通信，發送拉取鏡像之類的命令行請求；Docker守護進程用來處理Docker客戶端發送的請求；Docker引擎是Docker架構中的運行引擎；Docker 容器是容器服務的交付實體。

圖 1　Docker 架構

1.2　Docker安全機制

Docker采用了多種Linux內核安全機制來約束容器內的進程，如表1所示。

Docker利用Linux的命名空間(Namespaces)為容器提供獨立的工作空間，與其他容器進行資源隔離；Docker利用Cgroups機制，限制每個容器可以訪問哪些資源，確保多容器環境下能正常使用系統資源；Capabilities定義了CAP_CHOWN、CAP_KILL等多種權限(不同版本略有不同，5.16-rc6版本中定義了40個權限)，將超級用戶權限進行細分，容器默認只有其中的14種權限；Docker基于Seccomp機制，限制容器內系統調用；SElinux和AppArmor屬于強制訪問控制，限制可執行程序的訪問控制權限，如讀寫功能；內容信任機制通過發布者簽名和使用者校驗的方式確認鏡像的完整性。

表 1　Docker 安全機制

2　容器 Docker 安全風險

狴犴安全團隊將Docker安全問題分為鏡像安全風險、容器虛擬化安全風險和容器網絡安全風險3個方面，本文在此基礎上對Docker安全問題進一步補充分析，為后續Docker安全增強提供研究方向。

2.1　鏡像安全風險

鏡像安全決定了生成容器的安全性，一直是學術界關注的熱點。表 2 是近幾年研究鏡像包含漏洞的情況。隨著時間的推移，鏡像中的漏洞數并沒有明顯減少，說明鏡像倉庫中的鏡像安全問題一直沒有得到很好的解決。

表 2　Docker 鏡像漏洞對比

(1)鏡像安全威脅模型如圖2所示，Docker Hub平臺用戶面臨兩種不同的威脅：一是攻擊者可以發布包含惡意執行命令的鏡像，一旦用戶下載運行鏡像，就可能遭受攻擊；二是開發者發布包含漏洞的鏡像，攻擊者有可能利用漏洞對使用鏡像的用戶進行攻擊。

(2)鏡像倉庫安全風險。主要包含兩個方面的風險：一是如果私有鏡像倉庫的配置不當，攻擊者可利用漏洞直接通過公網訪問私有倉庫并隨意篡改倉庫鏡像；二是用戶以明文形式下載鏡像，容易遭遇中間人攻擊，攻擊者能夠篡改鏡像內容或者冒名發布惡意鏡像。

(3)構建鏡像安全風險。兩種Docker鏡像的構建方式：一是使用Docker commit命令行方式構建，直接提交容器并生成鏡像；二是編寫Dockerfile指令，按照指令構建一個新鏡像。文獻[5]研究表明，Docker Hub平臺上的Dockerfiles文件存在兩個問題：一是構建過程違背Dockerfile最佳實踐，如未明確標記鏡像版本等；二是Dockerfiles文件包含惡意代碼腳本，導致存在主機文件泄露等安全問題。

圖 2　Docker 鏡像安全威脅模型

2.2　容器虛擬化安全風險

容器是一種輕量級的虛擬化方式，且不擁有獨立的資源配置，沒有做到系統內核層面的隔離。

(1)容器隔離安全風險。與虛擬機相比，Docker缺少虛擬化層，在文件隔離方面并不完善，如容器仍然可以訪問主機系統的/proc和/sys目錄，攻擊者可以獲取/proc/kallsyms中的內核符號來構建針對內核漏洞的攻擊。針對存儲資源，Cgroups未對主機存儲資源進行限制。若容器不斷向存儲空間寫入數據直至耗盡，將造成主機或容器的拒絕服務。

(2)容器逃逸攻擊。容器逃逸是指容器“逃出”自身權限，能夠對宿主機和其他容器進行非法訪問。容器逃逸的方式有很多種：一是利用容器的配置不當，如Docker高危啟動參數等；二是利用Docker軟件本身存在的安全漏洞，如容器逃逸著名案例Shocker攻擊通過調用open_by_handle_at函數來獲取宿主機的資源；三是利用內核漏洞進行容器逃逸，如通過內核漏洞非法進入內核上下文，獲取當前進程的有關數據，切換當前命名空間來獲取root shell，實現容器逃逸。

2.3　容器網絡安全風險

Docker網絡驅動包含橋接網絡、MacVLAN和Overlay這3種模式，如圖3所示。Docker默認的網絡驅動是橋接網絡。

圖 3　Docker 網絡驅動

橋接網絡的容器之間共用未過濾的Docker0網橋來進行通信；MacVLAN與主機的網絡接口連接，容器之間沒有訪問權限限制；Overlay主要利用虛擬擴展局域網(Virtual eXtensible Local Area Network，VXLAN)技術，在主機之間的網絡上構建出新的虛擬網絡，但未實現流量加密。3種組網模式都存在一定的安全風險，容器易遭受地址解析協議(Address Resolution Protocol，ARP)欺騙、嗅探、廣播風暴和拒絕服務等攻擊，造成敏感信息泄露和網絡服務功能受限等危害。

容器之間的網絡流量控制主要利用Iptables命令進行基于IP的訪問控制。但是容器的IP是動態的，創建或重新啟動容器會分配一個新IP，Iptables命令都需要調整。因此，從性能和安全性兩方面為容器指定安全策略是一個挑戰，因為每當重新創建容器時，必須更新這些策略，并且在策略更新期間也應鎖定Iptables的策略表。此外，Iptables的限制范圍有限，容器網絡仍然容易受到數據鏈路層攻擊，如ARP欺騙等。每個容器需要不同的網絡策略，策略的總數將隨著容器數量的增加而增加，容易產生網絡策略爆炸，容器生態系統的性能和安全性都將受到影響。

3　Docker安全增強技術

Docker安全增強技術主要包括利用Linux內核安全機制、可信計算的單容器安全增強，以及基于訪問控制策略容器間運行安全控制等。

(1)基于命名空間和內核模塊(Linux Kernel Module，LKM)來緩解容器隔離安全風險。Jian等人通過動態檢查主機命名空間的方式，實現了對異常進程的有效檢測，防止逃逸行為。陳莉君等人提出了基于LKM的Docker資源信息隔離方法，利用系統調用劫持技術來覆寫進程文件內容，建立有效的資源隔離機制。

(2)基于AppArmor機制增強容器安全，緩解了容器逃逸和特權提升等攻擊。在AppArmor的默認配置文件中并沒有限制網絡和capability規則，攻擊者可以通過受損容器危害宿主機。Loukidisandreou等人提出Docker-Sec方法，通過靜態分析容器執行參數和動態監測運行狀態來生成AppArmor配置文件，但該方法無法防御用戶空間攻擊。Mattetti等人提出了LiCShield框架，利用SystemTap方法跟蹤系統內核操作并生成包含5種規則的AppArmor配置文件，但LiCShield生成的文件作用范圍只在Docker守護進程。Zhu等人提出的Lic-Sec將Docker-Sec與LiCShield相結合，動態分析生成AppArmor配置文件。其能夠提供更高級別的保護，防止所有的特權提升攻擊，包括Docker-Sec無法防御的用戶空間攻擊。Lic-Sec的流程如圖4所示。

圖 4　Lic-Sec 流程

(3)基于Seccomp機制增強容器安全。在Linux的300多個可用系統調用中，Seccomp默認會在配置文件中阻止其中44個系統調用，但剩余的系統調用仍有可能被濫用從而對系統造成安全威脅。Lei等人提出了分階段執行應用程序容器SPEAKER，將容器分成啟動階段和運行階段，使用strace工具對系統調用進行跟蹤并生成Seccomp配置文件，但是動態分析無法覆蓋容器全部的系統調用。Wan等人提出了一種基于自動測試的沙箱容器挖掘方案(Mining Sandboxes)，使用測試套件對容器進行測試并跟蹤系統調用，分析日志生成Seccomp配置文件，同樣動態分析無法覆蓋容器全部的系統調用。Ghavamnia等人提出Confine工具，使用靜態和動態分析來檢測出容器內的應用程序及其所有依賴項，識別容器正確操作所需的系統調用，并生成Seccomp配置文件。基于AppArmor機制和Seccomp機制的6種方法的具體比較如表3所示。

(4)基于可信計算增強容器安全。2015年，Intel推出指令集擴展(Software Guard Extensions，SGX)，可用于保護不受信任主機上運行的容器和其他應用程序。Arnautov等人提出了基于SGX機制增強Linux容器安全(Secure Linux Containers with Intel SGX，SCONE)來保護容器免受外部攻擊，但是該方法對于硬件設備的限制過高，無法進行大范圍推廣。王鵑等人利用可信計算技術，提出了 Docker 安全增強系統DockerGuard，構造了一條從底層硬件到容器的信任鏈，增強運行過程的安全。但該方案犧牲了 Docker 容器原有的便捷、快速部署的特性，并且難以根據Docker版本的更新進行實時更新。

表 3　基于 Linux 內核安全機制的加固方法

(5)微服務環境中的容器間訪問控制。云服務應用程序通常由許多微服務組成，而73%的微服務部署在容器當中。為了防止正常的微服務被其他惡意的微服務隨意訪問，需要有細粒度的訪問控制策略來支撐。Li等人提出了自動增強訪問控制工具AUTOARMOR，具有以下特點：一是利用基于靜態分析的請求提取機制，從微服務源碼中自動獲取微服務間的調用邏輯；二是利用基于圖形的策略管理機制，通過權限圖來實現策略的更新。實驗表明，AUTOARMOR能夠以較小的開銷有效地生成微服務間的訪問控制策略，成功阻止了訪問未經授權的微服務、訪問未經授權的資源和執行未經授權的操作3種未經授權請求攻擊，緩解了容器網絡安全風險。但該方法仍存在以下問題：

服務應用程序通常由許多微服務組成，而73%的微服務部署在容器當中。為了防止正常的微服務被其他惡意的微服務隨意訪問，需要有細粒度的訪問控制策略來支撐。Li等人提出了自動增強訪問控制工具AUTOARMOR，具有以下特點：一是利用基于靜態分析的請求提取機制，從微服務源碼中自動獲取微服務間的調用邏輯；二是利用基于圖形的策略管理機制，通過權限圖來實現策略的更新。實驗表明，AUTOARMOR能夠以較小的開銷有效地生成微服務間的訪問控制策略，成功阻止了訪問未經授權的微服務、訪問未經授權的資源和執行未經授權的操作3種未經授權請求攻擊，緩解了容器網絡安全風險。但該方法仍存在以下問題：一是請求識別依賴于服務間通信庫的建立和語義模型，當通信庫的建模不完整時，會導致請求不被識別；二是即使通信庫建模是正確的，無用代碼也會帶來誤報。

4　Docker安全檢測

4.1　檢測容器安全工具

鏡像安全風險一直是學術界的研究熱點。目前的鏡像安全檢測工具主要分為開源工具和商用工具。本文對代表性的開源工具進行性能對比，如表4所示。

Javed等人使用Clair、Anchore和Microscanner這3種掃描工具對59個承載Java應用程序的容器進行掃描，發現現有的工具準確性普遍不高，準確率最高的Anchore漏掉了34%的漏洞，原因是只有Anchore能夠掃描非系統包，同時準確率依賴于現有的漏洞數據庫和漏洞檢測方式。Zheng等人介紹了一種基于繼承圖的安全檢測系統ZeroDVS，通過2 000個鏡像的rootfs配置信息，建立有鏡像繼承關系的圖形數據庫，并預先存儲父鏡像信息。在掃描鏡像漏洞時，與數據庫匹配批量識別父鏡像源的漏洞，此時只需掃描未匹配的子鏡像層的安全漏洞，提高了安全掃描效率。

表 4　檢測容器安全工具

4.2　基于機器學習的容器安全檢測

容器安全檢測工具大多是針對鏡像進行靜態掃描檢測。基于機器學習的檢測技術主要是對容器運行時的狀態(系統調用、文件輸入/輸出、網絡輸入/輸出、調度程序和內存等)進行特征提取，然后使用分類器進行訓練檢測。檢測技術分為無監督學習檢測方法和有監督學習檢測方法。

(1)無監督學習檢測方法。Tunde-onadele等人發現僅對容器進行靜態漏洞掃描是不夠的，于是提出了4種無監督機器學習方法，包括K近鄰法(K-Nearest Neighbor，KNN)、主成分分析(Principal Component Analysis，PCA)結合KNN、K均值(K-Means)、自組織映射算法(Self-Organizing Map，SOM)，把系統調用頻率作為特征向量，通過實驗比較，SOM的檢測準確率最好，達到78.57%，但都沒有達到較高的準確率。Srinivasan等人提出了一種實時入侵檢測系統模型，利用N-grams系統調用計算概率，然后使用最大似然估計器和簡單良好的圖靈平滑技術來處理跟蹤，檢測異常的準確率可達到87%~97%。

(2)有監督學習檢測方法。Abed等人將系統調用包(Bag of System Calls，BoSC)與滑動窗口技術結合，只跟蹤當前窗口中系統調用的頻率，把規定窗口內不同的系統調用的頻率映射成序號，并作為特征向量來進行判別訓練。該方法具有較高的檢測率，真陽性率達到100%，但該方法對訓練要求高。Tien等人提出KubAnomaly系統，使用4層全連接層構造神經網絡，利用系統調用作為特征向量來創建分類模型，實現了高達96%的檢測準確率，并成功識別了4次真實環境下的攻擊。但應用該系統需要在客戶機上安裝代理軟件，可能會面臨通過代理軟件進行攻擊的威脅。季一木等人利用基于系統調用序列和系統調用頻率的入侵檢測方法，結合滑動窗口與優化后的詞的逆文檔頻率(Term Frequency–Inverse Document Frequency，TF-IDF)算法提取系統調用特征，通過對比特征相似度進行分類。得出的實驗結果表明，該方法檢測準確率高達99.71%。但該方法只能預測容器內是否出現異常操作，未能對異常進行分類和規避。

4.3　基于溯源圖的容器安全檢測

溯源圖技術能夠細粒度地跟蹤系統的數據流，是全面安全監控和對歷史攻擊行為建模的有效手段。但容器的命名空間機制使數據流中引入了碎片和模糊性。碎片是指頂點分裂，導致溯源圖中的節點錯誤連接。模糊性是指頂點合并，其中一個頂點表示溯源圖中的多個不同對象。

Hassan等人提出Winnower工具能夠將進程從不同的容器中區分開來，但是缺少命名空間感知，導致容器內的溯源圖連接斷開。Pasquier等人[34]提出CamFlow工具能夠生成命名空間感知的溯源圖，但是不能有效地捕獲基本的容器語義(即容器邊界)，無法判斷溯源子圖屬于哪一個容器。

Chen等人提出利用CLARION工具來解決命名空間帶來的挑戰。針對PID命名空間帶來的影響，可以使用內核數據結構獲取主機與容器之間PID的映射；針對Mount命名空間帶來的影響，可以使用與chdir關聯的當前工作目錄查找容器根目錄的主機路徑，在文件路徑上建立主機容器映射；針對Network命名空間帶來的影響，設計了一個基于Netfilter的解決方案，用于跟蹤主機容器IP/端口映射；針對IPC命名空間帶來的影響，向每個IPC對象添加一個IPC命名空間ID，可以唯一區分來自不同容器的IPC對象。實驗表明，該工具能夠生成正確的容器溯源圖，在容器內的攻擊能夠被準確地檢測和溯源。

4.4　基于鏡像標簽的容器安全檢測

2018年殷康的研究表明在鏡像倉庫中，大部分鏡像標簽并沒有指定版本號，導致用戶可能下載同一個鏡像名的不同版本的惡意鏡像。基于此，作者設計出一種面向Docker鏡像的標簽自動推薦方法，該方法基于Dockerfile相似度和基于標簽的隱含狄利克雷分布(Labeled Latent Dirichlet Allocation，L-LDA)模型，實現了一種多模型融合的鏡像標簽推薦方法。針對10萬個Dockerfile文件，該方法能夠提升25.6%的鏡像構建成功率，同時能識別正確的鏡像版本號并完成下載，提高了用戶使用鏡像的安全性。

2022年Liu等人研究了關于容器注冊中心的注冊表拼寫的安全問題。作者通過精心構造鏡像的標簽，并將該鏡像上傳至鏡像倉庫，實驗表明，用戶確實存在因標簽拼寫錯誤而拉取作者上傳的鏡像。因此，作者提出了CRYSTAL工具，利用收集到的鏡像標簽數據打包成文件供CRYSTAL查詢，幫助容器注冊中心發現潛在的拼寫錯誤的鏡像標簽，在用戶下載鏡像時，提醒用戶是否存在拼寫錯誤并提供正確的標簽選項。作者實現了CRYSTAL的原型，達到了97.5%以上的檢測率，提高了用戶使用鏡像的安全性。由于CRYSTAL工具在Docker命令行上實現，所以對于其他拉取鏡像的方式，如使用Dockerfile文件拉取鏡像，CRYSTAL工具無法檢測使用，下一步將CRYSTAL工具擴展到注冊表，進一步緩解因拼寫錯誤而下載惡意鏡像的風險。

5　Docker鏡像瘦身

容器鏡像通常被構建在其他鏡像上，使得鏡像代碼量逐步增加，軟件規模不斷擴大且復雜性顯著增加，導致容器性能下降，安全漏洞增加。優化鏡像大小常用的方法是在構建Dockerfile時通過命令來縮減鏡像體積大小，如多階段構建等。Docker官方推出了一款開源的縮減工具Docker-Slim。Docker-Slim通過鏡像的歷史信息，來獲取生成鏡像的Dockerfile文件及相關的配置信息。通過內核工具解析出鏡像中必要的文件和文件依賴，將這些必要文件重新構建成新鏡像，其體積最大程度能夠縮減30倍。Rastogi等人提出Cimplifier工具，根據最小權限原則將一個容器劃分成若干個小容器，每個小容器只運行一個簡單應用程序。利用系統調用日志映射出所需的資源，在可執行文件級別上對其進行分區，容器大小可減少58%~95%。減少不必要的文件就相應地減少了攻擊者能夠利用的攻擊面，緩解了容器鏡像安全風險。

6　結語

本文對Docker架構以及基本安全特性進行介紹，分析了Docker面臨的安全威脅，對Docker增強、安全檢測、瘦身等方面的安全技術進行了分析梳理。但Docker安全問題還有許多待解決的問題值得深入研究：一是研究漏洞評估工具的可用性，研究和對比容器的漏洞掃描器性能、可用性、自動化性以及與當前部署和編排工具的集成問題，需解決0-day、1-day帶給Docker的重大安全威脅；二是開發有效、實用和在線的安全補丁解決方案，因為容器在打補丁后需要重啟，導致服務器(如Web服務器)產生業務斷開；三是關注物聯網等資源共享和受限場景下的容器安全問題。