Docker容器安全性分析與增強方案研究

【摘 要】 Docker的核心思想是利用擴展的Linux容器方案實現一種輕量級的虛擬化解決方案。本文介紹了Docker容器技術的架構和安全特性，在分析Docker容器安全風險的基礎上，論述了Docker容器的安全增強方案。

【關鍵詞】 Docker 容器 微服務 云計算

【中圖分類號】 TP315 【文獻標識碼】 A

1 引言

隨著互聯網的迅猛發展，云計算作為一種商業計算模式在搜索服務、移動商務、開放協作等多樣化需求的推動下迅速發展起來[1]。云計算以動態的、易擴展等優勢提供了虛擬化資源的計算和存儲方式，并受到谷歌、IBM、亞馬遜、微軟等IT廠商的大力推廣和應用。虛擬化技術作為云技術的核心，逐漸受到人們的廣泛關注。傳統計算機運行主要采用虛擬機技術，它占用了大量系統資源，導致主機運行緩慢。所以，急需一種輕量級的虛擬技術，以提高信息隔離程度，減少資源消耗[2]。

Docker是一款適應市場需求的輕量級操作系統級虛擬化產品，利用Linux內核的資源分離機制以及Linux內核的控制組（Cgroups）建立獨立運行的容器。容器間互相隔離，除了內核之外，每個容器可以有自己的庫文件、配置文件、工具等，并且提供了良好設計的容器間通信機制，Docker技術的出現推動了基于云計算平臺開發模式的變革和應用部署方式的變革[3]。

2 Docker技術介紹

2.1 概述

Docker設想是交付運行環境如同海運（如圖1所示），操作系統如同一個貨輪，每一個運行在操作系統基礎上的軟件都如同一個集裝箱，用戶可以通過標準化手段自由組裝運行環境，同時集裝箱的內容可以由用戶自定義，也可以由專業人員制造。這樣，交付一個軟件，就是一系列標準化組件的集合的交付，如同樂高積木，用戶只需要選擇合適的積木組合，并且在最頂端部署上自己的應用。

2.2 Docker系統架構

Docker容器采用客戶端與服務器的架構模式，如圖2所示。服務端處理復雜的操作任務，例如，創建（Create）、運行（Run）、保存（Commit）容器等，Docker客戶端作為服務端的遠程控制器，可以用來連接并控制Docker的服務端進程。Docker守護進程和Docker客戶端之間可以通過RESTful API或者套接字（Socket）進行進程間通信。

2.2.1 注冊中心

注冊中心是存儲容器鏡像的管理倉庫，容器在運行過程中，守護進程與注冊中心執行進程間通信。目前既有公有倉庫（如Docker Hub），也有私有倉庫（如Harbor）。與公有倉庫相比，私有倉庫可以保證容器鏡像在本地網絡獲得。

2.2.2 容器

容器是Docker服務交付的最終體現形式。通過Docker客戶端下發的命令，訂制相應的服務并運行容器，Docker容器可以計算資源的配額，確保容器只能使用指定范圍內的資源。

2.2.3 守護進程

Docker守護進程是Docker架構中一個常駐在后臺的系統進程，用于接收和處理客戶端發送的請求。該守護進程在后臺啟動一個服務端，負責接受客戶端發送的請求；接受請求后，服務端通過路由與分發調度，找到相應的處理器（handler）來執行請求。

引擎是Docker架構中的運行引擎，它扮演容器存儲倉庫的角色，并且通過執行任務的方式對容器進行操作和管理。

2.2.4 函數庫

函數庫通過Go語言設計實現，可以直接訪問內核中與容器相關的API，從而實現對容器命名空間、控制組、網絡設備以及防火墻規則等資源的操作。

2.3 Docker安全特性

2.3.1 安全隔離特性

隔離能力是Docker容器技術的核心安全能力之一，主要通過Linux命名空間實現，用于隔離進程樹、網絡接口、掛載點、進程間通信以及用戶等資源的方法。雖然多個容器運行在同一個平臺上，但是它們分別位于自己的命名空間中，無法訪問到命名空間外部的資源，這樣即使某個容器被攻擊或者存在某個惡意容器，入侵者也僅能訪問到當前容器的所有內容。目前，Docker常用的命名空間包括進程命名空間（PID）、網絡命名空間（NET）、文件系統命名空間（MNT）、主機與域名命名空間（UTS）以及用戶與用戶組命名空間（USER）等。

