Docker是目前最具代表性的容器技術之一，對雲計算及虛擬化技術產生了顛覆性的影響。本文對Docker容器在應用中可能面臨的安全問題和風險進行了研究，並將Docker容器應用環境中的安全機制與相關解決方案分爲容器虛擬化安全、容器安全管理、容器網絡安全三部分進行分析。
從虛擬化安全到容器安全
傳統虛擬化技術
虛擬化技術是實現硬件基礎設施資源的充分利用、合理分配和有效調度的重要技術手段。例如，在基於OpenStack的典型IaaS服務中，雲服務提供商可通過搭建設備集羣建立資源池，並將服務器、存儲和網絡等底層資源進行彈性虛擬化提供給租戶。
傳統虛擬化技術以虛擬機爲管理單元，各虛擬機擁有獨立的操作系統內核，不共用宿主機的軟件系統資源，因此具有良好的隔離性，適用於雲計算環境中的多租戶場景。
容器技術
容器技術可以看作一種輕量級的虛擬化方式，將應用與必要的執行環境打包成容器鏡像，使得應用程序可以直接在宿主機（物理機或虛擬機）中相對獨立地運行。容器技術在操作系統層進行虛擬化，可在宿主機內核上運行多個虛擬化環境。相比於傳統的應用測試與部署，容器的部署無需預先考慮應用的運行環境兼容性問題；相比於傳統虛擬機，容器無需獨立的操作系統內核就可在宿主機中運行，實現了更高的運行效率與資源利用率。
Docker是目前最具代表性的容器平臺之一，它模糊了傳統的IaaS和PaaS的邊界，具有持續部署與測試、跨雲平臺支持等優點。在基於Kubernetes等容器編排工具實現的容器雲環境中，通過對跨主機集羣資源的調度，容器雲可提供資源共享與隔離、容器編排與部署、應用支撐等功能。
Docker容器技術以宿主機中的容器爲管理單元，但各容器共用宿主機內核資源，分別通過linux系統的Namespaces和CGroups機制實現資源的隔離與限制。
Namespaces
爲了保證容器進程之間的資源隔離，避免相互影響和干擾，Linux內核的Namespaces（命名空間）機制提供了UTS、User、Mount、Network、PID、IPC等命名空間實現了主機名、用戶權限、文件系統、網絡、進程號、進程間通信等六項資源隔離功能。通過調用clone函數並傳入相應的系統調用參數創建容器進程，可實現對應資源內容的隔離，具體情況如表1所示。
| 命名空間 | 系統調用參數 | 隔離內容 | Linux內核版本 |
|---|---|---|---|
| UTS | CLONE_NEWUTS | 主機名和域名 | 2.6.19 |
| IPC | CLONE_NEWIPC | 信號量、信息隊列和共享內存 | 2.6.19 |
| PID | CLONE_NEWPID | 進程編號 | 2.6.24 |
| Network | CLONE_NEWNET | 網絡設備、網絡棧、端口等 | 2.6.29 |
| Mount | CLONE_NEWNS | 掛載點（文件系統） | 2.4.19 |
| User | CLONE_NEWUSER | 用戶和用戶組 | 3.8 |
表1：Namespaces隔離機制
對於某個進程而言，可通過查看/proc/[PID]/ns文件，獲取該進程下的命名空間隔離情況，如圖1所示。其中，每一項命名空間都擁有一個編號對其進行唯一標識，如果宿主機中兩個進程指向的命名空間編號相同，則表示他們同在一個命名空間之下。
圖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所示。
| 子系統 | 功能 |
|---|---|
| blkio | 爲塊設備（如磁盤、固態硬盤等物理驅動設備）設定輸入/輸出限制 |
| cpu | 通過調度程序控制任務對CPU的使用 |
| cpuacct | 生成任務對CPU資源使用情況的報告 |
| cpuset | 爲任務分配獨立的CPU和內存 |
| devices | 開啓或關閉任務對設備的訪問 |
| freezer | 掛起或恢復任務 |
| memory | 設定任務對內存的使用量限制，生成任務對內存資源使用情況的報告 |
表2：CGroups子系統
安全性
傳統虛擬化技術與Docker容器技術在運行時的安全性差異主要體現在隔離性方面，包括進程隔離、文件系統隔離、設備隔離、進程間通信隔離、網絡隔離、資源限制等。
在Docker容器環境中，由於各容器共享操作系統內核，而容器僅爲運行在宿主機上的若干進程，其安全性特別是隔離性與傳統虛擬機相比在理論上與實際上都存在一定的差距。
Docker容器安全風險分析
根據Docker容器的主要特點及其在安全應用中的實際問題，本文將Docker容器技術應用中可能存在的技術性安全風險分爲鏡像安全風險、容器虛擬化安全風險、網絡安全風險等類型進行具體分析，如圖2所示。
圖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等可能造成容器逃逸的漏洞。
拒絕服務***
由於容器與宿主機共享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所示。
| 容器默認能力 | 作用 |
|---|---|
| CHOWN | 允許任意更改文件UID以及GID |
| DAC_OVERRIDE | 允許忽略文件的讀、寫、執行訪問權限檢查 |
| FSETID | 允許文件修改後保留setuid/setgid標誌位 |
| SETGID | 允許改變進程組ID |
| SETUID | 允許改變進程用戶ID |
| SETFCAP | 允許向其他進程轉移或刪除能力 |
| NET_RAW | 允許創建RAW和PACKET套接字 |
| MKNOD | 允許使用mknod創建指定文件 |
| SYS_REBOOT | 允許使用reboot或者kexec_load |
| SYS_CHROOT | 允許使用chroot |
| KILL | 允許發送信號 |
| NET_BIND_SERVICE | 允許綁定常用端口號（端口號小於1024） |
| AUDIT_WRITE | 允許審計日誌寫入 |
表3：容器默認能力
如果對容器能力不加以適當限制，可能會存在以下安全隱患：
內部因素：在運行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所示。
| 需要審計的文件或目錄 | 備註 |
|---|---|
| /var/lib/docker | 包含有關容器的所有信息 |
| /etc/docker | 包含Docker守護進程和客戶端TLS通信的密鑰和證書 |
| docker.service | Docker守護進程運行參數配置文件 |
| docker.socket | 守護進程運行socket |
| /etc/default/docker | 支持Docker守護進程各種參數 |
| /etc/default/daemon.json | 支持Docker守護進程各種參數 |
| /usr/bin/docker-containerd | Docker可用containerd生成容器 |
| /usr/bin/docker-runc | Docker可用runC生成容器 |
表4：Docker相關文件和目錄審計
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容器技術具有敏捷化、輕量化等特點，在推進雲原生應用方面具有不可替代性。與此同時，容器技術對於高效性的追求也犧牲了隔離性等安全要求，在安全性方面與虛擬化技術相比還存在較大差距，且所涉及的面較廣，涉及到容器的鏡像安全、內核安全、網絡安全、虛擬化安全、運行時安全等各個層面。
在應用容器技術進行系統部署時，應充分評估安全風險，根據應用場景制定相應安全需求，並整合相關安全解決方案，形成容器安全應用最佳實踐。