Docker容器安全性分析
【編者的話】Docker是目前最具代表性的容器技術之一，對雲端計算及虛擬化技術產生了顛覆性的影響。本文對Docker容器在應用中可能面臨的安全問題和風險進行了研究，並將Docker容器應用環境中的安全機制與相關解決方案分為容器虛擬化安全、容器安全管理、容器網路安全三部分進行分析。
從虛擬化安全到容器安全
傳統虛擬化技術
虛擬化技術是實現硬體基礎設施資源的充分利用、合理分配和有效排程的重要技術手段。例如，在基於OpenStack的典型IaaS服務中，雲服務提供商可通過搭建裝置叢集建立資源池，並將伺服器、儲存和網路等底層資源進行彈性虛擬化提供給租戶。

傳統虛擬化技術以虛擬機器為管理單元，各虛擬機器擁有獨立的作業系統核心，不共用宿主機的軟體系統資源，因此具有良好的隔離性，適用於雲端計算環境中的多租戶場景。
容器技術
容器技術可以看作一種輕量級的虛擬化方式，將應用與必要的執行環境打包成容器映象，使得應用程式可以直接在宿主機（物理機或虛擬機器）中相對獨立地執行。容器技術在作業系統層進行虛擬化，可在宿主機核心上執行多個虛擬化環境。相比於傳統的應用測試與部署，容器的部署無需預先考慮應用的執行環境相容性問題；相比於傳統虛擬機器，容器無需獨立的作業系統核心就可在宿主機中執行，實現了更高的執行效率與資源利用率。

Docker是目前最具代表性的容器平臺之一，它模糊了傳統的IaaS和PaaS的邊界，具有持續部署與測試、跨雲平臺支援等優點。在基於Kubernetes等容器編排工具實現的容器雲環境中，通過對跨主機叢集資源的排程，容器雲可提供資源共享與隔離、容器編排與部署、應用支撐等功能。

Docker容器技術以宿主機中的容器為管理單元，但各容器共用宿主機核心資源，分別通過Linux系統的Namespaces和CGroups機制實現資源的隔離與限制。

Namespaces

為了保證容器程序之間的資源隔離，避免相互影響和干擾，Linux核心的Namespaces（名稱空間）機制提供了UTS、User、Mount、Network、PID、IPC等名稱空間實現了主機名、使用者許可權、檔案系統、網路、程序號、程序間通訊等六項資源隔離功能。通過呼叫clone()函式並傳入相應的系統呼叫引數建立容器程序，可實現對應資源內容的隔離，具體情況如表1所示。

表1：Namespaces隔離機制
1.png

對於某個程序而言，可通過檢視/proc/[PID]/ns檔案，獲取該程序下的名稱空間隔離情況，如圖1所示。其中，每一項名稱空間都擁有一個編號對其進行唯一標識，如果宿主機中兩個程序指向的名稱空間編號相同，則表示他們同在一個名稱空間之下。
2.png

圖1：程序名稱空間

CGroups

CGroups（Control Groups，控制組）機制最早於2006年由Google提出，目前是Linux核心的一種機制，可以實現對任務組（程序組或執行緒組）使用的物理資源（CPU、記憶體、I/O等）進行限制和記錄，通過多種度量標準為各個容器相對公平地分配資源，以防止資源濫用的情況。

在實際應用中，CGroups會為每個執行任務建立一個鉤子，在任務執行的過程中涉及到資源分配使用時，就會觸發鉤子上的函式並對相應的資源進行檢測，從而對資源進行限制和優先順序分配。

CGroups提供了資源限制（Resource Limitation）、優先順序分配（Prioritization）、資源統計（Accounting）、任務控制（Control）四個功能，包含blkio、cpu、cpuacct、cpuset、devices、freezer、memory、perf_event、net_cls、net_prio、ns、hugetlb等子系統，每種子系統獨立地控制一種資源，可分別實現塊裝置輸入/輸出限制、CPU使用控制、生成CPU資源使用情況報告、記憶體使用量限制等功能。幾個主要子系統的具體功能如表2所示。

表2：CGroups子系統
3.png

安全性
傳統虛擬化技術與Docker容器技術在執行時的安全性差異主要體現在隔離性方面，包括程序隔離、檔案系統隔離、裝置隔離、程序間通訊隔離、網路隔離、資源限制等。

