Docker是目前最具代表性的容器技術(shù)之一，對云計算及虛擬化技術(shù)產(chǎn)生了顛覆性的影響。本文對Docker容器在應(yīng)用中可能面臨的安全問題和風(fēng)險進(jìn)行了研究，并將Docker容器應(yīng)用環(huán)境中的安全機制與相關(guān)解決方案分為容器虛擬化安全、容器安全管理、容器網(wǎng)絡(luò)安全三部分進(jìn)行分析。

成都創(chuàng)新互聯(lián)公司專注于浚縣網(wǎng)站建設(shè)服務(wù)及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗。 熱誠為您提供?？h營銷型網(wǎng)站建設(shè)，?？h網(wǎng)站制作、浚縣網(wǎng)頁設(shè)計、浚縣網(wǎng)站官網(wǎng)定制、小程序定制開發(fā)服務(wù)，打造?？h網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供浚縣網(wǎng)站排名全網(wǎng)營銷落地服務(wù)。

從虛擬化安全到容器安全

傳統(tǒng)虛擬化技術(shù)

虛擬化技術(shù)是實現(xiàn)硬件基礎(chǔ)設(shè)施資源的充分利用、合理分配和有效調(diào)度的重要技術(shù)手段。例如，在基于OpenStack的典型IaaS服務(wù)中，云服務(wù)提供商可通過搭建設(shè)備集群建立資源池，并將服務(wù)器、存儲和網(wǎng)絡(luò)等底層資源進(jìn)行彈性虛擬化提供給租戶。

傳統(tǒng)虛擬化技術(shù)以虛擬機為管理單元，各虛擬機擁有獨立的操作系統(tǒng)內(nèi)核，不共用宿主機的軟件系統(tǒng)資源，因此具有良好的隔離性，適用于云計算環(huán)境中的多租戶場景。

容器技術(shù)

容器技術(shù)可以看作一種輕量級的虛擬化方式，將應(yīng)用與必要的執(zhí)行環(huán)境打包成容器鏡像，使得應(yīng)用程序可以直接在宿主機（物理機或虛擬機）中相對獨立地運行。容器技術(shù)在操作系統(tǒng)層進(jìn)行虛擬化，可在宿主機內(nèi)核上運行多個虛擬化環(huán)境。相比于傳統(tǒng)的應(yīng)用測試與部署，容器的部署無需預(yù)先考慮應(yīng)用的運行環(huán)境兼容性問題；相比于傳統(tǒng)虛擬機，容器無需獨立的操作系統(tǒng)內(nèi)核就可在宿主機中運行，實現(xiàn)了更高的運行效率與資源利用率。

Docker是目前最具代表性的容器平臺之一，它模糊了傳統(tǒng)的IaaS和PaaS的邊界，具有持續(xù)部署與測試、跨云平臺支持等優(yōu)點。在基于Kubernetes等容器編排工具實現(xiàn)的容器云環(huán)境中，通過對跨主機集群資源的調(diào)度，容器云可提供資源共享與隔離、容器編排與部署、應(yīng)用支撐等功能。

Docker容器技術(shù)以宿主機中的容器為管理單元，但各容器共用宿主機內(nèi)核資源，分別通過linux系統(tǒng)的Namespaces和CGroups機制實現(xiàn)資源的隔離與限制。

Namespaces

為了保證容器進(jìn)程之間的資源隔離，避免相互影響和干擾，Linux內(nèi)核的Namespaces（命名空間）機制提供了UTS、User、Mount、Network、PID、IPC等命名空間實現(xiàn)了主機名、用戶權(quán)限、文件系統(tǒng)、網(wǎng)絡(luò)、進(jìn)程號、進(jìn)程間通信等六項資源隔離功能。通過調(diào)用clone函數(shù)并傳入相應(yīng)的系統(tǒng)調(diào)用參數(shù)創(chuàng)建容器進(jìn)程，可實現(xiàn)對應(yīng)資源內(nèi)容的隔離，具體情況如表1所示。

表1：Namespaces隔離機制

對于某個進(jìn)程而言，可通過查看/proc/[PID]/ns文件，獲取該進(jìn)程下的命名空間隔離情況，如圖1所示。其中，每一項命名空間都擁有一個編號對其進(jìn)行唯一標(biāo)識，如果宿主機中兩個進(jìn)程指向的命名空間編號相同，則表示他們同在一個命名空間之下。

圖1：進(jìn)程命名空間

CGroups

CGroups（Control Groups，控制組）機制最早于2006年由google提出，目前是Linux內(nèi)核的一種機制，可以實現(xiàn)對任務(wù)組（進(jìn)程組或線程組）使用的物理資源（CPU、內(nèi)存、I/O等）進(jìn)行限制和記錄，通過多種度量標(biāo)準(zhǔn)為各個容器相對公平地分配資源，以防止資源濫用的情況。

在實際應(yīng)用中，CGroups會為每個執(zhí)行任務(wù)創(chuàng)建一個鉤子，在任務(wù)執(zhí)行的過程中涉及到資源分配使用時，就會觸發(fā)鉤子上的函數(shù)并對相應(yīng)的資源進(jìn)行檢測，從而對資源進(jìn)行限制和優(yōu)先級分配。

CGroups提供了資源限制（Resource Limitation）、優(yōu)先級分配（Prioritization）、資源統(tǒng)計（Accounting）、任務(wù)控制（Control）四個功能，包含blkio、cpu、cpuacct、cpuset、devices、freezer、memory、perf_event、net_cls、net_prio、ns、hugetlb等子系統(tǒng)，每種子系統(tǒng)獨立地控制一種資源，可分別實現(xiàn)塊設(shè)備輸入/輸出限制、CPU使用控制、生成CPU資源使用情況報告、內(nèi)存使用量限制等功能。幾個主要子系統(tǒng)的具體功能如表2所示。