（1）進程命名空間

進程命名空間用來隔離進程空間，使得不同命名空間里的進程編號可以重復且互不影響，同時無法感知到運行在其他容器或者宿主機上的進程[4]。

（2）網絡命名空間

網絡命名空間用于實現網絡資源隔離，每個命名空間有獨立的網絡設備、IP地址、IP路由表等。

（3）文件系統命名空間

文件系統命名空間實現對根文件系統的環境進行隔離，不同的命名空間對應不同的根文件系統，組織不同的文件系統掛載樹，形成不同的文件系統目錄結構。

（4）主機與域名命名空間

主機與域名命名空間允許每個容器擁有獨立的主機名和域名，使其在網絡上可以被視作一個獨立的節點而非宿主機上的一個進程。

（5）用戶與用戶組命名空間

每個容器可以有不同的用戶和用戶組，也就是說可以在容器內部用內部的用戶而非宿主機上的用戶。

2.3.2資源管控特性

Docker通過Linux的控制組技術來實現容器的資源控制。控制組是由Linux內核提供的一種對各進程組所使用的物理資源（如處理器時間片、IO時間片、內存等）進行記錄、限制和隔離的技術，其主要有以下3個功能。

（1）資源限制：限制每個進程組可以分配的資源數量。比如，內存子系統可以為某一進程組設定一個內存分配上限。

（2）優先級設定：為進程組指定特定的優先級，當各容器進程搶占資源時，宿主機依據優先級算法和各進程組設定的優先級分配資源。

（3）進程組控制：如某一應用或者容器發生了死鎖，可以通過控制組技術中斷這一進程。

3 Docker安全風險

繼2017年容器安全被列入高德納（Gartner）年度十大安全項目，2019年Gartner年度安全與風險管理峰會上，再一次將容器安全項目列入榜單，預示著容器技術得到了廣泛的研究和應用，尤其是隨著微服務架構和DevOps開發模式的盛行，越來越多的開發人員使用容器技術。但是容器技術是一種新型的技術革命，不僅僅存在傳統的主機安全問題，同時也帶來了新型的安全威脅，例如，容器使用的是共享的操作系統模式，對主機操作系統的漏洞攻擊可能導致所有容器都受到破壞[5]。

3.1 逃逸安全風險

Docker容器的逃逸安全風險主要來源于危險配置、危險掛載、相關程序漏洞、內核漏洞等諸多方面[6]。

（1）危險配置威脅

用戶可以通過修改容器環境配置，或在運行容器時指定參數來縮小或擴大Docker容器所需的最小權限，如果用戶為存在安全風險的容器配置了危險參數，實際上是為攻擊者提供了一定程度的逃逸可能性。例如，特權（Privileged）參數使得容器能夠運行在特權模式，此時Docker容器將可以訪問宿主機上的所有設備，同時能夠修改宿主機強制訪問控制策略，使容器具備與直接運行在宿主機上的進程幾乎相同的訪問權限，嚴重破壞了Docker容器的隔離機制。

（2）隔離不完善威脅

Linux內核層面提供的隔離防護措施還不夠，仍有部分關鍵內容沒有完全隔離，如系統運行的關鍵目錄（如/proc、/sys等）、偽文件系統等，這些信息可以被惡意用戶利用，為攻擊創造有利條件。文獻[7]的作者利用/proc目錄中泄露的信息，創造最優條件，以最小代價對數據中心發起攻擊[7]。

（3）內核漏洞安全威脅

操作系統內核的攻擊是非常具有誘惑力的，大量研究者致力于發現可被用來執行任意代碼或能進行本地提權攻擊的內核漏洞，而此內核漏洞對基于與宿主機共享內核機制構建的Docker容器也同樣適用，一旦宿主內核存在可以橫向越權或者提權漏洞，那么盡管Docker使用普通用戶執行，攻擊者還是可以利用內核漏洞逃逸到宿主。例如，Linux內核3.16以前的版本存在一個內存溢出漏洞（CVE-2014-7822），由于splice系統調用在兩個文件間拷貝數據時未檢查拷貝大小，可溢出覆寫內核數據，本地未授權用戶可利用此漏洞越界寫內存，導致系統崩潰。