在Docker容器環境中，由於各容器共享作業系統核心，而容器僅為執行在宿主機上的若干程序，其安全性特別是隔離性與傳統虛擬機器相比在理論上與實際上都存在一定的差距。
Docker容器安全風險分析
根據Docker容器的主要特點及其在安全應用中的實際問題，本文將Docker容器技術應用中可能存在的技術性安全風險分為映象安全風險、容器虛擬化安全風險、網路安全風險等型別進行具體分析，如圖2所示。
4.png

圖2：容器安全風險分類
映象安全風險
Docker映象是Docker容器的靜態表示形式，映象的安全決定了容器的執行時安全。

Docker容器官方映象倉庫Docker Hub中的映象可能由個人開發者上傳，其數量豐富、版本多樣，但質量參差不齊，甚至存在包含惡意漏洞的惡意映象，因而可能存在較大的安全風險。具體而言，Docker映象的安全風險分佈在建立過程、獲取來源、獲取途徑等方方面面。

Dockerfile安全問題

Docker映象的生成主要包括兩種方式，一種是對執行中的動態容器通過docker commit命令進行打包，另一種是通過docker build命令執行Dockerfile檔案進行建立。為了確保最小安裝原則，同時考慮容器的易維護性，一般推薦採用Dockerfile檔案構建容器映象，即在基礎映象上進行逐層應用新增操作。

Dockerfile是包含用於組合映象命令的文字檔案，一般由基礎映象資訊（FROM）、維護者資訊（MAINTAINER）、映象操作指令（RUN、ADD、COPY等）、容器啟動時執行指令（CMD等）四個部分組成，Docker可通過讀取Dockerfile中的命令建立容器映象。

Dockerfile檔案內容在一定程度上決定了Docker映象的安全性，其安全風險具體包括但不限於以下情況：

如果Dockerfile存在漏洞或被插入惡意指令碼，那麼生成的容器也可能產生漏洞或被惡意利用。例如，攻擊者可構造特殊的Dockerfile壓縮檔案，在編譯時觸發漏洞獲取執行任意程式碼的許可權。
如果在Dockerfile中沒有指定USER，Docker將預設以root使用者的身份執行該Dockerfile建立的容器，如果該容器遭到攻擊，那麼宿主機的root訪問許可權也可能會被獲取。
如果在Dockerfile檔案中儲存了固定密碼等敏感資訊並對外進行釋出，則可能導致資料洩露的風險。
如果在Dockerfile的編寫中添加了不必要的應用，如SSH、Telnet等，則會產生攻擊面擴大的風險。

映象漏洞

對於大多數一般的開發者而言，通常需要獲取一系列基礎映象進行容器雲的部署和進一步開發，因此，基礎映象的安全性在一定程度上決定了容器雲環境的安全性。

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

1、CVE漏洞

由於映象通常由基礎作業系統與各類應用軟體構成，因此，含有CVE漏洞的應用軟體同樣也會向Docker映象中引入CVE漏洞。

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

2、惡意漏洞

惡意使用者可能將含有後門、病毒等惡意漏洞的映象上傳至官方映象庫。2018年6月，安全廠商Fortinet和Kromtech在Docker Hub上發現17個包含用於數字貨幣挖礦惡意程式的Docker映象，而這些惡意映象當時已有500萬次的下載量。目前，由於Docker應用在世界範圍內具有廣泛性，全網針對Docker容器的攻擊很多都被用於進行數字貨幣挖礦，為攻擊者帶來實際經濟利益，損害Docker使用者的正常使用。

映象倉庫安全

作為搭建私有映象儲存倉庫的工具，Docker Registry的應用安全性也必須得到保證。映象倉庫的安全風險主要包括倉庫本身的安全風險和映象拉取過程中的傳輸安全風險。

倉庫自身安全：如果映象倉庫特別是私有映象倉庫被惡意攻擊者所控制，那麼其中所有映象的安全性將無法得到保證。例如，如果私有映象倉庫由於配置不當而開啟了2357埠，將會導致私有倉庫暴露在公網中，攻擊者可直接訪問私有倉庫並篡改映象內容，造成倉庫內映象的安全隱患。
映象拉取安全：如何保證容器映象從映象倉庫到使用者端的完整性也是映象倉庫面臨的一個重要安全問題。由於使用者以明文形式拉取映象，如果使用者在與映象倉庫互動的過程中遭遇了中間人攻擊，導致拉取的映象在傳輸過程中被篡改或被冒名釋出惡意映象，會造成映象倉庫和使用者雙方的安全風險。Docker已在其1.8版本後採用內容校驗機制解決中間人攻擊的問題。