表2：CGroups子系統(tǒng)

安全性

傳統(tǒng)虛擬化技術(shù)與Docker容器技術(shù)在運行時的安全性差異主要體現(xiàn)在隔離性方面，包括進(jìn)程隔離、文件系統(tǒng)隔離、設(shè)備隔離、進(jìn)程間通信隔離、網(wǎng)絡(luò)隔離、資源限制等。

在Docker容器環(huán)境中，由于各容器共享操作系統(tǒng)內(nèi)核，而容器僅為運行在宿主機上的若干進(jìn)程，其安全性特別是隔離性與傳統(tǒng)虛擬機相比在理論上與實際上都存在一定的差距。

Docker容器安全風(fēng)險分析

根據(jù)Docker容器的主要特點及其在安全應(yīng)用中的實際問題，本文將Docker容器技術(shù)應(yīng)用中可能存在的技術(shù)性安全風(fēng)險分為鏡像安全風(fēng)險、容器虛擬化安全風(fēng)險、網(wǎng)絡(luò)安全風(fēng)險等類型進(jìn)行具體分析，如圖2所示。

圖2：容器安全風(fēng)險分類

鏡像安全風(fēng)險

Docker鏡像是Docker容器的靜態(tài)表示形式，鏡像的安全決定了容器的運行時安全。

Docker容器官方鏡像倉庫Docker Hub中的鏡像可能由個人開發(fā)者上傳，其數(shù)量豐富、版本多樣，但質(zhì)量參差不齊，甚至存在包含惡意漏洞的惡意鏡像，因而可能存在較大的安全風(fēng)險。具體而言，Docker鏡像的安全風(fēng)險分布在創(chuàng)建過程、獲取來源、獲取途徑等方方面面。

Dockerfile安全問題

Docker鏡像的生成主要包括兩種方式，一種是對運行中的動態(tài)容器通過docker commit命令進(jìn)行打包，另一種是通過docker build命令執(zhí)行Dockerfile文件進(jìn)行創(chuàng)建。為了確保最小安裝原則，同時考慮容器的易維護(hù)性，一般推薦采用Dockerfile文件構(gòu)建容器鏡像，即在基礎(chǔ)鏡像上進(jìn)行逐層應(yīng)用添加操作。

Dockerfile是包含用于組合鏡像命令的文本文件，一般由基礎(chǔ)鏡像信息（FROM）、維護(hù)者信息（MAINTAINER）、鏡像操作指令（RUN、ADD、COPY等）、容器啟動時執(zhí)行指令（CMD等）四個部分組成，Docker可通過讀取Dockerfile中的命令創(chuàng)建容器鏡像。

Dockerfile文件內(nèi)容在一定程度上決定了Docker鏡像的安全性，其安全風(fēng)險具體包括但不限于以下情況：

• 如果Dockerfile存在漏洞或被插入惡意腳本，那么生成的容器也可能產(chǎn)生漏洞或被惡意利用。例如，***者可構(gòu)造特殊的Dockerfile壓縮文件，在編譯時觸發(fā)漏洞獲取執(zhí)行任意代碼的權(quán)限。

• 如果在Dockerfile中沒有指定USER，Docker將默認(rèn)以root用戶的身份運行該Dockerfile創(chuàng)建的容器，如果該容器遭到***，那么宿主機的root訪問權(quán)限也可能會被獲取。

• 如果在Dockerfile文件中存儲了固定密碼等敏感信息并對外進(jìn)行發(fā)布，則可能導(dǎo)致數(shù)據(jù)泄露的風(fēng)險。

• 如果在Dockerfile的編寫中添加了不必要的應(yīng)用，如SSH、Telnet等，則會產(chǎn)生***面擴大的風(fēng)險。

鏡像漏洞

對于大多數(shù)一般的開發(fā)者而言，通常需要獲取一系列基礎(chǔ)鏡像進(jìn)行容器云的部署和進(jìn)一步開發(fā)，因此，基礎(chǔ)鏡像的安全性在一定程度上決定了容器云環(huán)境的安全性。

鏡像漏洞安全風(fēng)險具體包括鏡像中的軟件含有CVE漏洞、***者上傳含有惡意漏洞的鏡像等情況。

1、CVE漏洞

由于鏡像通常由基礎(chǔ)操作系統(tǒng)與各類應(yīng)用軟件構(gòu)成，因此，含有CVE漏洞的應(yīng)用軟件同樣也會向Docker鏡像中引入CVE漏洞。

鏡像的獲取通常是通過官方鏡像倉庫Docker Hub或網(wǎng)易、阿里云等提供的第三方鏡像倉庫。然而，根據(jù)對Docker Hub中鏡像安全漏洞的相關(guān)研究，無論是社區(qū)鏡像還是官方鏡像，其平均漏洞數(shù)均接近200個，包括Nginx、MySQL、redis在內(nèi)的常用鏡像都含有高危漏洞。

2、惡意漏洞

惡意用戶可能將含有后門、病毒等惡意漏洞的鏡像上傳至官方鏡像庫。2018年6月，安全廠商Fortinet和Kromtech在Docker Hub上發(fā)現(xiàn)17個包含用于數(shù)字貨幣挖礦惡意程序的Docker鏡像，而這 些惡意鏡像當(dāng)時已有500萬次的下載量 。目前，由于Docker應(yīng)用在世界范圍內(nèi)具有廣泛性，全網(wǎng)針對Docker容器的***很多都被用于進(jìn)行數(shù)字貨幣挖礦，為***者帶來實際經(jīng)濟利益，損害Docker用戶的正常使用。