3.2 鏡像安全風險

鏡像是Docker容器的靜態表示形式，鏡像安全決定了容器的運行時安全。Docker官方鏡像倉庫Docker Hub中的鏡像可能由個人開發者上傳，其數量豐富、版本多樣，但質量參差不齊，甚至存在包含惡意漏洞的惡意鏡像，存在較大的安全風險。具體而言，Docker鏡像的安全風險分布在創建過程、獲取來源、獲取途徑等方方面面。2017年有團隊對鏡像安全漏洞進行調研[8]，并在《Docker Hub安全漏洞分析》一文中給出了一份鏡像的統計數據，如表1所示。

總的來說，鏡像安全主要表現在鏡像腳本文件（Dockerfile）安全、鏡像漏洞和倉庫安全等諸多方面。

（1）鏡像腳本安全威脅

鏡像腳本是創建鏡像的一種主要形式，主要考慮最小安裝原則，同時考慮容器的易維護性，一般由基礎鏡像信息（FROM）、維護者信息（MAINTAINER）、鏡像操作指令（RUN，ADD，COPY等）、容器啟動時執行指令（CMD等）4個部分組成。

如果鏡像腳本存在漏洞或被插入惡意腳本，那么生成的容器也可能產生漏洞或被惡意利用。例如，如果在腳本文件中沒有指定用戶，Docker將默認以root的身份運行該容器，若該容器遭到攻擊，那么宿主機的root訪問權限也可能會被獲取；如果在腳本文件中存儲了固定密碼等敏感信息并對外進行發布，則可能導致數據泄露。

（2）鏡像漏洞安全威脅

鏡像漏洞安全風險具體包括鏡像中的軟件含有CVE漏洞、攻擊者上傳含有惡意漏洞的鏡像等情況。

①CVE漏洞

鏡像通常是通過官方鏡像倉庫Docker Hub或網易、阿里云等提供的第三方鏡像倉庫獲取。然而，根據對Docker Hub中鏡像安全漏洞的相關研究，無論是社區鏡像還是官方鏡像，其平均漏洞數均接近200個，包括nginx、mysql、redis在內的常用鏡像都含有高危漏洞。

CVE-2019-5021報告指出，自Alpine Linux3.3版本開始的所有Docker鏡像中，root用戶包含一個空密碼，如果在Docker容器中安裝了shadow軟件包并以非root用戶身份運行服務，那么具有shell訪問權限的用戶可在容器內對賬號進行提權[9]。

②惡意漏洞

惡意用戶可能將含有后門、病毒等惡意漏洞的鏡像上傳至官方鏡像庫。2018年5月，Fortinet公司披露Docker賬戶（Docker123321）創建的17個包含用于數字貨幣挖礦惡意程序的Docker鏡像。2018年6月，Kromtech公司發布了一份完整的報告，對該事件進行了復盤。該事件涉及的惡意鏡像如表2所示。

3.3 網絡安全風險

Docker容器網絡默認使用橋接方式進行連接，通過在宿主機上創建一個虛擬的網橋Docker0扮演傳統交換機的角色，并在各個網絡接口間自動地進行分組轉發。每創建一個新的容器，就為其增加一個虛擬網絡接口，并將該網絡接口連接到網橋Docker0。同一主機上的容器之間采用網橋模式，對轉發的數據分組未進行任何過濾，容易遭受ARP欺騙和MAC泛洪攻擊。當容器中的應用程序對內核資源惡意使用時，將會影響該主機上其他容器。例如，頻繁惡意訪問Linux系統的隨機生成函數，將可能造成主機的其他業務無法正常運行。

容器的創建和刪除頻率較高，IP地址會隨著容器的狀態隨機分配和綁定，新創建的容器使用的IP大多數情況下已被其他容器綁定過，因此，對IP原所屬容器的攻擊可能會重定向到新容器中。

4 Docker安全增強方案

4.1 增強容器之間的精準安全隔離