容器虛擬化安全風險
與傳統虛擬機器相比，Docker容器不擁有獨立的資源配置，且沒有做到作業系統核心層面的隔離，因此可能存在資源隔離不徹底與資源限制不到位所導致的安全風險。

容器隔離問題

對於Docker容器而言，由於容器與宿主機共享作業系統核心，因此存在容器與宿主機之間、容器與容器之間隔離方面的安全風險，具體包括程序隔離、檔案系統隔離、程序間通訊隔離等。

雖然Docker通過Namespaces進行了檔案系統資源的基本隔離，但仍有/sys、/proc/sys、/proc/bus、/dev、time、syslog等重要系統檔案目錄和名稱空間資訊未實現隔離，而是與宿主機共享相關資源。

針對容器隔離安全風險問題，主要存在以下兩種隔離失效的情況：

攻擊者可能通過對宿主機核心進行攻擊達到攻擊其中某個容器的目的。
由於容器所在主機檔案系統存在聯合掛載的情況，惡意使用者控制的容器也可能通過共同掛載的檔案系統訪問其他容器或宿主機，造成資料安全問題。

容器逃逸攻擊

容器逃逸攻擊指的是容器利用系統漏洞，“逃逸”出了其自身所擁有的許可權，實現了對宿主機和宿主機上其他容器的訪問。由於容器與宿主機共享作業系統核心，為了避免容器獲取宿主機的root許可權，通常不允許採用特權模式執行Docker容器。

在容器逃逸案例中，最為著名的是shocker.c程式，其通過呼叫open_by_handle_at函式對宿主機檔案系統進行暴力掃描，以獲取宿主機的目標檔案內容。由於Docker 1.0之前版本對容器能力（Capability）使用黑名單策略進行管理，並沒有限制CAP_DAC_READ_SEARCH能力，賦予了shocker.c程式呼叫open_by_handle_at函式的能力，導致容器逃逸的發生。因此，對容器能力的限制不當是可能造成容器逃逸等安全問題的風險成因之一。所幸的是，Docker在後續版本中對容器能力採用白名單管理，避免了預設建立的容器通過shocker.c案例實現容器逃逸的情況。

此外，在Black Hat USA 2019會議中，來自Capsule8的研究員也給出了若干Docker容器引擎漏洞與容器逃逸攻擊方法，包括CVE-2019-5736、CVE-2018-18955、CVE-2016-5195等可能造成容器逃逸的漏洞。

CVE-2019-5736是runC的一個安全漏洞，導致18.09.2版本前的Docker允許惡意容器覆蓋宿主機上的runC二進位制檔案。runC是用於建立和執行Docker容器的CLI工具，該漏洞使攻擊者能夠以root身份在宿主機上執行任意命令。
CVE-2018-18955漏洞涉及到User名稱空間中的巢狀使用者名稱空間，使用者名稱空間中針對uid（使用者ID）和gid（使用者組ID）的ID對映機制保證了程序擁有的許可權不會逾越其父名稱空間的範疇。該漏洞利用建立使用者名稱空間的子名稱空間時損壞的ID對映實現提權。
CVE-2016-5195髒牛（Dirty CoW）Linux核心提權漏洞可以使低許可權使用者在多版本Linux系統上實現本地提權，進而可能導致容器逃逸的發生。Linux核心函式get_user_page在處理Copy-on-Write時可能產生競態條件，導致出現向程序地址空間內只讀記憶體區域寫資料的機會，攻擊者可進一步修改su或者passwd程式以獲取root許可權。

拒絕服務攻擊

由於容器與宿主機共享CPU、記憶體、磁碟空間等硬體資源，且Docker本身對容器使用的資源並沒有預設限制，如果單個容器耗盡宿主機的計算資源或儲存資源（例如程序數量、儲存空間等）可能導致宿主機或其他容器的拒絕服務。

1、計算型DoS攻擊

Fork Bomb是一類典型的針對計算資源的拒絕服務攻擊手段，其可通過遞迴方式無限迴圈呼叫fork()系統函式快速建立大量程序。由於宿主機作業系統核心支援的程序總數有限，如果某個容器遭到了Fork Bomb攻擊，那麼就有可能存在由於短時間內在該容器內建立過多程序而耗盡宿主機程序資源的情況，宿主機及其他容器就無法再建立新的程序。