鏡像倉庫安全

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

• 倉庫自身安全：如果鏡像倉庫特別是私有鏡像倉庫被惡意***者所控制，那么其中所有鏡像的安全性將無法得到保證。例如，如果私有鏡像倉庫由于配置不當(dāng)而開啟了2357端口，將會導(dǎo)致私有倉庫暴露在公網(wǎng)中，***者可直接訪問私有倉庫并篡改鏡像內(nèi)容，造成倉庫內(nèi)鏡像的安全隱患。

• 鏡像拉取安全：如何保證容器鏡像從鏡像倉庫到用戶端的完整性也是鏡像倉庫面臨的一個重要安全問題。由于用戶以明文形式拉取鏡像，如果用戶在與鏡像倉庫交互的過程中遭遇了中間人***，導(dǎo)致拉取的鏡像在傳輸過程中被篡改或被冒名發(fā)布惡意鏡像，會造成鏡像倉庫和用戶雙方的安全風(fēng)險。Docker已在其1.8版本后采用內(nèi)容校驗機制解決中間人***的問題。

容器虛擬化安全風(fēng)險

與傳統(tǒng)虛擬機相比，Docker容器不擁有獨立的資源配置，且沒有做到操作系統(tǒng)內(nèi)核層面的隔離，因此可能存在資源隔離不徹底與資源限制不到位所導(dǎo)致的安全風(fēng)險。

容器隔離問題

對于Docker容器而言，由于容器與宿主機共享操作系統(tǒng)內(nèi)核，因此存在容器與宿主機之間、容器與容器之間隔離方面的安全風(fēng)險，具體包括進(jìn)程隔離、文件系統(tǒng)隔離、進(jìn)程間通信隔離等。

雖然Docker通過Namespaces進(jìn)行了文件系統(tǒng)資源的基本隔離，但仍有/sys、/proc/sys、/proc/bus、/dev、time、syslog等重要系統(tǒng)文件目錄和命名空間信息未實現(xiàn)隔離，而是與宿主機共享相關(guān)資源。

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

• ***者可能通過對宿主機內(nèi)核進(jìn)行***達(dá)到***其中某個容器的目的。

• 由于容器所在主機文件系統(tǒng)存在聯(lián)合掛載的情況，惡意用戶控制的容器也可能通過共同掛載的文件系統(tǒng)訪問其他容器或宿主機，造成數(shù)據(jù)安全問題。

容器逃逸***

容器逃逸***指的是容器利用系統(tǒng)漏洞，“逃逸”出了其自身所擁有的權(quán)限，實現(xiàn)了對宿主機和宿主機上其他容器的訪問。由于容器與宿主機共享操作系統(tǒng)內(nèi)核，為了避免容器獲取宿主機的root權(quán)限，通常不允許采用特權(quán)模式運行Docker容器。

在容器逃逸案例中，最為著名的是shocker.c程序，其通過調(diào)用open_by_handle_at函數(shù)對宿主機文件系統(tǒng)進(jìn)行暴力掃描，以獲取宿主機的目標(biāo)文件內(nèi)容。由于Docker 1.0之前版本對容器能力（Capability）使用黑名單策略進(jìn)行管理，并沒有限制CAP_DAC_READ_SEARCH能力，賦予了shocker.c程序調(diào)用open_by_handle_at函數(shù)的能力，導(dǎo)致容器逃逸的發(fā)生。因此，對容器能力的限制不當(dāng)是可能造成容器逃逸等安全問題的風(fēng)險成因之一。所幸的是，Docker在后續(xù)版本中對容器能力采用白名單管理，避免了默認(rèn)創(chuàng)建的容器通過shocker.c案例實現(xiàn)容器逃逸的情況。

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

拒絕服務(wù)***

由于容器與宿主機共享CPU、內(nèi)存、磁盤空間等硬件資源，且Docker本身對容器使用的資源并沒有默認(rèn)限制，如果單個容器耗盡宿主機的計算資源或存儲資源（例如進(jìn)程數(shù)量、存儲空間等）可能導(dǎo)致宿主機或其他容器的拒絕服務(wù)。

1、計算型DoS***

Fork Bomb是一類典型的針對計算資源的拒絕服務(wù)***手段，其可通過遞歸方式無限循環(huán)調(diào)用fork系統(tǒng)函數(shù)快速創(chuàng)建大量進(jìn)程。由于宿主機操作系統(tǒng)內(nèi)核支持的進(jìn)程總數(shù)有限，如果某個容器遭到了Fork Bomb***，那么就有可能存在由于短時間內(nèi)在該容器內(nèi)創(chuàng)建過多進(jìn)程而耗盡宿主機進(jìn)程資源的情況，宿主機及其他容器就無法再創(chuàng)建新的進(jìn)程。

2、存儲型DoS***

針對存儲資源，雖然Docker通過Mount命名空間實現(xiàn)了文件系統(tǒng)的隔離，但CGroups并沒有針對AUFS文件系統(tǒng)進(jìn)行單個容器的存儲資源限制，因此采用AUFS作為存儲驅(qū)動具有一定的安全風(fēng)險。如果宿主機上的某個容器向AUFS文件系統(tǒng)中不斷地進(jìn)行寫文件操作，則可能會導(dǎo)致宿主機存儲設(shè)備空間不足，無法再滿足其自身及其他容器的數(shù)據(jù)存儲需求。

網(wǎng)絡(luò)安全風(fēng)險

