一個課程作業的報告
DOCKER架構及組件
提到Docker的安全，那麼首先就要從Docker的整個架構來入手。Docker是基於Client/Server模式來設計的，主要部分分爲Docker Client、Docker Daemon、Docker Registry組成的。Docker Client爲用戶提供了很多操作的接口，主要功能是向Docker Daemon發送請求來獲取服務。Docker Daemon 運行於宿主機上位客戶端請求服務，類似一個服務器。Docker Registry是一個集中存儲和分發鏡像的地方，負責處理從Daemon發過來的請求。它們三者及其所依賴的組件如圖所示。 
DOCKER 安全威脅
Docker的安全威脅實際上和Docker的架構密切相關。構成整個Docker的各個組件都可以成爲攻擊的點。目前關於Docker的安全問題主要是圍繞網絡、容器、容器依賴的Linux內核、鏡像。Docker的攻擊面如下圖所示。
鏡像安全威脅
Docker運行的鏡像是從倉庫上面下載過來的。運行不安全的鏡像會對整個系統造成很大的威脅。鏡像安全問題主要包括兩個部分：鏡像自身安全威脅和鏡像倉庫安全威脅。
鏡像自身安全威脅又可分爲鏡像缺陷和鏡像中毒。簡單說就是鏡像存在漏洞這樣的缺陷和鏡像存在病毒等惡意軟件。鏡像缺陷指的是鏡像在製作過程中都是基於一些基礎鏡像構建的，可能安裝了很多不必要的庫和依賴，而這些庫中存在很多漏洞，從而導致了鏡像存在可以被攻擊者利用的缺陷。
鏡像中毒指的是鏡像被植入了後門或者病毒這類的惡意軟件。有些惡意用戶會在鏡像中植入病毒或者後門上傳到官方社區中。2018年6月，安全廠商Fortinet和Kromtech在Docker Hub上發現17個包含用於數字貨幣挖礦惡意程序的Docker鏡像，而這些惡意鏡像當時已有500萬次的下載量。這種挖礦的鏡像嚴重了損害了用戶的利益。
鏡像倉庫安全威脅指的是倉庫中的鏡像被外部的攻擊者惡意篡改。比如，私有鏡像倉庫由於配置不當而開啓了2357端口，將會導致私有倉庫暴露在公網中，攻擊者可以直接訪問私有倉庫篡改鏡像內容，破壞鏡像的完整性，造成鏡像安全隱患。
網絡安全威脅
網絡安全威脅主要是針對Docker各個組件的通信進行攻擊。這也是所有互聯網信息系統所面臨的重要風險。Docker提供橋接網絡、MacVLAN、Overlay等多種組網方式。默認使用的是網橋模式，在宿主機上創建一個虛擬網橋docker0，在各個網絡接口間自動地進行包轉發，每創建一個新的容器，就增加一個虛擬網絡接口，並將該網絡接口連接到網橋Docker0。然而默認情況下，虛擬網橋沒有對轉發的數據包進行過濾，容器間也沒有網絡安全管理機制，無法對同一宿主機內各容器之間的網絡訪問權限進行限制。所以攻擊者可以利用某個容器對宿主機內的其他容器進行ARP欺騙、嗅探和廣播風暴，導致信息泄露和影響網絡運行等安全隱患。
另外一種攻擊模式是拒絕服務攻擊，簡稱DoS攻擊。這裏又可分爲容器間的DoS攻擊和容器外的DoS攻擊。容器間的DoS攻擊指的是攻擊者本身可以操縱某容器，利用該容器向其他容器發起DoS攻擊，降低其他容器的網絡數據處理能力。容器外的DoS攻擊是基於同一臺宿主機所有容器共享宿主機的物理網卡資源的前提來發動的。攻擊者通過使用大量受控主機組成的殭屍網絡向某個宿主機發送大量數據包進行DoS攻擊，有可能佔滿宿主機的網絡帶寬資源，造成宿主機和其他容器的拒絕服務。
容器安全威脅
容器存在的安全問題可以分爲Docker代碼漏洞、配置不當、拒絕服務攻擊這些問題。
Docker本身也是一種應用軟件。這樣就意味着Docker本身在代碼實現上會存在缺陷。在CVE官網上搜索關於Docker歷史版本的漏洞有81個，而這些漏洞很有可能會被攻擊者利用。
此外，容器存在一類配置不當引起的安全問題。例如，當容器啓動時，給定權能-net=host時，Docker不會將容器放入單獨的網絡命名空間中，因此，它使容器能夠完全訪問主機的網絡堆棧；配置容器重啓策略時，如果不限制重啓次數，可能會被惡意反覆重啓，導致耗盡計算資源，形成DoS攻擊。除了計算資源會被惡意利用，攻擊者針對存儲資源，利用CGroups沒有對AUFS文件系統限制單個容器的存儲資源的特性，向宿主機的某個容器的AUFS文件系統不斷地進行寫文件操作，可能會導致宿主機存儲設備空間不足，導致無法滿足其他容器的存儲需求。不同於上一小節的DoS攻擊，這裏的DoS攻擊不是通過網絡來實施的，但目的是一樣的，都是佔用主機資源，導致其他容器無法正常工作。
內核安全威脅
從Docker容器是基於和宿主機共享內核機制構建的，而目前Linux內核層面提供的支撐機制還不夠完善。因此，攻擊者可以基於容器和操作系統共享內核這一特性，利用內核存在的漏洞，進行提權，從而可以對宿主機和宿主機其他容器進行訪問。在Black Hat USA 2019會議上，就提到了若干基於這種方式實施的攻擊，例如CVE-2016-5195 髒牛漏洞。這個漏洞利用linux內核函數get_user_page在處理Copy-on-Write的時候產生競態條件，導致可以向只讀內存區域寫數據的機會，攻擊者可以利用這點進一步修改su或者passwd文件獲得root權限。
此外，由於處理器出現Meltdown、Spectre等漏洞，導致側信道攻擊這幾年大行其道。這些漏洞都是基於共享這一特性進行攻擊。而容器存在很多共享的情況。基於硬件的側信道攻擊如Meltdown、Spectre，不僅可以泄露底層內核的信息，還可以泄露運行在同一主機上的其他信息。
DOCKER安全防禦
上一章節分析了Docker存在的安全問題，這一節將介紹業界基於這些安全問題的解決方案。
鏡像安全防禦
保護鏡像自身安全的策略有鏡像安全掃描和鏡像完整性度量。鏡像安全掃描主要是在從公共鏡像倉庫獲取鏡像時對其進行安全檢查，防止存在安全隱患的鏡像運行。這類工具有Docker Security Scanning、Clair、Anchore、Trivy、Auqua等等。
鏡像完整性度量主要是保護鏡像的完整性，即保護鏡像不被惡意篡改。這類技術基於可信計算中的TPM來實現的。
針對鏡像倉庫的防禦，主要是保護鏡像從鏡像倉庫push或者pull的過程的安全。這裏的防禦是利用Docker的內容信任（Content Trust）機制實現的。內容信任機制的主要功能是對從Docker 倉庫傳送過來的鏡像進行完整性和發佈者真實性校驗，並對鏡像進行數字簽名。內容信任機制開啓後，只有已簽名的基礎鏡像才能通過docker build進行鏡像構建。
容器安全防禦
與傳統的虛擬化不同，容器架構中沒有Hypervisor層，需要依賴操作系統內核來對容器進行管理。因此，容器間共享內核導致了容器間產生了諸多的安全問題。針對容器的防禦機制也是最多的，主要集中於隔離技術、容器運行時監控、容器安全審計這幾方面，下面將依次展開。
容器的隔離技術是通過linux內核的Namespace機制實現容器與宿主機之間、容器與容器之間資源的相對獨立。通過爲容器創建自己的命名空間，保證容器中進程的運行不會影響到其他容器或宿主機的進程。此外，Docker使用Cgroup來對宿主機的不同容器進行資源限制，包括CPU、內存、I/O等物理資源進行均衡化配置，防止單個容器耗盡宿主機所有資源，以防拒絕服務攻擊。然而，Cgroup不是很完善，沒有對磁盤存儲資源進行限制。對此，Docker也採用-storage-opt來限制磁盤存儲，但是這種方式僅支持Device Mapper系統，難以針對Docker容器實現基於進程或目錄的磁盤限額。針對這個問題，Docker可以採取虛擬文件系統、選擇XFS等針對目錄進行磁盤使用量限制的文件系統等方法。
容器運行時監控是指在容器運行時，監控系統的各項指標，遇到安全威脅及時預警並響應。這類工具有docker stats、cAdvisor、DataDog、Sensu等等。最常見的是原生的Docker stats命令和谷歌的cAdvisor。
容器安全審計指的是對容器的各類行爲進行記錄，對日誌進行審查追蹤安全行爲的過程。對於Docker容器而言，不僅要對主機Linux文件系統進行審計，也要對Docker守護進程進行審計。但是系統不會默認對Docker守護進程進行審計，因此，Docker提供了auditctl命令來添加審計規則。
網絡安全防禦
網絡安全防禦這部分工作主要是爲了防止基於網絡的攻擊，比如中間人攻擊和ARP欺騙。Docker爲了應對這類攻擊設立了網絡訪問控制規則。其將容器放在不同的橋接網絡中。當Dokcer使用Docker network create命令創建新的橋接網絡時，會在iptables中的DOCKER-ISOLATION新增DROP丟棄規則，阻斷與其他網絡之間的通信流量，實現容器網絡之間隔離的目的。同時也可修改白名單規則來按需設置網絡訪問控制，即根據實際需要在iptables中添加訪問控制策略，以最小化策略減小攻擊面。
然而在大規模容器雲環境中，存在頻繁的動態變化，手動配置規則顯然是不現實的。因此，可以通過微分段機制來實現面向容器雲環境的容器防火牆。微分段(Micro-Segmentation)是一種細粒度的網絡隔離機制，與傳統的以網絡地址微基本單位的網絡分段機制不同，微分段可以以單個容器、同網段容器、容器應用爲粒度實現分段隔 離，並通過容器防火牆實現微分段間的網絡訪問控制。
此外，容器間的流量限制可以防止潛在的網絡DoS攻擊。流量限制有兩種，一種是完全禁止容器間通信，一般應用於特定場景。一種是限制流量，其通過linux的流量控制模塊traffic controller對容器網絡流量進行限制。這個模塊的原理是簡歷數據包隊列並制定發送規則，實現流量限制與調度功能。
內核安全防禦
由於容器技術很依賴linux內核，所以一旦linux內核出了什麼毛病，容器也會跟着出問題。而針對內核保護的研究實際上已經比較成熟，但內核爆出的漏洞也逐年增長，這是一個攻防博弈的過程。內核防禦機制有權能機制（Capabilities）、強制訪問控制、Seccomp機制、Grsecurity/PAX等。
權能機制是按照最小化權限原則來限制容器的能力。權限被細分爲37個小權能，只有具有某種權能才能執行某種特定任務。這種機制可以防止容器的權限濫用。
強制訪問控制相對於自主訪問控制可以提供更嚴格的保護，用戶不能改變他們的安全級別和對象的安全屬性，只能依據預先設定的安全等級來做決策。這種機制已經在內核安全模塊中實現了，比如SELinux、AppArmor等。
Seccomp機制是Linux內核提供的安全特性，可以實現沙盒機制，以白名單/黑名單的方式限制進程能夠進行的系統調用範圍。
Grsecurity/PAX是一個linux內核的加固補丁，讓linux內核的內存頁受限於最小權限原則。
總結與思考
本文對Docker容器技術產生的安全問題以及業內解決方案做了調研，總結的思維導圖如下圖所示。可以發現，攻擊者的攻擊面幾乎在整個系統運行的每個步驟都存在，攻擊者只要攻破某個點就能實現目的。防禦者只要阻止一個完整的攻擊的某個步驟就能防禦住。攻擊有攻擊的優勢，防禦也有防禦的優勢，所以這也是一個攻防博弈的過程。此外，我們也可以發現，許多安全問題是因爲存在共享導致的。共享雖然提供了便利，但同時也引入了安全問題。容器技術相對於傳統虛擬化，更依賴於Linux底層，這也導致了Linux內核出現的問題也會帶給容器。這也就是說，底層技術的安全性得到保障，才能保障上冊的安全。或者可以降低容器和linux內核的依賴關係，二者相互獨立，也能避免很多安全問題。實際上，正因爲容器技術依賴Linux內核，丟掉了Hypervisor層，才能讓容器成爲一個輕量級的技術。由此可見，容器的優點可能也導致了它的缺點。做安全，實際上也是一個不斷trade-off的過程，什麼樣的情景需要安全，什麼樣的情景需要性能或者操作便捷。一個系統不能十全十美，但可以是最適合某個場景。
參考文獻
[1] 魯濤, 陳杰, 史軍. Docker安全性研究%Research of Docker Security[J]. 計算機技術與發展, 2018, 028(006):115-120.
[2] Yasrab, Robail. “Mitigating docker security issues.” arXiv preprint arXiv:1804.05039 (2018).
[3] Bui, Thanh. “Analysis of docker security.” arXiv preprint arXiv:1501.02967 (2015).
[4] 餘金鍵, 賈川, and 蒲東. “Docker 安全性研究綜述 A Review of Docker Security Research.” Computer Science and Application 9.05 (2019): 926.
[5] 狴犴安全團隊.Docker容器安全性分析[EB/OL].https://www.freebuf.com/articles/system/221319.html,2019-12-15.
[6] 王婷婷，徐國坤.Docker安全風險，原來有這麼多[EB/OL].https://cloud.tencent.com/developer/news/243123,2018-06-14.
[7] The MITRE Corporation. Common Vulnerabilities and Exposures[EB/OL].https://cve.mitre.org/,2020-3-20.