2、儲存型DoS攻擊

針對儲存資源，雖然Docker通過Mount名稱空間實現了檔案系統的隔離，但CGroups並沒有針對AUFS檔案系統進行單個容器的儲存資源限制，因此採用AUFS作為儲存驅動具有一定的安全風險。如果宿主機上的某個容器向AUFS檔案系統中不斷地進行寫檔案操作，則可能會導致宿主機儲存裝置空間不足，無法再滿足其自身及其他容器的資料儲存需求。
網路安全風險
網路安全風險是網際網路中所有資訊系統所面臨的重要風險，不論是物理裝置還是虛擬機器，都存在難以完全規避的網路安全風險問題。而在輕量級虛擬化的容器網路環境中，其網路安全風險較傳統網路而言更為複雜嚴峻。

容器網路攻擊

Docker提供橋接網路、MacVLAN、覆蓋網路（Overlay）等多種組網模式，可分別實現同一宿主機內容器互聯、跨宿主機容器互聯、容器叢集網路等功能。

1、網橋模式

Docker預設採用網橋模式，利用iptables進行NAT轉換和埠對映。Docker將所有容器都通過虛擬網路介面對連線在一個名為docker0的虛擬網橋上，作為容器的預設閘道器，而該網橋與宿主機直接相連。

容器內部的資料包經過虛擬網路介面對到達docker0，實現同一子網內不同容器間的通訊。在網橋模式下，同一宿主機內各容器間可以互相通訊，而宿主機外部無法通過分配給容器的IP地址對容器進行外部訪問。

由於缺乏容器間的網路安全管理機制，無法對同一宿主機內各容器之間的網路訪問許可權進行限制。具體而言，由於各容器之間通過宿主機內部網路的docker0網橋連線以實現路由和NAT轉換，如果容器間沒有防火牆等保護機制，則攻擊者可通過某個容器對宿主機內的其他容器進行ARP欺騙、嗅探、廣播風暴等攻擊，導致資訊洩露、影響網路正常執行等安全後果。

因此，如果在同一臺宿主機上部署的多個容器沒有進行合理的網路配置進行訪問控制邊界隔離，將可能產生容器間的網路安全風險。

2、MacVLAN

MacVLAN是一種輕量級網路虛擬化技術，通過與主機的網路介面連線實現了與實體網路的隔離性。

MacVLAN允許為同一個物理網絡卡配置多個擁有獨立MAC地址的網路介面並可分別配置IP地址，實現了網絡卡的虛擬化。MacVLAN模式無需建立網橋，即無需NAT轉換和埠對映就可以直接通過網路介面連線到物理網路，不同MacVLAN網路間不能在二層網路上進行通訊。

然而，處於同一虛擬網路下各容器間同樣沒有進行訪問許可權控制，因此MacVLAN模式依然存在與網橋模式類似的內部網路攻擊的安全風險。

3、Overlay網路

Overlay網路架構主要用於構建分散式容器叢集，通過VxLAN技術在不同主機之間的Underlay網路上建立虛擬網路，以搭建跨主機容器叢集，實現不同物理主機中同一Overlay網路下的容器間通訊。

與其他組網模式一樣，Overlay網路也沒有對同一網路內各容器間的連線進行訪問控制。此外，由於VxLAN網路流量沒有加密，需要在設定IPSec隧道引數時選擇加密以保證容器網路傳輸內容安全。

因此，無論採用何種網路連線模式，都難以避免容器間互相攻擊的安全風險。

網路DoS攻擊

由於網路虛擬化的存在，容器網路面臨著與傳統網路不同的DoS攻擊安全風險。Docker容器網路的DoS攻擊分為內部威脅和外部威脅兩種主要形式。

內部威脅：針對Docker容器網路環境，DoS攻擊可不通過物理網絡卡而在宿主機內部的容器之間進行，攻擊者通過某個容器向其他容器發起DoS攻擊可能降低其他容器的網路資料處理能力。因此，存在容器虛擬網路間的DoS攻擊風險。
外部威脅：由於同一臺宿主機上的所有容器共享宿主機的物理網絡卡資源，若外部攻擊者使用包含大量受控主機的殭屍網路向某一個目標容器傳送大量資料包進行DDoS攻擊，將可能佔滿宿主機的網路頻寬資源，造成宿主機和其他容器的拒絕服務。