隨著基于容器的微服務化技術的大規模落地使用，容器之間的東西向流量急劇增大，目前常見的解決方案是在硬件級進行隔離，這樣所有的流量都不得不經過硬件交換設備和安全防護設備，增加容器環境的網絡復雜度，并且會形成“發夾效應”，降低了數據傳輸效率，增加了網絡流量和硬件設備的傳輸壓力。

CNCF的容器平臺的安全最佳實踐文檔中要求從容器級別實現隔離或者打通等安全管控，在不同業務的容器之間，按照既定規則—標簽、地址、端口等限制，來實現網絡分段，實現策略化的安全隔離。

4.2 增強對IP地址假冒的安全防護

容器平臺的容器數量越來越多，對外暴露的風險點也會成倍增加，一旦有一個容器被攻破，攻擊行為會嘗試假冒IP地址、嗅探內部漏洞等動作，當攻擊行為成功繞過南北防火墻之后，對內部造成的破壞將會非常巨大而且危險。不僅是攻破一個容器，還可能通過攻破容器再獲取整個主機的管理權限，在整個網絡內部做更深度的攻擊和破壞。

針對該安全威脅，業界經常采用的方案是通過NSX-T的spoofguard功能，維護容器名和IP地址的引用表來防止IP地址欺騙，在容器啟動過程中，用檢索到的信息填充它與每個容器的IP地址，可以有效阻止未知容器發送或接受流量，提高容器環境的整體安全性。

4.3 增強對挖礦病毒的安全防護

容器挖礦病毒到處肆虐，能利用多個軟件不同版本的各種漏洞，滲透到內部環境，來注入挖礦木馬，并且在內部網到處嗅探、傳染。此前的解決方法往往是發生了一次后，升級解決某個軟件版本的漏洞，刪除被感染環境的木馬程序，但是各個軟件升級調整又有新的漏洞以及源源不斷的新木馬變種。

針對該類安全問題建議從以下4個方面進行安全加固。

（1）在進行安全策略配置時，屏蔽掉常見的挖礦網站的IP地址。

（2）減少挖礦軟件經常使用的服務軟件，例如minerd挖礦程序利用Redis等中間件的漏洞發起攻擊，獲取root權限，植入挖礦木馬。針對該類情況可以限定Redis所在容器的可訪問地址范圍，同時修改Redis的默認服務器端口。

（3）修改或者關閉容器集群的默認服務器端口，例如2375和2376等。

（4）建立健全漏洞發現和修復機制，定期對問題鏡像進行漏洞修復。

5 結語

以Docker為代表的容器化技術逐漸成熟，已經在云計算、微服務、開發運維一體化等各個領域得到了廣泛研究和應用。但是由于容器存在天然的安全問題和缺陷，相關的安全問題也不斷出現。目前對容器安全的研究也是百家爭鳴，主要有容器自身安全性研究、容器攻擊威脅研究、容器安全加固方案研究、容器監控技術方案研究等各個方面。相信隨著容器技術本身和配套安全解決方案研究的不斷深入，容器技術將迎來下一個春天。

參考文獻

[1] 浙江大學SEL實驗室.Docker容器與容器云(第二版)[M].北京:北京郵電大學出版社,2016:28.

[2] 李明全.基于Docker的虛擬化技術分析與探究[J].信息與電腦(理論版),2020,32(01):21~22+25.

[3] 趙冠臣,王冬妮,劉至洋,孟振江.淺談Docker容器技術[J].有線電視技術,2019(09):85~88.

[4] 李俊灝.Docker安全性分析及安全防護[J].科技視界,2019(20):240~241+201.

[5] Gartner's top 10 security projects for 2019[EB/OL].[2020-10-18].https://www.ciodive.com/news/gartners-top-10-security-projects-for-2019/549899/,2019.

[6] 江燕青.容器逃逸技術的探討[J].福建電腦,2020,36(08):59~61.

[7] Gao X, Gu Z, Kayaalp M, et al. ContainerLeaks:Emerging Security Threats of Information Leakages in Container Clouds[C]. Ieee/ifip International Conference on Dependable Systems and Networks. IEEE, 2017:237~248.

[8] Shu R, Gu X, Enck W. A Study of Security Vulnerabilities on Docker Hub[C].ACM on Conference on Data and Application Security and Privacy. ACM, 2017:269~280.

[9]CVE-2019-5021[EB/OL].[2020-10-18].https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5021,2019.