網(wǎng)絡(luò)安全風(fēng)險是互聯(lián)網(wǎng)中所有信息系統(tǒng)所面臨的重要風(fēng)險，不論是物理設(shè)備還是虛擬機，都存在難以完全規(guī)避的網(wǎng)絡(luò)安全風(fēng)險問題。而在輕量級虛擬化的容器網(wǎng)絡(luò)環(huán)境中，其網(wǎng)絡(luò)安全風(fēng)險較傳統(tǒng)網(wǎng)絡(luò)而言更為復(fù)雜嚴(yán)峻。

容器網(wǎng)絡(luò)***

Docker提供橋接網(wǎng)絡(luò)、macVLAN、覆蓋網(wǎng)絡(luò)（Overlay）等多種組網(wǎng)模式，可分別實現(xiàn)同一宿主機內(nèi)容器互聯(lián)、跨宿主機容器互聯(lián)、容器集群網(wǎng)絡(luò)等功能。

1、網(wǎng)橋模式

Docker默認(rèn)采用網(wǎng)橋模式，利用iptables進(jìn)行NAT轉(zhuǎn)換和端口映射。Docker將所有容器都通過虛擬網(wǎng)絡(luò)接口對連接在一個名為docker0的虛擬網(wǎng)橋上，作為容器的默認(rèn)網(wǎng)關(guān)，而該網(wǎng)橋與宿主機直接相連。

容器內(nèi)部的數(shù)據(jù)包經(jīng)過虛擬網(wǎng)絡(luò)接口對到達(dá)docker0，實現(xiàn)同一子網(wǎng)內(nèi)不同容器間的通信。在網(wǎng)橋模式下，同一宿主機內(nèi)各容器間可以互相通信，而宿主機外部無法通過分配給容器的IP地址對容器進(jìn)行外部訪問。

由于缺乏容器間的網(wǎng)絡(luò)安全管理機制，無法對同一宿主機內(nèi)各容器之間的網(wǎng)絡(luò)訪問權(quán)限進(jìn)行限制。具體而言，由于各容器之間通過宿主機內(nèi)部網(wǎng)絡(luò)的docker0網(wǎng)橋連接以實現(xiàn)路由和NAT轉(zhuǎn)換，如果容器間沒有防火墻等保護(hù)機制，則***者可通過某個容器對宿主機內(nèi)的其他容器進(jìn)行ARP欺騙、嗅探、廣播風(fēng)暴等***，導(dǎo)致信息泄露、影響網(wǎng)絡(luò)正常運行等安全后果。

因此，如果在同一臺宿主機上部署的多個容器沒有進(jìn)行合理的網(wǎng)絡(luò)配置進(jìn)行訪問控制邊界隔離，將可能產(chǎn)生容器間的網(wǎng)絡(luò)安全風(fēng)險。

2、MacVLAN

MacVLAN是一種輕量級網(wǎng)絡(luò)虛擬化技術(shù)，通過與主機的網(wǎng)絡(luò)接口連接實現(xiàn)了與實體網(wǎng)絡(luò)的隔離性。

MacVLAN允許為同一個物理網(wǎng)卡配置多個擁有獨立MAC地址的網(wǎng)絡(luò)接口并可分別配置IP地址，實現(xiàn)了網(wǎng)卡的虛擬化。MacVLAN模式無需創(chuàng)建網(wǎng)橋，即無需NAT轉(zhuǎn)換和端口映射就可以直接通過網(wǎng)絡(luò)接口連接到物理網(wǎng)絡(luò)，不同MacVLAN網(wǎng)絡(luò)間不能在二層網(wǎng)絡(luò)上進(jìn)行通信。

然而，處于同一虛擬網(wǎng)絡(luò)下各容器間同樣沒有進(jìn)行訪問權(quán)限控制，因此MacVLAN模式依然存在與網(wǎng)橋模式類似的內(nèi)部網(wǎng)絡(luò)***的安全風(fēng)險。

3、Overlay網(wǎng)絡(luò)

Overlay網(wǎng)絡(luò)架構(gòu)主要用于構(gòu)建分布式容器集群，通過VxLAN技術(shù)在不同主機之間的Underlay網(wǎng)絡(luò)上建立虛擬網(wǎng)絡(luò)，以搭建跨主機容器集群，實現(xiàn)不同物理主機中同一Overlay網(wǎng)絡(luò)下的容器間通信。

與其他組網(wǎng)模式一樣，Overlay網(wǎng)絡(luò)也沒有對同一網(wǎng)絡(luò)內(nèi)各容器間的連接進(jìn)行訪問控制。此外，由于VxLAN網(wǎng)絡(luò)流量沒有加密，需要在設(shè)定IPSec隧道參數(shù)時選擇加密以保證容器網(wǎng)絡(luò)傳輸內(nèi)容安全。

因此，無論采用何種網(wǎng)絡(luò)連接模式，都難以避免容器間互相***的安全風(fēng)險。

網(wǎng)絡(luò)DoS***

由于網(wǎng)絡(luò)虛擬化的存在，容器網(wǎng)絡(luò)面臨著與傳統(tǒng)網(wǎng)絡(luò)不同的DoS***安全風(fēng)險。Docker容器網(wǎng)絡(luò)的DoS***分為內(nèi)部威脅和外部威脅兩種主要形式。

• 內(nèi)部威脅：針對Docker容器網(wǎng)絡(luò)環(huán)境，DoS***可不通過物理網(wǎng)卡而在宿主機內(nèi)部的容器之間進(jìn)行，***者通過某個容器向其他容器發(fā)起DoS***可能降低其他容器的網(wǎng)絡(luò)數(shù)據(jù)處理能力。因此，存在容器虛擬網(wǎng)絡(luò)間的DoS***風(fēng)險。