Docker容器安全機制與解決方案
容器虛擬化安全
在傳統虛擬化技術架構中，Hypervisor虛擬機器監視器是虛擬機器資源的管理與排程模組。而在容器架構中，由於不含有Hypervisor層，因此需要依靠作業系統核心層面的相關機制對容器進行安全的資源管理。

容器資源隔離與限制

在資源隔離方面，與採用虛擬化技術實現作業系統核心級隔離不同，Docker通過Linux核心的Namespace機制實現容器與宿主機之間、容器與容器之間資源的相對獨立。通過為各執行容器建立自己的名稱空間，保證了容器中程序的執行不會影響到其他容器或宿主機中的程序。

在資源限制方面，Docker通過CGroups實現宿主機中不同容器的資源限制與審計，包括對CPU、記憶體、I/O等物理資源進行均衡化配置，防止單個容器耗盡所有資源造成其他容器或宿主機的拒絕服務，保證所有容器的正常執行。

但是，CGroups未實現對磁碟儲存資源的限制。若宿主機中的某個容器耗盡了宿主機的所有儲存空間，那麼宿主機中的其他容器無法再進行資料寫入。Docker提供的–storage-opt=[]磁碟限額僅支援Device Mapper檔案系統，而Linux系統本身採用的磁碟限額機制是基於使用者和檔案系統的quota技術，難以針對Docker容器實現基於程序或目錄的磁碟限額。因此，可考慮採用以下方法實現容器的磁碟儲存限制：

為每個容器建立單獨使用者，限制每個使用者的磁碟使用量；
選擇XFS等支援針對目錄進行磁碟使用量限制的檔案系統；
為每個容器建立單獨的虛擬檔案系統，具體步驟為建立固定大小的磁碟檔案，並從該磁碟檔案建立虛擬檔案系統，然後將該虛擬檔案系統掛載到指定的容器目錄。

此外，在預設情況下，容器可以使用主機上的所有記憶體。可以使用記憶體限制機制來防止一個容器消耗所有主機資源的拒絕服務攻擊，具體可使用使用-m或-memory引數執行容器。

（命令示例：docker run [執行引數] -memory [記憶體大小] [容器映象名或ID] [命令]）

容器能力限制

Linux核心能力表示程序所擁有的系統呼叫許可權，決定了程式的系統呼叫能力。

容器的預設能力包括CHOWN、DAC_OVERRIDE、FSETID、SETGID、SETUID、SETFCAP、NET_RAW、MKNOD、SYS_REBOOT、SYS_CHROOT、KILL、NET_BIND_SERVICE、AUDIT_WRITE等等，具體功能如表3所示。

表3：容器預設能力
5.png

如果對容器能力不加以適當限制，可能會存在以下安全隱患：

內部因素：在執行Docker容器時，如果採用預設的核心功能配置可能會產生容器的隔離問題。
外部因素：不必要的核心功能可能導致攻擊者通過容器實現對宿主機核心的攻擊。

因此，不當的容器能力配置可能會擴大攻擊面，增加容器與宿主機面臨的安全風險，在執行docker run命令執行Docker容器時可根據實際需求通過–cap-add或–cap-drop配置介面對容器的能力進行增刪。

（命令示例：docker run --cap-drop ALL --cap-add SYS_TIME ntpd /bin/sh）

強制訪問控制

強制訪問控制（Mandatory Access Control，MAC）是指每一個主體（包括使用者和程式）和客體都擁有固定的安全標記，主體能否對客體進行相關操作，取決於主體和客體所擁有安全標記的關係。在Docker容器應用環境下，可通過強制訪問控制機制限制容器的訪問資源。Linux核心的強制訪問控制機制包括SELinux、AppArmor等。

1、SELinux機制

SELinux（Security-Enhanced Linux）是Linux核心的強制訪問控制實現，由美國國家安全域性（NSA）發起，用以限制程序的資源訪問，即程序僅能訪問其任務所需的檔案資源。因此，可通過SELinux對Docker容器的資源訪問進行控制。

在啟動Docker daemon守護程序時，可通過將–selinux-enabled引數設為true，從而在Docker容器中使用SELinux。SELinux可以使經典的shocker.c程式失效，使其無法逃逸出Docker容器實現對宿主機資源的訪問。

（命令示例：docker daemon --selinux-enabled = true）

2、AppArmor機制

