Docker安全性研究

魯 濤，陳 杰，史 軍

(江南計(jì)算技術(shù)研究所，江蘇 無(wú)錫 214083)

0 引 言

云計(jì)算因?yàn)槟軌蛱峁╈`活的彈性服務(wù)，具備快速部署能力及便攜性特點(diǎn)而在當(dāng)今計(jì)算領(lǐng)域占據(jù)著大部分市場(chǎng)份額[1]，其中資源虛擬化技術(shù)在實(shí)現(xiàn)云計(jì)算基礎(chǔ)設(shè)施服務(wù)按需分配中起到了至關(guān)重要作用[2]。Vmware、Xen、KVM和Microsoft Hyper-v等傳統(tǒng)硬件級(jí)虛擬化由于要虛擬一個(gè)完整操作系統(tǒng)層，降低了資源利用率，對(duì)大規(guī)模的集群應(yīng)用來(lái)說(shuō)是不容忽視的缺陷。為尋求更高效的隔離化技術(shù)替代方案，Docker公司將一些現(xiàn)有技術(shù)進(jìn)行包裝整合后，于2013年3月推出了開源的容器項(xiàng)目Docker[3]。也得益于趕上了一場(chǎng)IT開發(fā)行業(yè)從SOA架構(gòu)向微服務(wù)架構(gòu)的變革[4]，Docker迅速取得了成功，廣泛應(yīng)用于各種場(chǎng)景。應(yīng)用的廣泛性使得對(duì)其安全性的研究工作也更具緊迫性和現(xiàn)實(shí)意義。

鑒于此，文中將從Docker安全的視角出發(fā)，針對(duì)性梳理了現(xiàn)階段Docker安全方面的研究成果，總結(jié)歸納了Docker面臨的安全威脅和現(xiàn)有的安全防護(hù)技術(shù)方法，為Docker安全的后續(xù)深入研究提供了有價(jià)值的參考。

1 Docker架構(gòu)及組件

Docker是基于客戶端服務(wù)器模式設(shè)計(jì)的，其主要組成可分為Docker Client、Docker Daemon、Docker Regeister三部分。Client通過(guò)tcp或unix套接字向Daemon發(fā)送請(qǐng)求命令獲取服務(wù)。Daemon運(yùn)行于宿主機(jī)中為客戶端請(qǐng)求提供服務(wù)，并在需要時(shí)向Regeister發(fā)送請(qǐng)求，進(jìn)行提取或推送鏡像等操作。Regeister主要任務(wù)是處理客戶端請(qǐng)求，進(jìn)行用戶認(rèn)證，并管理存儲(chǔ)鏡像，對(duì)請(qǐng)求服務(wù)進(jìn)行響應(yīng)。三者間的具體關(guān)系如圖1所示。

圖1 Docker主要組件間關(guān)系

Docker Daemon是常駐后臺(tái)的系統(tǒng)進(jìn)程，其主要作用是接收并處理Docker Client請(qǐng)求，管理所有Docker容器。默認(rèn)情形下，其僅監(jiān)聽本地Unix socket，這種情況下宿主機(jī)以外的客戶端將無(wú)法進(jìn)行遠(yuǎn)程訪問(wèn)，可以通過(guò)對(duì)配置文件的修改啟用tcp監(jiān)聽，對(duì)遠(yuǎn)程訪問(wèn)提供支持[6]。

Docker Regeister又稱為Docker倉(cāng)庫(kù)，其主要功能是存儲(chǔ)鏡像。根據(jù)使用范圍又可以分為私有倉(cāng)庫(kù)和公共倉(cāng)庫(kù)。私有倉(cāng)庫(kù)一般是公司或個(gè)人自己搭建的只供內(nèi)部用戶使用的倉(cāng)庫(kù)。公共倉(cāng)庫(kù)一般是指可在外網(wǎng)上提供公共服務(wù)倉(cāng)庫(kù)，用戶通過(guò)認(rèn)證后可對(duì)鏡像進(jìn)行拉取、上傳等系列操作。

2 Docker安全威脅

根據(jù)Docker不同組成部分，從網(wǎng)絡(luò)、鏡像、容器、倉(cāng)庫(kù)、Docker所依賴的Linux內(nèi)核、Docker軟件本身等六個(gè)角度逐類分析了其中存在的安全威脅。

2.1 Docker網(wǎng)絡(luò)安全威脅

Docker容器網(wǎng)絡(luò)默認(rèn)使用橋接方式進(jìn)行連接，其在宿主機(jī)上創(chuàng)建一個(gè)虛擬的網(wǎng)橋Dokcer0,它本身扮演了傳統(tǒng)交換機(jī)的角色，在各個(gè)網(wǎng)絡(luò)接口間自動(dòng)地進(jìn)行包轉(zhuǎn)發(fā)，每創(chuàng)建一個(gè)新的容器，就為其增加一個(gè)虛擬網(wǎng)絡(luò)接口，并將該網(wǎng)絡(luò)接口連接到網(wǎng)橋Docker0。默認(rèn)情況下，虛擬網(wǎng)橋并沒(méi)有對(duì)轉(zhuǎn)發(fā)的數(shù)據(jù)包進(jìn)行任何過(guò)濾，因此這種連接方式容易遭受ARP欺騙和MAC泛洪攻擊，位于同一宿主機(jī)中的容器也更易受到臨近被感染容器的網(wǎng)絡(luò)攻擊。通過(guò)docker run -p命令指定對(duì)外服務(wù)端口時(shí)，操作不當(dāng)可能致使暴露端口被映射到宿主機(jī)的每個(gè)網(wǎng)卡上監(jiān)聽外界連接，一些情況下會(huì)帶來(lái)難以預(yù)料的安全風(fēng)險(xiǎn)[7]。

2.2 Docker鏡像安全威脅

開發(fā)者在構(gòu)建鏡像時(shí)可能由于疏忽大意將包括數(shù)據(jù)庫(kù)認(rèn)證密碼在內(nèi)的敏感信息添加到鏡像中，為生產(chǎn)環(huán)境中部署的應(yīng)用埋下安全隱患；鏡像在方便進(jìn)行傳輸和便于部署的同時(shí)，也為含病毒后門的鏡像惡意傳播提供了便利。

在構(gòu)建鏡像過(guò)程中，現(xiàn)在使用的基礎(chǔ)鏡像都比較大，如基于ubuntu和Debain構(gòu)建的鏡像，由于包含與實(shí)際用途不相關(guān)的庫(kù)和依賴項(xiàng)，可能會(huì)引入額外漏洞。Rui Shu等在其《Docker Hub安全漏洞分析》一文中給出了一份詳細(xì)的統(tǒng)計(jì)數(shù)據(jù)[8]。該數(shù)據(jù)如表1所示，由數(shù)據(jù)可以看出，無(wú)論是社區(qū)鏡像或官方鏡像都有較多的漏洞。在使用鏡像前，必須要檢測(cè)鏡像中是否含有漏洞，在制作鏡像過(guò)程中要盡量減少引入不相關(guān)的依賴庫(kù)。在鏡像的漏洞掃描方面盡管有Docker Security Scanning、Clair等安全掃描軟件，但目前這些軟件仍無(wú)法給出一種通用的解決方案以識(shí)別所有類型鏡像中都安裝了哪些軟件依賴項(xiàng)。

經(jīng)Spearman相關(guān)關(guān)系檢測(cè)，SMILE組和FS-LASIK組在手術(shù)前后角膜光密度的變化量與手術(shù)前后角膜厚度、曲率、眼壓、等效球鏡的改變量無(wú)明顯相關(guān)關(guān)系。

表1 鏡像中所含漏洞數(shù)量統(tǒng)計(jì)

2.3 Docker容器安全威脅

容器運(yùn)行時(shí)有大量的狀態(tài)向量和進(jìn)程信息與操作系統(tǒng)相關(guān)聯(lián)，捕獲并轉(zhuǎn)移這些信息相比于虛擬機(jī)更難操作，所以目前還不能像虛擬機(jī)一樣支持熱遷移。而Docker這種基于Daemon為中心運(yùn)行的容器，在Daemon出現(xiàn)運(yùn)行故障或者需要升級(jí)時(shí)只能中斷運(yùn)行。這對(duì)需要保持持續(xù)運(yùn)行的業(yè)務(wù)將是災(zāi)難性的事故。

容器運(yùn)行時(shí)存在一類配置不當(dāng)引起的安全問(wèn)題。當(dāng)容器以Privileged特權(quán)運(yùn)行時(shí)，容器內(nèi)用戶能獲得宿主機(jī)絕大部分資源支配權(quán)；配置容器重啟策略時(shí)，如不限制容器重啟次數(shù)，反復(fù)的重啟可耗盡計(jì)算資源，引發(fā)拒絕服務(wù)攻擊；將敏感文件掛載到容器，可導(dǎo)致難以想象的后果，若將/var/run/目錄掛載到容器后，導(dǎo)致遠(yuǎn)程用戶可不加認(rèn)證對(duì)宿主機(jī)進(jìn)行任意訪問(wèn)的后果。

2.4 Docker倉(cāng)庫(kù)安全威脅

為確保鏡像的傳輸安全，Daemon和Registry通信過(guò)程啟用了TLS安全連接，為防止鏡像被篡改，Docker 1.8之后版本中提供了鏡像簽名和校驗(yàn)功能[9]。但這中間仍然存在一些問(wèn)題，如在本地私有網(wǎng)絡(luò)中搭建的Registry，為了便利會(huì)給Daemon配置-insecure-registry參數(shù)啟用不安全通信連接，并通過(guò)傳遞-disable-content-trust參數(shù)禁用Daemon簽名校驗(yàn)功能；在Docker Hub中有成千上萬(wàn)的開發(fā)者，每個(gè)開發(fā)者都可以利用自己的私鑰對(duì)鏡像進(jìn)行簽名，簽名校驗(yàn)機(jī)制并不能從源頭上確保開發(fā)者可信問(wèn)題[10]。

Docker Hub為方便用戶升級(jí)鏡像，實(shí)現(xiàn)了鏡像自動(dòng)構(gòu)建(automated builds)功能。該功能允許Docker Hub跟蹤指定的GitHub或BitBucket項(xiàng)目，一旦項(xiàng)目發(fā)生新提交，則自動(dòng)重新構(gòu)建鏡像，并將鏡像部署到實(shí)際生產(chǎn)環(huán)境中。在該過(guò)程中，會(huì)自動(dòng)從第三方資源平臺(tái)下載依賴項(xiàng)，而第三方資源平臺(tái)可能是不安全的鏈接，傳輸過(guò)程中依賴項(xiàng)極有可能被惡意篡改[11]，這對(duì)Docker也是一項(xiàng)不安全因素。

2.5 Linux內(nèi)核支持安全威脅

大批研究者致力于發(fā)現(xiàn)可被用來(lái)執(zhí)行任意代碼或能進(jìn)行本地提權(quán)攻擊的內(nèi)核漏洞，由此發(fā)現(xiàn)的大量?jī)?nèi)核漏洞對(duì)基于和宿主機(jī)共享內(nèi)核機(jī)制構(gòu)建的Docker容器也是非常大的威脅。另外Linux內(nèi)核層面提供的支撐技術(shù)還不完全成熟，從隔離性上來(lái)看，盡管有Namespaces提供隔離防護(hù)，但是仍有很多內(nèi)容并沒(méi)被加入其中來(lái)保證完全隔離，這其中包括偽文件系統(tǒng)、系統(tǒng)時(shí)鐘和LSMs中的一些特征等[12]。系統(tǒng)運(yùn)行所必須的關(guān)鍵目錄若沒(méi)有實(shí)現(xiàn)完全的隔離是非常危險(xiǎn)的，例如/proc、/sys下的子目錄中含有系統(tǒng)運(yùn)行的關(guān)鍵信息，直接暴露給容器會(huì)造成信息的泄露，并為惡意用戶發(fā)起攻擊創(chuàng)造了有利條件。Gao X等論述了如何利用/proc目錄中泄露的信息，選擇最佳時(shí)機(jī)，啟動(dòng)多個(gè)容器，以更小代價(jià)對(duì)數(shù)據(jù)中心發(fā)起電力攻擊[13]。

2.6 Docker軟件安全威脅

在Docker 1.10之前的版本中，Daemon在創(chuàng)建容器時(shí)需執(zhí)行很多特權(quán)操作，包括掛載文件系統(tǒng)、配置網(wǎng)絡(luò)等，必須由root用戶啟動(dòng)。這在Daemon被突破后，宿主機(jī)也將跟著淪陷[9]。雖然在新版本中，Daemon被置于新建的Docker用戶組下運(yùn)行，并利用安全可靠子進(jìn)程來(lái)代理執(zhí)行需要特權(quán)權(quán)限的操作。但在現(xiàn)實(shí)實(shí)踐中，Docker用戶組并不能很好地保證宿主機(jī)安全。

Docker Daemon對(duì)鏡像、Dockerfile文件解析過(guò)程中，如不能對(duì)這些輸入數(shù)據(jù)進(jìn)行很好的過(guò)濾，可能導(dǎo)致嚴(yán)重的安全問(wèn)題。歷史上就出現(xiàn)過(guò)通過(guò)構(gòu)造特殊Dockerfile壓縮文件，在編譯時(shí)觸發(fā)漏洞獲取執(zhí)行任意代碼權(quán)限的嚴(yán)重事件。早期版本中也出現(xiàn)過(guò)本地用戶通過(guò)在Docker Image中構(gòu)造特殊的軟鏈接進(jìn)行提權(quán)的問(wèn)題。

3 Docker安全防護(hù)

3.1 Docker安全防護(hù)支撐技術(shù)

Docker提供的隔離特性大多都是通過(guò)集成先前已有技術(shù)實(shí)現(xiàn)的，這包括NameSpaces、Cgroups(control groups)和聯(lián)合文件系統(tǒng)(UnionFS)特性等技術(shù)，這三項(xiàng)技術(shù)為Docker的安全隔離提供了基礎(chǔ)架構(gòu)支撐，具體關(guān)系如圖2所示。

圖2 Docker安全防護(hù)關(guān)鍵支撐技術(shù)

(1)NameSpaces由一組NameSpace組成，主要作用是確保處于同一NameSpaces下的進(jìn)程相互之間是可見的，不同NameSpaces的進(jìn)程之間則相互隔離。Docker環(huán)境中目前可支持六種不同的NameSpace，它們分別對(duì)系統(tǒng)資源的不同方面進(jìn)行了隔離，具體資源隔離情況如表2所示。

表2 NameSpaces資源隔離

NameSpaces提供的隔離機(jī)制為容器提供了相對(duì)安全的環(huán)境。但正如前文所提到的這種隔離并不徹底，且從今后發(fā)展看，對(duì)NameSpaces的完善工作會(huì)使內(nèi)核過(guò)于復(fù)雜，能否為L(zhǎng)inux內(nèi)核主線所接收也是未知數(shù)[14]，如何在不增加內(nèi)核冗雜性的基礎(chǔ)上提供更好的隔離方案，是一類亟需研究的安全防護(hù)問(wèn)題。

(2)Cgroups最大特點(diǎn)是可通過(guò)使用其各子系統(tǒng)對(duì)組內(nèi)進(jìn)程資源供給進(jìn)行靈活組合限制[15]，解決了多租戶容器平臺(tái)中差別化的系統(tǒng)資源分配問(wèn)題，減少了資源耗盡型Dos攻擊的攻擊面。其由很多子系統(tǒng)組成，每個(gè)子系統(tǒng)實(shí)現(xiàn)對(duì)不同類型資源的控制[16]，具體對(duì)照關(guān)系如表3所示。

表3 Cgroups子系統(tǒng)功能對(duì)照表

Cgroups存在的缺陷同樣是資源限制上不能涵蓋全部類型系統(tǒng)資源，盡管Linux提供的另外兩種資源限制機(jī)制rlimit(resource limit)和配額(quota)機(jī)制可彌補(bǔ)Cgroups的部分不足之處，但是對(duì)Cgroups的豐富和完善也是今后安全研究工作的重要方面。

(3)聯(lián)合文件系統(tǒng)是一種分層、輕量級(jí)的高性能文件系統(tǒng)，它支持對(duì)文件系統(tǒng)的修改作為一次提交并層層疊加，并將不同目錄掛載到同一個(gè)虛擬文件系統(tǒng)下為用戶提供一個(gè)統(tǒng)一的視圖[17]。

早期Docker產(chǎn)品中，鏡像構(gòu)建和容器運(yùn)行所需層級(jí)結(jié)構(gòu)、寫時(shí)復(fù)制技術(shù)都依賴于聯(lián)合文件系統(tǒng)提供的底層支持。隨著Docker的發(fā)展，后添加的Device Mapper等驅(qū)動(dòng)存儲(chǔ)雖不屬聯(lián)合文件系統(tǒng)，但也可對(duì)層級(jí)結(jié)構(gòu)、寫時(shí)復(fù)制技術(shù)提供支持，統(tǒng)稱這些驅(qū)動(dòng)存儲(chǔ)技術(shù)具有聯(lián)合文件系統(tǒng)特性。Docker的這種層級(jí)結(jié)構(gòu)和寫時(shí)復(fù)制特性確保了運(yùn)行中容器不能直接對(duì)底層鏡像文件進(jìn)行修改，保證了鏡像的穩(wěn)定性，同時(shí)建立于其上的內(nèi)容尋址保證了鏡像中的每個(gè)層級(jí)都有一個(gè)唯一的校驗(yàn)ID,從而確保鏡像的完整性[18]。

3.2 Docker內(nèi)核安全防護(hù)

確保內(nèi)核安全和利用內(nèi)核提供的安全技術(shù)進(jìn)行自身安全加強(qiáng)都是Docker安全的重要方面。Docker在這方面也做了很多整合工作，主要是通過(guò)采用能力機(jī)制(capabilities)、Seccomp(secure computing mode)安全特性、強(qiáng)制訪問(wèn)控制(mandatory access control,MAC)對(duì)容器的權(quán)能和系統(tǒng)調(diào)用進(jìn)行限制；通過(guò)利用內(nèi)核相關(guān)安全模塊Iptables、Trafic controller來(lái)加強(qiáng)自身網(wǎng)絡(luò)安全，以及通過(guò)利用內(nèi)核相關(guān)完整性保護(hù)技術(shù)確保鏡像和系統(tǒng)的完整性等；通過(guò)已有安全框架Grsecurity/PAX等對(duì)內(nèi)核進(jìn)行安全強(qiáng)化。

(1)能力機(jī)制將Linux權(quán)限進(jìn)行了更細(xì)粒度的劃分，改變了過(guò)去root用戶擁有全部特權(quán)現(xiàn)象。能力機(jī)制將特權(quán)細(xì)分為37種不同的能力[14]，涵蓋了對(duì)文件、進(jìn)程、網(wǎng)絡(luò)、系統(tǒng)、設(shè)備等各方面的操作權(quán)限。Docker默認(rèn)情況下為容器提供了有限能力權(quán)限，用戶也可根據(jù)實(shí)際需要在運(yùn)行時(shí)添加或減少能力特權(quán)。能力機(jī)制方面仍存在的問(wèn)題是，權(quán)能的劃分在一些方面仍不夠細(xì)致，不能很好地滿足對(duì)容器的限制要求，CAP-SYS-ADMIN就覆蓋了很多的特權(quán)，需要進(jìn)一步細(xì)分。為容器分配權(quán)限時(shí)，很難知道容器內(nèi)應(yīng)用需要哪些特權(quán)。為兼顧此問(wèn)題，Docker提供的默認(rèn)能力權(quán)限列表包含了較寬泛的范圍，從安全的角度考慮則并不是個(gè)好策略。

(2)Seccomp可以限制用戶進(jìn)程的系統(tǒng)調(diào)用，對(duì)系統(tǒng)調(diào)用參數(shù)進(jìn)行篩選。系統(tǒng)調(diào)用是用戶態(tài)和內(nèi)核態(tài)間最重要的接口，通過(guò)限定它可在很大程度上確保進(jìn)程在安全可控范圍內(nèi)運(yùn)行。Docker默認(rèn)基于白名單機(jī)制使用Seccomp配置文件規(guī)定允許進(jìn)行哪些系統(tǒng)調(diào)用，有50多種系統(tǒng)將會(huì)被阻止，部分系統(tǒng)調(diào)用在特定參數(shù)的情況下也會(huì)被阻止。該配置文件下，大部分容器都可正常運(yùn)行。

(3)強(qiáng)制訪問(wèn)控制相對(duì)于自主訪問(wèn)控制(discretionary access control，DAC)可提供更嚴(yán)格的保護(hù)，用戶由于不能改變他們的安全級(jí)別和對(duì)象的安全屬性，只能由MAC根據(jù)事先定義好的用戶及數(shù)據(jù)安全等級(jí)匹配結(jié)果做出客觀的具體決策，這樣就能屏蔽掉用戶主觀因素而更好地保障系統(tǒng)安全。在Linux系統(tǒng)中，強(qiáng)制訪問(wèn)控制一般會(huì)和DAC配合使用，并在LSM(linux security module)框架下實(shí)現(xiàn)具體安全模塊[19]。已經(jīng)實(shí)現(xiàn)并合并到內(nèi)核主線的安全模塊有SELinux、AppArmor、Yama、SMACK、Tomoyo，這些安全模塊都可為Docker容器提供增強(qiáng)的安全防護(hù)。各模塊間除Yama外，同時(shí)使用會(huì)存在互斥現(xiàn)象，一般會(huì)根據(jù)Linux發(fā)行版本的不同而選擇不同的安全模塊。Debain系列一般使用自帶的AppArmor,Redhat系列發(fā)行版本則選擇自帶的SELinux安全模塊。

其中SELinux的問(wèn)題主要是操作過(guò)于復(fù)雜，開發(fā)者和實(shí)際生產(chǎn)環(huán)節(jié)對(duì)啟用SELinux都持抵制態(tài)度,而且在使用上和BTRFS驅(qū)動(dòng)也不兼容。AppArmor的獨(dú)特之處在于它并不關(guān)注全系統(tǒng)的安全，只會(huì)為特別標(biāo)明進(jìn)程提供強(qiáng)制訪問(wèn)控制，其他進(jìn)程都工作在不受控制的狀態(tài)。Mattetti M等介紹了一種LiCShield安全框架用于加固Linux容器，該框架通過(guò)跟蹤分析容器運(yùn)行所需權(quán)限，有針對(duì)性地自動(dòng)生成一個(gè)AppArmor配置文件，來(lái)確保容器后續(xù)運(yùn)行的安全可控[20]。除這些安全模塊外，用戶也可根據(jù)LSM框架設(shè)計(jì)更適合自己的安全模塊，李平平等做了相關(guān)方面研究[21]。

(4)在Linux內(nèi)核中有一些網(wǎng)絡(luò)框架可用來(lái)解決Docker網(wǎng)絡(luò)安全問(wèn)題，這包括Netfilter框架和TC(tracfic controller)框架。Netfilter側(cè)重于防火墻數(shù)據(jù)過(guò)濾，而TC則側(cè)重流量帶寬控制。Docker可通過(guò)修改配置文件啟用Iptable防火墻，配置防火墻策略來(lái)控制容器間的通信[22]，可通過(guò)TC限制容器在宿主機(jī)上的虛擬網(wǎng)絡(luò)接口流量而達(dá)到限制容器帶寬的目的[18]，或者結(jié)合Cgroups子系統(tǒng)標(biāo)記網(wǎng)絡(luò)數(shù)據(jù)包，利用TC中的分類隊(duì)列限制容器的通信流量，有效防止獨(dú)占網(wǎng)絡(luò)帶寬類型拒絕服務(wù)攻擊。

(5)Linux內(nèi)核中的完整性保護(hù)相關(guān)技術(shù)可很好地應(yīng)用到Docker中，確保鏡像和容器運(yùn)行過(guò)程中的完整性。涉及到的技術(shù)包括可信計(jì)算開放標(biāo)準(zhǔn)(trusted computing group,TCG)在Linux具體實(shí)施的部分模塊及Device Mapper下實(shí)現(xiàn)完整性校驗(yàn)功能的dm-verity子模塊。這些技術(shù)都可以用來(lái)實(shí)現(xiàn)Docker鏡像的完整性保護(hù)，其中王鵑等利用TCG中的TPM做基礎(chǔ)支撐，實(shí)現(xiàn)了鏡像的完整性度量[23]，Hosseinzadeh S等也提出了兩種基于vTPM實(shí)現(xiàn)容器可信度量的方法[24]，而目前利用dm-verity來(lái)實(shí)現(xiàn)鏡像的完整性校驗(yàn)的研究則較少。

3.3 Docker數(shù)據(jù)中心安全防護(hù)

Docker數(shù)據(jù)中心產(chǎn)品中有兩個(gè)重要組成部分：DTR(Docker trusted registry)、UCP(Docker universal control plane)。為確保數(shù)據(jù)中心的安全性，它們?cè)黾恿嗽S多新的安全特性，在啟用DCT(Docker content trust)框架的情況下可很大程度上保障數(shù)據(jù)中心的安全。

(1)Docker content trust的主要功能是對(duì)從Docker registry傳送進(jìn)來(lái)的Docker鏡像進(jìn)行完整性和發(fā)布者真實(shí)性校驗(yàn)，為要推送到Docker registry中的鏡像進(jìn)行數(shù)字簽名。DCT在功能實(shí)現(xiàn)上采用了Docker notary及其封裝的TUF(the update framework)框架。在配置了Docker notary服務(wù)的Docker registry環(huán)境下，DCT還可以實(shí)現(xiàn)更為高級(jí)的功能，比如門限簽名(threshold signing)功能。

(2)Docker trusted registry是Docker容器云的核心組件，它允許企業(yè)在本地或私有云中存儲(chǔ)及管理它們的鏡像資源。相比Docker registry，除了提供更好的易用性外也增加了額外的安全特性，包括鏡像簽名、基于角色的訪問(wèn)控制(role based access control)、LDAP/AD的身份認(rèn)證機(jī)制、鏡像掃描功能[25]。

(3)和DTR相比，UCP的主要功能則是側(cè)重于本地及私有云環(huán)境中容器集群的管理和部署，而不是鏡像存儲(chǔ)。在安全方面同樣集成了基于角色的訪問(wèn)控制、LDAP/AD的身份認(rèn)證機(jī)制，除此之外，還提供了增強(qiáng)的TLS安全機(jī)制、Secrets機(jī)制及日志記錄集中管控功能。

3.4 其他相關(guān)安全防護(hù)

(1)Docker盡管在日志的可視化審計(jì)方面有比較系統(tǒng)的實(shí)施方案[7]，但在大規(guī)模日志數(shù)據(jù)深入挖掘，自動(dòng)化分析方面，仍有待進(jìn)一步研究[26]；在運(yùn)行環(huán)境審計(jì)方面，可參考Docker公司和CIS(center for Internet security)合作制定的一份安全性評(píng)估文檔，其相應(yīng)的具體評(píng)估實(shí)施工具為Docker bench for security。

(2)在針對(duì)Docker的安全威脅檢測(cè)方面，盡管可采用傳統(tǒng)基于主機(jī)的威脅檢測(cè)與基于數(shù)據(jù)流的威脅檢測(cè)技術(shù)，但如何結(jié)合Docker自身的特點(diǎn)進(jìn)行針對(duì)化應(yīng)用還有待進(jìn)一步加強(qiáng)。Abed A S等詳細(xì)介紹了如何通過(guò)檢測(cè)Docker中進(jìn)程的系統(tǒng)調(diào)用，對(duì)定義的調(diào)用頻度進(jìn)行聚類分析，識(shí)別出異常入侵行為[27]。該方法就屬于將傳統(tǒng)基于主機(jī)威脅檢測(cè)技術(shù)應(yīng)用于Docker具體環(huán)境中的一個(gè)實(shí)例。

(3)從不同的視角出發(fā)，對(duì)Docker的安全問(wèn)題進(jìn)行研究的內(nèi)容還有很多。比如，為提供更安全的容器運(yùn)行環(huán)境，先后出現(xiàn)了一批致力于改造出更適合容器運(yùn)行的精簡(jiǎn)操作系統(tǒng)項(xiàng)目，包括CoreOS、Ubuntu Core等；一些研究者則從剔除容器對(duì)宿主內(nèi)核依賴性的角度出發(fā)，提出了一種新型的更輕量級(jí)架構(gòu)方案，該方案將借助定制的內(nèi)核使應(yīng)用能夠直接在裸機(jī)上運(yùn)行，相互之間不再共享內(nèi)核系統(tǒng)，代表性的解決方案有Unikernels等；也有研究者致力于容器系統(tǒng)安全模型標(biāo)準(zhǔn)界定的研究，Catuogno對(duì)CCRA(common criteria recognition arrangement)界定的容器安全標(biāo)準(zhǔn)模型和Reshetova等提出的一種安全模型在Docker環(huán)境下進(jìn)行了對(duì)照比較，并指出了兩種安全模型實(shí)質(zhì)上的等價(jià)性[28]；Sharath N等則介紹了如何利用斯坦克爾伯格模型(Stackelberg model)通過(guò)線性規(guī)劃方法尋求一個(gè)可同時(shí)兼顧Docker安全性和確保運(yùn)行效率的最佳結(jié)合點(diǎn)[29]。

4 結(jié)束語(yǔ)

隨著容器應(yīng)用的日益普及，將有越來(lái)越多的敏感應(yīng)用遷移到容器中，在提供便利部署、高資源利用率的同時(shí)，如何加強(qiáng)容器的安全性也成為一個(gè)日益引人關(guān)注的問(wèn)題。文中首先簡(jiǎn)要介紹了Docker的主要架構(gòu)；接下來(lái)對(duì)Docker面臨的安全威脅進(jìn)行了梳理，指出了其存在的脆弱性；然后對(duì)Docker的安全防護(hù)技術(shù)進(jìn)行了歸納，匯總了現(xiàn)階段的研究方向，指出了一些亟待研究和解決的關(guān)鍵問(wèn)題。與傳統(tǒng)虛擬技術(shù)相比，Docker容器的安全性還有差距，但兩者并不是相對(duì)立的，在同樣起到虛擬隔離效果的同時(shí)也存在優(yōu)勢(shì)互補(bǔ)的作用，盡力補(bǔ)足Docker安全性上的短板將能更好地發(fā)揮其優(yōu)勢(shì)。

參考文獻(xiàn)：

[1] 王 斌.云計(jì)算IaaS體系架構(gòu)面向中小企業(yè)的商業(yè)模式研究[D].北京：北京郵電大學(xué),2014.

[2] 羅軍舟,金嘉暉,宋愛波,等.云計(jì)算:體系架構(gòu)與關(guān)鍵技術(shù)[J].通信學(xué)報(bào),2011,32(7):3-21.

[3] 李在弘,武傳海.Docker基礎(chǔ)與實(shí)戰(zhàn)[M].北京:人民郵電出版社,2016.

[4] 王 磊.微服務(wù)架構(gòu)與實(shí)踐[M].北京:電子工業(yè)出版社,2016.

[5] 孫宏亮.Docker源碼分析[M].北京:機(jī)械工業(yè)出版社,2015.

[6] 張 濤.Docker全攻略[M].北京:電子工業(yè)出版社,2016.

[7] GOASGUEN S. Docker cookbook[M]. [s.l.]:O'Reilly Media,Inc.,2015.

[8] SHU Rui,GU Xiaohui,ENCK W.A study of security vulnerabilities on Docker Hub[C]//Proceedings of the seventh ACM on conference on data and application security and privacy.Scottsdale,Arizona,USA:ACM,2017:269-280.

[9] 華為Docker實(shí)踐小組.Docker進(jìn)階與實(shí)戰(zhàn)[M].北京:機(jī)械工業(yè)出版社,2016：313-354.

[10] COMBE T,MARTIN A,PIETRO R D.Containers:vulnerability analysis[R].[s.l.]:[s.n.],2015.

[11] COMBE T,MARTIN A,PIETRO R D.To Docker or not to Docker:a security perspective[J].IEEE Cloud Computing,2016,3(5):54-62.

[12] GRATTAFIORI A.Understanding and hardening Linux containers[M].[s.l.]:NCC Group,2016.

[13] GAO Xing,GU Zhongshu,KAYAALP M,et al.ContainerLeaks:emerging security threats of information leakages in container clouds[C]//Proceedings of the 47th IEEE/IFIP international conference on dependable systems and networks.Denver,CO,USA:IEEE,2017:3-15.

[14] 李 志.Linux內(nèi)核安全模塊深入剖析[M].北京：機(jī)械工業(yè)出版社,2016.

[15] MATTHIAS K,KANE S P.Docker:up & running[M].[s.l.]:O'Reilly Media,Inc.,2015.

[16] 汪 愷,張功萱,周秀敏.基于容器虛擬化技術(shù)研究[J].計(jì)算機(jī)技術(shù)與發(fā)展,2015,25(8):138-141.

[17] 楊保華,戴王劍,曹亞侖.Docker技術(shù)入門與實(shí)戰(zhàn)[M].北京:機(jī)械工業(yè)出版社,2017.

[18] 浙江大學(xué)SEL實(shí)驗(yàn)室.Docker容器與容器云[M].北京:人民郵電出版社,2016.

[19] 劉威鵬,胡 俊,呂輝軍,等.LSM框架下可執(zhí)行程序的強(qiáng)制訪問(wèn)控制機(jī)制[J].計(jì)算機(jī)工程,2008,34(7):160-162.

[20] MATTETTI M,SHULMAN-PELEG A,ALLOUCHE Y,et al.Automatic security hardening and protection of Linux containers[C]//Workshop on security and privacy in the cloud.Florence,Italy:Curran Associates,2015.

[21] 李平平,陳莉君.基于LSM的Docker訪問(wèn)控制機(jī)制研究[J].信息技術(shù),2016,40(11):134-138.

[22] DUA R,KOHLI V,KONDURI S K.Learning Docker networking[M].[s.l.]:Packet Publishing Ltd,2016.

[23] 王 鵑,胡 威,張雨菡,等.基于Docker的可信容器[J].武漢大學(xué)學(xué)報(bào)：理學(xué)版,2017,63(2)：102-108.

[24] HOSSEINZADEH S,LAURéN S,LEPPNEN V.Security in container-based virtualization through vTPM[C]//Proceedings of the 9th international conference on utility and cloud computing.[s.l.]:[s.n.],2016:214-219.

[25] GALLAGHER S.Securing Docker[M].[s.l.]:Packet Publishing Ltd,2016.

[26] 褚瓦金.日志管理與分析權(quán)威指南[M].北京:機(jī)械工業(yè)出版社,2014.

[27] ABED A S,CLANCY C,LEVY D S.Intrusion detection system for applications using Linux containers[C]//International workshop on security and trust management.[s.l.]:[s.n.],2015:123-135.

[28] CATUOGNO L,GALDI C.On the evaluation of security properties of containerized systems[C]//International conference on ubiquitous computing and communications and 2016 international symposium on cyberspace and security.Granada,Spain:IEEE,2016:69-76.

[29] SHARATH N,KUMAR V,CHANDRASEKARAN K.Solving security issues in Docker using Stackelberg games[J].IJCTA,2016,9(16):8275-8285.