• 外部威脅：由于同一臺宿主機上的所有容器共享宿主機的物理網(wǎng)卡資源，若外部***者使用包含大量受控主機的僵尸網(wǎng)絡(luò)向某一個目標(biāo)容器發(fā)送大量數(shù)據(jù)包進(jìn)行DDoS***，將可能占滿宿主機的網(wǎng)絡(luò)帶寬資源，造成宿主機和其他容器的拒絕服務(wù)。

Docker容器安全機制與解決方案

容器虛擬化安全

在傳統(tǒng)虛擬化技術(shù)架構(gòu)中，Hypervisor虛擬機監(jiān)視器是虛擬機資源的管理與調(diào)度模塊。而在容器架構(gòu)中，由于不含有Hypervisor層，因此需要依靠操作系統(tǒng)內(nèi)核層面的相關(guān)機制對容器進(jìn)行安全的資源管理。

容器資源隔離與限制

在資源隔離方面，與采用虛擬化技術(shù)實現(xiàn)操作系統(tǒng)內(nèi)核級隔離不同，Docker通過Linux內(nèi)核的Namespace機制實現(xiàn)容器與宿主機之間、容器與容器之間資源的相對獨立。通過為各運行容器創(chuàng)建自己的命名空間，保證了容器中進(jìn)程的運行不會影響到其他容器或宿主機中的進(jìn)程。

在資源限制方面，Docker通過CGroups實現(xiàn)宿主機中不同容器的資源限制與審計，包括對CPU、內(nèi)存、I/O等物理資源進(jìn)行均衡化配置，防止單個容器耗盡所有資源造成其他容器或宿主機的拒絕服務(wù)，保證所有容器的正常運行。

但是，CGroups未實現(xiàn)對磁盤存儲資源的限制。若宿主機中的某個容器耗盡了宿主機的所有存儲空間，那么宿主機中的其他容器無法再進(jìn)行數(shù)據(jù)寫入。Docker提供的–storage-opt=[]磁盤限額僅支持Device MApper文件系統(tǒng)，而Linux系統(tǒng)本身采用的磁盤限額機制是基于用戶和文件系統(tǒng)的quota技術(shù)，難以針對Docker容器實現(xiàn)基于進(jìn)程或目錄的磁盤限額。因此，可考慮采用以下方法實現(xiàn)容器的磁盤存儲限制：

• 為每個容器創(chuàng)建單獨用戶，限制每個用戶的磁盤使用量；

• 選擇XFS等支持針對目錄進(jìn)行磁盤使用量限制的文件系統(tǒng)；

• 為每個容器創(chuàng)建單獨的虛擬文件系統(tǒng)，具體步驟為創(chuàng)建固定大小的磁盤文件，并從該磁盤文件創(chuàng)建虛擬文件系統(tǒng)，然后將該虛擬文件系統(tǒng)掛載到指定的容器目錄。

此外，在默認(rèn)情況下，容器可以使用主機上的所有內(nèi)存?？梢允褂脙?nèi)存限制機制來防止一個容器消耗所有主機資源的拒絕服務(wù)***，具體可使用使用-m或-memory參數(shù)運行容器。

1. （命令示例： docker run [運行參數(shù)] - memory [內(nèi)存大小] [容器鏡像名或 ID ] [命令]）

容器能力限制

Linux內(nèi)核能力表示進(jìn)程所擁有的系統(tǒng)調(diào)用權(quán)限，決定了程序的系統(tǒng)調(diào)用能力。

容器的默認(rèn)能力包括CHOWN、DAC_OVERRIDE、FSETID、SETGID、SETUID、SETFCAP、NET_RAW、MKNOD、SYS_REBOOT、SYS_CHROOT、KILL、NET_BIND_SERVICE、AUDIT_WRITE等等，具體功能如表3所示。

表3：容器默認(rèn)能力

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

• 內(nèi)部因素：在運行Docker容器時，如果采用默認(rèn)的內(nèi)核功能配置可能會產(chǎn)生容器的隔離問題。

• 外部因素：不必要的內(nèi)核功能可能導(dǎo)致***者通過容器實現(xiàn)對宿主機內(nèi)核的***。

因此，不當(dāng)?shù)娜萜髂芰ε渲每赡軙U大***面，增加容器與宿主機面臨的安全風(fēng)險，在執(zhí)行docker run命令運行Docker容器時可根據(jù)實際需求通過–cap-add或–cap-drop配置接口對容器的能力進(jìn)行增刪。

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

強制訪問控制

強制訪問控制（Mandatory Access Control，MAC）是指每一個主體（包括用戶和程序）和客體都擁有固定的安全標(biāo)記，主體能否對客體進(jìn)行相關(guān)操作，取決于主體和客體所擁有安全標(biāo)記的關(guān)系。在Docker容器應(yīng)用環(huán)境下，可通過強制訪問控制機制限制容器的訪問資源。Linux內(nèi)核的強制訪問控制機制包括SELinux、AppArmor等。

1、SELinux機制

SELinux（Security-Enhanced Linux）是Linux內(nèi)核的強制訪問控制實現(xiàn)，由美國國家安全局（NSA）發(fā)起，用以限制進(jìn)程的資源訪問，即進(jìn)程僅能訪問其任務(wù)所需的文件資源。因此，可通過SELinux對Docker容器的資源訪問進(jìn)行控制。