與SELinux類似，AppArmor（Application Armor，應用程式防護）也是Linux的一種強制訪問控制機制，其作用是對可執行程式進行目錄和檔案讀寫、網路埠訪問和讀寫等許可權的控制。

在Docker daemon啟動後會在/etc/apparmor.d/docker自動建立AppArmor的預設配置檔案docker-default，可通過在該預設配置檔案中新增訪問控制規則的方式對容器進行許可權控制，同時可在啟動容器時通過–security-opt指定其他配置檔案。例如，在配置檔案中加入一行deny /etc/hosts rwklx限制對/etc/hosts的獲取，同樣可使shocker.c容器逃逸攻擊失效。

（命令示例：docker run --rm -ti --cap-add=all --security-opt apparmor:docker-default shocker bash）

Seccomp機制

Seccomp（Secure Computing Mode）是Linux核心提供的安全特性，可實現應用程式的沙盒機制構建，以白名單或黑名單的方式限制程序能夠進行的系統呼叫範圍。

在Docker中，可通過為每個容器編寫json格式的seccomp profile實現對容器中程序系統呼叫的限制。在seccomp profile中，可定義以下行為對程序的系統呼叫做出響應：

SCMP_ACT_KILL：當程序進行對應的系統呼叫時，核心發出SIGSYS訊號終止該程序，該程序不會接受到這個訊號；
SCMP_ACT_TRAP：當程序進行對應的系統呼叫時，該程序會接收到SIGSYS訊號，並改變自身行為；
SCMP_ACT_ERRNO：當程序進行對應的系統呼叫時，系統呼叫失敗，程序會接收到errno返回值；
SCMP_ACT_TRACE：當程序進行對應的系統呼叫時，程序會被跟蹤；
SCMP_ACT_ALLOW：允許程序進行對應的系統呼叫行為。

預設情況下，在Docker容器的啟動過程中會使用預設的seccomp profile，可使用security-opt seccomp選項使用特定的seccomp profile。

（命令示例：docker run --rm -it --security-opt seccomp:/path/to/seccomp/profile.json hello-world）

容器安全管理
映象倉庫安全

1、內容信任機制

Docker的內容信任（Content Trust）機制可保護映象在映象倉庫與使用者之間傳輸過程中的完整性。目前，Docker的內容信任機制預設關閉，需要手動開啟。內容信任機制啟用後，映象釋出者可對映象進行簽名，而映象使用者可以對映象簽名進行驗證。

具體而言，映象構建者在通過docker build命令執行Dockerfile檔案前，需要通過手動或指令碼方式將DOCKER_CONTENT_TRUST環境變數置為1進行啟用。在內容信任機制開啟後，push、build、create、pull、run等命令均與內容信任機制繫結，只有通過內容信任驗證的映象才可成功執行這些操作。例如，Dockerfile中如果包含未簽名的基礎映象，將無法成功通過docker build進行映象構建。

（命令示例：export DOCKER_CONTENT_TRUST = 1）

2、Notary專案

Notary是一個從Docker中剝離的獨立開源專案，提供資料收集的安全性。Notary用於釋出內容的安全管理，可對釋出的內容進行數字簽名，並允許使用者驗證內容的完整性和來源。Notary的目標是保證伺服器與客戶端之間使用可信連線進行互動，用於解決網際網路內容釋出的安全性，並未侷限於容器應用。

在Docker容器場景中，Notary可支援Docker內容信任機制。因此，可使用Notary構建映象倉庫伺服器，實現對容器映象的簽名，對映象源認證、映象完整性等安全需求提供更好的支援。

映象安全掃描

為了保證容器執行的安全性，在從公共映象倉庫獲取映象時需要對映象進行安全檢查，防止存在安全隱患甚至惡意漏洞的映象執行，從源頭端預防安全事故的發生。映象漏洞掃描工具是一類常用的映象安全檢查輔助工具，可檢測出容器映象中含有的CVE漏洞。

針對Docker映象的漏洞掃描，目前已經有許多相關工具與解決方案，包括Docker Security Scanning、Clair、Anchore、Trivy、Aqua等等。

1、Docker Security Scanning服務

Docker Security Scanning是Docker官方推出的不開源映象漏洞掃描服務，用於檢測Docker Cloud服務中私有倉庫和Docker Hub官方倉庫中的映象是否安全。

Docker Security Scanning包括掃描觸發、掃描器、資料庫、附加元件框架以及CVE漏洞資料庫比對等服務。當倉庫中有映象發生更新時，會自動啟動漏洞掃描；當CVE漏洞資料庫發生更新時，也會實時更新映象漏洞掃描結果。

