Docker安全性研究

魯 濤，陳 杰，史 軍

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

0 引 言

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

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

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

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

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

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

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

2 Docker安全威脅

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

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

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

2.2 Docker鏡像安全威脅

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

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

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

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

2.3 Docker容器安全威脅

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

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

2.4 Docker倉庫安全威脅

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

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

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

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

2.6 Docker軟件安全威脅

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

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

3 Docker安全防護

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

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

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

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

表2 NameSpaces資源隔離

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4 結(jié)束語

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

參考文獻：

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

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

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

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

[5] 孫宏亮.Docker源碼分析[M].北京:機械工業(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實踐小組.Docker進階與實戰(zhàn)[M].北京:機械工業(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].北京：機械工業(yè)出版社,2016.

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

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

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

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

[19] 劉威鵬,胡 俊,呂輝軍,等.LSM框架下可執(zhí)行程序的強制訪問控制機制[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訪問控制機制研究[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é)報：理學(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].北京:機械工業(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.