在啟動Docker daemon守護(hù)進(jìn)程時，可通過將–selinux-enabled參數(shù)設(shè)為true，從而在Docker容器中使用SELinux。SELinux可以使經(jīng)典的shocker.c程序失效，使其無法逃逸出Docker容器實現(xiàn)對宿主機資源的訪問。

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

2、AppArmor機制

與SELinux類似，AppArmor（Application Armor，應(yīng)用程序防護(hù)）也是Linux的一種強制訪問控制機制，其作用是對可執(zhí)行程序進(jìn)行目錄和文件讀寫、網(wǎng)絡(luò)端口訪問和讀寫等權(quán)限的控制。

在Docker daemon啟動后會在/etc/apparmor.d/docker自動創(chuàng)建AppArmor的默認(rèn)配置文件docker-default，可通過在該默認(rèn)配置文件中新增訪問控制規(guī)則的方式對容器進(jìn)行權(quán)限控制，同時可在啟動容器時通過–security-opt指定其他配置文件。例如，在配置文件中加入一行deny /etc/hosts rwklx限制對/etc/hosts的獲取，同樣可使shocker.c容器逃逸***失效。

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

Seccomp機制

Seccomp（Secure Computing Mode）是Linux內(nèi)核提供的安全特性，可實現(xiàn)應(yīng)用程序的沙盒機制構(gòu)建，以白名單或黑名單的方式限制進(jìn)程能夠進(jìn)行的系統(tǒng)調(diào)用范圍。

在Docker中，可通過為每個容器編寫json格式的seccomp profile實現(xiàn)對容器中進(jìn)程系統(tǒng)調(diào)用的限制。在seccomp profile中，可定義以下行為對進(jìn)程的系統(tǒng)調(diào)用做出響應(yīng)：

• SCMP_ACT_KILL：當(dāng)進(jìn)程進(jìn)行對應(yīng)的系統(tǒng)調(diào)用時，內(nèi)核發(fā)出SIGSYS信號終止該進(jìn)程，該進(jìn)程不會接受到這個信號；

• SCMP_ACT_TRAP：當(dāng)進(jìn)程進(jìn)行對應(yīng)的系統(tǒng)調(diào)用時，該進(jìn)程會接收到SIGSYS信號，并改變自身行為；

• SCMP_ACT_ERRNO：當(dāng)進(jìn)程進(jìn)行對應(yīng)的系統(tǒng)調(diào)用時，系統(tǒng)調(diào)用失敗，進(jìn)程會接收到errno返回值；

• SCMP_ACT_TRACE： 當(dāng)進(jìn)程進(jìn)行對應(yīng)的系統(tǒng)調(diào)用時，進(jìn)程會被跟蹤；

• SCMP_ACT_ALLOW：允許進(jìn)程進(jìn)行對應(yīng)的系統(tǒng)調(diào)用行為。

默認(rèn)情況下，在Docker容器的啟動過程中會使用默認(rèn)的seccomp profile，可使用security-opt seccomp選項使用特定的seccomp profile。

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

容器安全管理

鏡像倉庫安全

1、內(nèi)容信任機制

Docker的內(nèi)容信任（Content Trust）機制可保護(hù)鏡像在鏡像倉庫與用戶之間傳輸過程中的完整性。目前，Docker的內(nèi)容信任機制默認(rèn)關(guān)閉，需要手動開啟。內(nèi)容信任機制啟用后，鏡像發(fā)布者可對鏡像進(jìn)行簽名，而鏡像使用者可以對鏡像簽名進(jìn)行驗證。

具體而言，鏡像構(gòu)建者在通過docker build命令運行Dockerfile文件前，需要通過手動或腳本方式將DOCKER_CONTENT_TRUST環(huán)境變量置為1進(jìn)行啟用。在內(nèi)容信任機制開啟后，push、build、create、pull、run等命令均與內(nèi)容信任機制綁定，只有通過內(nèi)容信任驗證的鏡像才可成功運行這些操作。例如，Dockerfile中如果包含未簽名的基礎(chǔ)鏡像，將無法成功通過docker build進(jìn)行鏡像構(gòu)建。

1. （命令示例： export DOCKER_CONTENT_TRUST = 1 ）

2、Notary項目

Notary是一個從Docker中剝離的獨立開源項目，提供數(shù)據(jù)收集的安全性。Notary用于發(fā)布內(nèi)容的安全管理，可對發(fā)布的內(nèi)容進(jìn)行數(shù)字簽名，并允許用戶驗證內(nèi)容的完整性和來源。Notary的目標(biāo)是保證服務(wù)器與客戶端之間使用可信連接進(jìn)行交互，用于解決互聯(lián)網(wǎng)內(nèi)容發(fā)布的安全性，并未局限于容器應(yīng)用。

在Docker容器場景中，Notary可支持Docker內(nèi)容信任機制。因此，可使用Notary構(gòu)建鏡像倉庫服務(wù)器，實現(xiàn)對容器鏡像的簽名，對鏡像源認(rèn)證、鏡像完整性等安全需求提供更好的支持。

鏡像安全掃描

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

針對Docker鏡像的漏洞掃描，目前已經(jīng)有許多相關(guān)工具與解決方案，包括Docker Security Scanning、Clair、Anchore、Trivy、Aqua等等。

1、Docker Security Scanning服務(wù)

Docker Security Scanning是Docker官方推出的不開源鏡像漏洞掃描服務(wù)，用于檢測Docker Cloud服務(wù)中私有倉庫和Docker Hub官方倉庫中的鏡像是否安全。

Docker Security Scanning包括掃描觸發(fā)、掃描器、數(shù)據(jù)庫、附加元件框架以及CVE漏洞數(shù)據(jù)庫比對等服務(wù)。當(dāng)倉庫中有鏡像發(fā)生更新時，會自動啟動漏洞掃描；當(dāng)CVE漏洞數(shù)據(jù)庫發(fā)生更新時，也會實時更新鏡像漏洞掃描結(jié)果。