2、Clair工具

Clair是一款開源的Docker映象漏洞掃描工具。與Docker Security Scanning類似，Clair通過對Docker映象進行靜態分析並與公共漏洞資料庫關聯，得到相應的漏洞分析結果。Clair主要包括以下模組：

Fetcher（獲取器）：從公共的CVE漏洞源收集漏洞資料；
Detector（檢測器）：對映象的每一個Layer進行掃描，提取映象特徵；
Notifier（通知器）：用於接收WebHook從公開CVE漏洞庫中的最新漏洞資訊並進行漏洞庫更新；
Databases（資料庫）：PostSQL資料庫儲存容器中的各個層和CVE漏洞；

3、Trivy工具

Trivy是一個簡單而全面的開源容器漏洞掃描程式。Trivy可檢測作業系統軟體包（Alpine、RHEL、CentOS等）和應用程式依賴項（Bundler、Composer、npm、yarn等）的漏洞。此外，Trivy具有較高的易用性，只需安裝二進位制檔案並指定掃描容器的映象名稱即可執行掃描。Trivy提供了豐富的功能介面，相比於其他容器映象漏洞掃描工具更適合自動化操作，可更好地滿足持續整合的需求。

（命令示例：trivy [映象名]）

容器執行時監控

為了在系統運維層面保證容器執行的安全性，實現安全風險的即時告警與應急響應，需要對Docker容器執行時的各項效能指標進行實時監控。

針對Docker容器監控的工具與解決方案包括docker stats、cAdvisor、Scout、DataDog、Sensu等等，其中最常見的是Docker原生的docker stats命令和Google的cAdvisor開源工具。

1、docker stats命令

docker stats是Docker自帶的容器資源使用統計命令，可用於對宿主機上的Docker容器的資源使用情況進行手動監控，具體內容包括容器的基本資訊、容器的CPU使用率、記憶體使用率、記憶體使用量與限制、塊裝置I/O使用量、網路I/O使用量、程序數等資訊。使用者可根據自身需求設定–format引數控制docker stats 命令輸出的內容格式。

（命令示例：docker stats [容器名]）

2、cAdvisor工具

由於docker stats只是簡單的容器資源檢視命令，其視覺化程度不高，同時不支援監控資料的儲存。cAdvisor是由Google開源的容器監控工具，優化了docker stats在視覺化展示與資料儲存方面的缺陷。

cAdvisor在宿主機上以容器方式執行，通過掛載在本地卷，可對同一臺宿主機上執行的所有容器進行實時監控和效能資料採集，具體包括CPU使用情況、記憶體使用情況、網路吞吐量、檔案系統使用情況等資訊，並提供本地基礎查詢介面和API介面，方便與其他第三方工具進行搭配使用。cAdvisor預設將資料快取在記憶體中，同時也提供不同的持久化儲存後端支援，可將監控資料儲存Google BigQuery、InfluxDB或Redis等資料庫中。

cAdvisor基於Go語言開發，利用CGroups獲取容器的資源使用資訊，目前已被整合在Kubernetes中的Kubelet元件裡作為預設啟動項。

（命令示例：docker run -v /var/run:/var/run:rw -v/sys:/sys:ro -v/var/lib/docker:/var/lib/docker:ro -p8080:8080 -d --name cadvisor google/cadvisor）

容器安全審計

1、Docker守護程序審計

在安全審計方面，對於執行Docker容器的宿主機而言，除需對主機Linux檔案系統等進行審計外，還需對Docker守護程序的活動進行審計。由於系統預設不會對Docker守護程序進行審計，需要通過主動新增審計規則或修改規則檔案進行。

（命令示例：auditctl -w /usr/bin/docker -k docker或修改/etc/audit/audit.rules檔案）

2、Docker相關檔案目錄審計

除Docker守護程序之外，還需對與Docker的執行相關的檔案和目錄進行審計，同樣需要通過命令列新增審計規則或修改規則配置檔案，具體檔案和目錄如表4所示。

表4：Docker相關檔案和目錄審計
6.png

Docker公司與美國網際網路安全中心（CIS）聯合制定了Docker最佳安全實踐CIS Docker Benchmark，目前最新版本為1.2.0。為了幫助Docker使用者對其部署的容器環境進行安全檢查，Docker官方提供了Docker Bench for Security安全配置檢查指令碼工具docker-bench-security，其檢查依據便是CIS制定的Docker最佳安全實踐。
容器網路安全
容器間流量限制

由於Docker容器預設的網橋模式不會對網路流量進行控制和限制，為了防止潛在的網路DoS攻擊風險，需要根據實際需求對網路流量進行相應的配置。

1、完全禁止容器間通訊

在特定的應用場景中，如果宿主機中的所有容器無需在三層或四層進行網路通訊互動，可通過將Docker daemon的–icc引數設為false以禁止容器與容器間的通訊。

（命令示例：dockerd --icc = false）

2、容器間流量控制

在存在多租戶的容器雲環境中，可能存在單個容器佔用大量宿主機物理網絡卡搶佔其他容器頻寬的情況。為了保證容器之間的正常通訊，同時避免異常流量造成網路DoS攻擊等後果，需要對容器之間的通訊流量進行一定的限制。

由於Docker通過建立虛擬網絡卡對（eth0和veth* ）將容器與虛擬網橋docker0連線，而容器之間的通訊需要經由虛擬網絡卡對eth0和veth* 通過網橋連線，因此，可採用Linux的流量控制模組traffic controller對容器網路進行流量限制。

traffic controller的原理是建立資料包佇列並制定傳送規則，實現流量限制與排程的功能。為了在一定程度上減輕容器間的DoS攻擊的危害，可將traffic controller的dev設定為宿主機中與各容器連線的veth*虛擬網絡卡，以此進行宿主機上容器間流量限制。

網橋模式下的網路訪問控制

在預設的網橋連線模式中，連線在同一個網橋的兩個容器可以進行直接相互訪問。因此，為了實現網路訪問控制，可按需配置網路訪問控制機制和策略。

1、為容器建立不同的橋接網路

為了實現容器間的網路隔離，可將容器放在不同的橋接網路中。當在Docker中使用docker network create命令建立新的橋接網路時，會在iptables中的DOCKER-ISOLATION新增DROP丟棄規則，阻斷與其他網路之間的通訊流量，實現容器網路之間隔離的目的。

（命令示例：docker network create --subnet 102.102.0.0/24 test）

2、基於白名單策略的網路訪問控制

為了保證容器間的網路安全，可預設禁止容器間的通訊，然後按需設定網路訪問控制規則。

具體而言，在同一虛擬網路內，不同Docker容器之間的網路訪問可通過iptables進行控制。在將Docker daemon的–icc引數設為false後，iptables的FORWARD鏈策略為預設全部丟棄。此時，可採用白名單策略實現網路訪問控制，即根據實際需要在iptables中新增訪問控制策略，以最小化策略減小攻擊面。

叢集模式下的網路訪問控制

與通過OpenStack建立的虛擬化叢集通過VLAN對不同租戶進行子網隔離不同，基於Overlay網路的容器叢集在同一主機內相同子網中的不同容器之間預設可以直接訪問。

如需控制宿主機外部到內部容器應用的訪問，可通過在宿主機iptables中的DOCKER-INGRESS鏈手動新增ACL訪問控制規則以控制宿主機的eth0到容器的訪問，或者在宿主機外部部署防火牆等方法實現。

然而，在大型的容器雲環境中，由於存在頻繁的微服務動態變化更新，通過手動的方式配置iptables或更新防火牆是不現實的。因此，可通過微分段（Micro-Segmentation）實現面向容器雲環境中的容器防火牆。微分段是一種細粒度的網路分段隔離機制，與傳統的以網路地址為基本單位的網路分段機制不同，微分段可以以單個容器、同網段容器、容器應用為粒度實現分段隔離，並通過容器防火牆對實現微分段間的網路訪問控制。
總結
與虛擬化技術相比，Docker容器技術具有敏捷化、輕量化等特點，在推進雲原生應用方面具有不可替代性。與此同時，容器技術對於高效性的追求也犧牲了隔離性等安全要求，在安全性方面與虛擬化技術相比還存在較大差距，且所涉及的面較廣，涉及到容器的映象安全、核心安全、網路安全、虛擬化安全、執行時安全等各個層面。

在應用容器技術進行系統部署時，應充分評估安全風險，根據應用場景制定相應安全需求，並整合相關安全解決方案，形成容器安全應用最佳實踐。

文章來源：FreeBuf.COM，作者：狴犴安全團隊。
原文地址：http://www.dockone.io/article/9817