2、Clair工具

Clair是一款開源的Docker鏡像漏洞掃描工具。與Docker Security Scanning類似，Clair通過對Docker鏡像進(jìn)行靜態(tài)分析并與公共漏洞數(shù)據(jù)庫關(guān)聯(lián)，得到相應(yīng)的漏洞分析結(jié)果。Clair主要包括以下模塊：

• Fetcher（獲取器）：從公共的CVE漏洞源收集漏洞數(shù)據(jù)；

• Detector（檢測器）：對鏡像的每一個Layer進(jìn)行掃描，提取鏡像特征；

• Notifier（通知器）：用于接收WebHook從公開CVE漏洞庫中的最新漏洞信息并進(jìn)行漏洞庫更新；

• Databases（數(shù)據(jù)庫）： PostSQL數(shù)據(jù)庫存儲容器中的各個層和CVE漏洞。

3、Trivy工具

Trivy是一個簡單而全面的開源容器漏洞掃描程序。Trivy可檢測操作系統(tǒng)軟件包（Alpine、RHEL、CentOS等）和應(yīng)用程序依賴項（Bundler、Composer、npm、yarn等）的漏洞。此外，Trivy具有較高的易用性，只需安裝二進(jìn)制文件并指定掃描容器的鏡像名稱即可執(zhí)行掃描。Trivy提供了豐富的功能接口，相比于其他容器鏡像漏洞掃描工具更適合自動化操作，可更好地滿足持續(xù)集成的需求。

1. （命令示例： trivy [鏡像名]）

容器運行時監(jiān)控

為了在系統(tǒng)運維層面保證容器運行的安全性，實現(xiàn)安全風(fēng)險的即時告警與應(yīng)急響應(yīng)，需要對Docker容器運行時的各項性能指標(biāo)進(jìn)行實時監(jiān)控。

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

1、docker stats命令

docker stats是Docker自帶的容器資源使用統(tǒng)計命令，可用于對宿主機上的Docker容器的資源使用情況進(jìn)行手動監(jiān)控，具體內(nèi)容包括容器的基本信息、容器的CPU使用率、內(nèi)存使用率、內(nèi)存使用量與限制、塊設(shè)備I/O使用量、網(wǎng)絡(luò)I/O使用量、進(jìn)程數(shù)等信息。用戶可根據(jù)自身需求設(shè)置–format參數(shù)控制docker stats 命令輸出的內(nèi)容格式。

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

2、cAdvisor工具

由于docker stats只是簡單的容器資源查看命令，其可視化程度不高，同時不支持監(jiān)控數(shù)據(jù)的存儲。cAdvisor是由Google開源的容器監(jiān)控工具，優(yōu)化了docker stats在可視化展示與數(shù)據(jù)存儲方面的缺陷。

cAdvisor在宿主機上以容器方式運行，通過掛載在本地卷，可對同一臺宿主機上運行的所有容器進(jìn)行實時監(jiān)控和性能數(shù)據(jù)采集，具體包括CPU使用情況、內(nèi)存使用情況、網(wǎng)絡(luò)吞吐量、文件系統(tǒng)使用情況等信息，并提供本地基礎(chǔ)查詢界面和API接口，方便與其他第三方工具進(jìn)行搭配使用。cAdvisor默認(rèn)將數(shù)據(jù)緩存在內(nèi)存中，同時也提供不同的持久化存儲后端支持，可將監(jiān)控數(shù)據(jù)保存Google BigQuery、InfluxDB或Redis等數(shù)據(jù)庫中。

cAdvisor基于Go語言開發(fā)，利用CGroups獲取容器的資源使用信息，目前已被集成在Kubernetes中的Kubelet組件里作為默認(rèn)啟動項。

1. （命令示例： 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守護(hù)進(jìn)程審計

在安全審計方面，對于運行Docker容器的宿主機而言，除需對主機Linux文件系統(tǒng)等進(jìn)行審計外，還需對Docker守護(hù)進(jìn)程的活動進(jìn)行審計。由于系統(tǒng)默認(rèn)不會對Docker守護(hù)進(jìn)程進(jìn)行審計，需要通過主動添加審計規(guī)則或修改規(guī)則文件進(jìn)行。

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

2、Docker相關(guān)文件目錄審計

除Docker守護(hù)進(jìn)程之外，還需對與Docker的運行相關(guān)的文件和目錄進(jìn)行審計，同樣需要通過命令行添加審計規(guī)則或修改規(guī)則配置文件，具體文件和目錄如表4所示。

表4：Docker相關(guān)文件和目錄審計

Docker公司與美國互聯(lián)網(wǎng)安全中心（CIS）聯(lián)合制定了Docker最佳安全實踐CIS Docker Benchmark，目前最新版本為1.2.0。為了幫助Docker用戶對其部署的容器環(huán)境進(jìn)行安全檢查，Docker官方提供了Docker Bench for Security安全配置檢查腳本工具docker-bench-security，其檢查依據(jù)便是CIS制定的Docker最佳安全實踐。

容器網(wǎng)絡(luò)安全

容器間流量限制

由于Docker容器默認(rèn)的網(wǎng)橋模式不會對網(wǎng)絡(luò)流量進(jìn)行控制和限制，為了防止?jié)撛诘木W(wǎng)絡(luò)DoS***風(fēng)險，需要根據(jù)實際需求對網(wǎng)絡(luò)流量進(jìn)行相應(yīng)的配置。

1、完全禁止容器間通信

在特定的應(yīng)用場景中，如果宿主機中的所有容器無需在三層或四層進(jìn)行網(wǎng)絡(luò)通信交互，可通過將Docker daemon的–icc參數(shù)設(shè)為false以禁止容器與容器間的通信。

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

2、容器間流量控制

在存在多租戶的容器云環(huán)境中，可能存在單個容器占用大量宿主機物理網(wǎng)卡搶占其他容器帶寬的情況。為了保證容器之間的正常通信，同時避免異常流量造成網(wǎng)絡(luò)DoS***等后果，需要對容器之間的通信流量進(jìn)行一定的限制。

由于Docker通過創(chuàng)建虛擬網(wǎng)卡對（eth0和veth*）將容器與虛擬網(wǎng)橋docker0連接，而容器之間的通信需要經(jīng)由虛擬網(wǎng)卡對eth0和veth*通過網(wǎng)橋連接，因此，可采用Linux的流量控制模塊traffic controller對容器網(wǎng)絡(luò)進(jìn)行流量限制。

traffic controller的原理是建立數(shù)據(jù)包隊列并制定發(fā)送規(guī)則，實現(xiàn)流量限制與調(diào)度的功能。為了在一定程度上減輕容器間的DoS***的危害，可將traffic controller的dev設(shè)置為宿主機中與各容器連接的veth*虛擬網(wǎng)卡，以此進(jìn)行宿主機上容器間流量限制。

網(wǎng)橋模式下的網(wǎng)絡(luò)訪問控制

在默認(rèn)的網(wǎng)橋連接模式中，連接在同一個網(wǎng)橋的兩個容器可以進(jìn)行直接相互訪問。因此，為了實現(xiàn)網(wǎng)絡(luò)訪問控制，可按需配置網(wǎng)絡(luò)訪問控制機制和策略。

1、為容器創(chuàng)建不同的橋接網(wǎng)絡(luò)

為了實現(xiàn)容器間的網(wǎng)絡(luò)隔離，可將容器放在不同的橋接網(wǎng)絡(luò)中。當(dāng)在Docker中使用docker network create命令創(chuàng)建新的橋接網(wǎng)絡(luò)時，會在iptables中的DOCKER-ISOLATION新增DROP丟棄規(guī)則，阻斷與其他網(wǎng)絡(luò)之間的通信流量，實現(xiàn)容器網(wǎng)絡(luò)之間隔離的目的。

1. （命令示例： docker network create -- subnet 102.102 . 0.0 / 24 test ）

2、基于白名單策略的網(wǎng)絡(luò)訪問控制

為了保證容器間的網(wǎng)絡(luò)安全，可默認(rèn)禁止容器間的通信，然后按需設(shè)置網(wǎng)絡(luò)訪問控制規(guī)則。

具體而言，在同一虛擬網(wǎng)絡(luò)內(nèi)，不同Docker容器之間的網(wǎng)絡(luò)訪問可通過iptables進(jìn)行控制。在將Docker daemon的–icc參數(shù)設(shè)為false后，iptables的FORWARD鏈策略為默認(rèn)全部丟棄。此時，可采用白名單策略實現(xiàn)網(wǎng)絡(luò)訪問控制，即根據(jù)實際需要在iptables中添加訪問控制策略，以最小化策略減小***面。

集群模式下的網(wǎng)絡(luò)訪問控制

與通過OpenStack建立的虛擬化集群通過VLAN對不同租戶進(jìn)行子網(wǎng)隔離不同，基于Overlay網(wǎng)絡(luò)的容器集群在同一主機內(nèi)相同子網(wǎng)中的不同容器之間默認(rèn)可以直接訪問。

如需控制宿主機外部到內(nèi)部容器應(yīng)用的訪問，可通過在宿主機iptables中的DOCKER-INGRESS鏈?zhǔn)謩犹砑覣CL訪問控制規(guī)則以控制宿主機的eth0到容器的訪問，或者在宿主機外部部署防火墻等方法實現(xiàn)。

然而，在大型的容器云環(huán)境中，由于存在頻繁的微服務(wù)動態(tài)變化更新，通過手動的方式配置iptables或更新防火墻是不現(xiàn)實的。因此，可通過微分段（Micro-Segmentation）實現(xiàn)面向容器云環(huán)境中的容器防火墻。微分段是一種細(xì)粒度的網(wǎng)絡(luò)分段隔離機制，與傳統(tǒng)的以網(wǎng)絡(luò)地址為基本單位的網(wǎng)絡(luò)分段機制不同，微分段可以以單個容器、同網(wǎng)段容器、容器應(yīng)用為粒度實現(xiàn)分段隔離，并通過容器防火墻對實現(xiàn)微分段間的網(wǎng)絡(luò)訪問控制。

總結(jié)

與虛擬化技術(shù)相比，Docker容器技術(shù)具有敏捷化、輕量化等特點，在推進(jìn)云原生應(yīng)用方面具有不可替代性。與此同時，容器技術(shù)對于高效性的追求也犧牲了隔離性等安全要求，在安全性方面與虛擬化技術(shù)相比還存在較大差距，且所涉及的面較廣，涉及到容器的鏡像安全、內(nèi)核安全、網(wǎng)絡(luò)安全、虛擬化安全、運行時安全等各個層面。

在應(yīng)用容器技術(shù)進(jìn)行系統(tǒng)部署時，應(yīng)充分評估安全風(fēng)險，根據(jù)應(yīng)用場景制定相應(yīng)安全需求，并整合相關(guān)安全解決方案，形成容器安全應(yīng)用最佳實踐。