Docker容器安全性解決方案

1、 Docker容器安全性解決方案目 錄 TOC o 1-3 h z u HYPERLINK l _Toc60740660 一、從虛擬化安全到容器安全 PAGEREF _Toc60740660 h 3 HYPERLINK l _Toc60740661 1、傳統(tǒng)虛擬化技術(shù) PAGEREF _Toc60740661 h 3 HYPERLINK l _Toc60740662 2、容器技術(shù) PAGEREF _Toc60740662 h 3 HYPERLINK l _Toc60740663 二、Docker容器安全風(fēng)險(xiǎn)分析 PAGEREF _Toc60740663 h 7 HYPERLINK l _Toc

2、60740664 1、鏡像安全風(fēng)險(xiǎn) PAGEREF _Toc60740664 h 7 HYPERLINK l _Toc60740665 2、容器虛擬化安全風(fēng)險(xiǎn) PAGEREF _Toc60740665 h 10 HYPERLINK l _Toc60740666 3、網(wǎng)絡(luò)安全風(fēng)險(xiǎn) PAGEREF _Toc60740666 h 13 HYPERLINK l _Toc60740667 三、Docker容器安全機(jī)制與解決方案 PAGEREF _Toc60740667 h 16 HYPERLINK l _Toc60740668 1、容器虛擬化安全 PAGEREF _Toc60740668 h 16 HY

3、PERLINK l _Toc60740669 3、容器網(wǎng)絡(luò)安全 PAGEREF _Toc60740669 h 27 HYPERLINK l _Toc60740670 四、總結(jié) PAGEREF _Toc60740670 h 30Docker是目前最具代表性的容器技術(shù)之一，對(duì)云計(jì)算及虛擬化技術(shù)產(chǎn)生了顛覆性的影響。本文對(duì)Docker容器在應(yīng)用中可能面臨的安全問(wèn)題和風(fēng)險(xiǎn)進(jìn)行了研究，并將Docker容器應(yīng)用環(huán)境中的安全機(jī)制與相關(guān)解決方案分為容器虛擬化安全、容器安全管理、容器網(wǎng)絡(luò)安全三部分進(jìn)行分析。一、從虛擬化安全到容器安全1、傳統(tǒng)虛擬化技術(shù)虛擬化技術(shù)是實(shí)現(xiàn)硬件基礎(chǔ)設(shè)施資源的充分利用、合理分配和有效調(diào)度的

4、重要技術(shù)手段。例如，在基于OpenStack的典型IaaS服務(wù)中，云服務(wù)提供商可通過(guò)搭建設(shè)備集群建立資源池，并將服務(wù)器、存儲(chǔ)和網(wǎng)絡(luò)等底層資源進(jìn)行彈性虛擬化提供給租戶(hù)。傳統(tǒng)虛擬化技術(shù)以虛擬機(jī)為管理單元，各虛擬機(jī)擁有獨(dú)立的操作系統(tǒng)內(nèi)核，不共用宿主機(jī)的軟件系統(tǒng)資源，因此具有良好的隔離性，適用于云計(jì)算環(huán)境中的多租戶(hù)場(chǎng)景。2、容器技術(shù)容器技術(shù)可以看作一種輕量級(jí)的虛擬化方式，將應(yīng)用與必要的執(zhí)行環(huán)境打包成容器鏡像，使得應(yīng)用程序可以直接在宿主機(jī)（物理機(jī)或虛擬機(jī)）中相對(duì)獨(dú)立地運(yùn)行。容器技術(shù)在操作系統(tǒng)層進(jìn)行虛擬化，可在宿主機(jī)內(nèi)核上運(yùn)行多個(gè)虛擬化環(huán)境。相比于傳統(tǒng)的應(yīng)用測(cè)試與部署，容器的部署無(wú)需預(yù)先考慮應(yīng)用的運(yùn)行環(huán)境

5、兼容性問(wèn)題；相比于傳統(tǒng)虛擬機(jī)，容器無(wú)需獨(dú)立的操作系統(tǒng)內(nèi)核就可在宿主機(jī)中運(yùn)行，實(shí)現(xiàn)了更高的運(yùn)行效率與資源利用率。Docker是目前最具代表性的容器平臺(tái)之一，它模糊了傳統(tǒng)的IaaS和PaaS的邊界，具有持續(xù)部署與測(cè)試、跨云平臺(tái)支持等優(yōu)點(diǎn)。在基于Kubernetes等容器編排工具實(shí)現(xiàn)的容器云環(huán)境中，通過(guò)對(duì)跨主機(jī)集群資源的調(diào)度，容器云可提供資源共享與隔離、容器編排與部署、應(yīng)用支撐等功能。Docker容器技術(shù)以宿主機(jī)中的容器為管理單元，但各容器共用宿主機(jī)內(nèi)核資源，分別通過(guò)Linux系統(tǒng)的Namespaces和CGroups機(jī)制實(shí)現(xiàn)資源的隔離與限制。1、Namespaces為了保證容器進(jìn)程之間的資源隔離，

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

7、kCLONE_NEWNET網(wǎng)絡(luò)設(shè)備、網(wǎng)絡(luò)棧、端口等2.6.29MountCLONE_NEWNS掛載點(diǎn)（文件系統(tǒng)）2.4.19UserCLONE_NEWUSER用戶(hù)和用戶(hù)組3.8對(duì)于某個(gè)進(jìn)程而言，可通過(guò)查看/proc/PID/ns文件，獲取該進(jìn)程下的命名空間隔離情況，如圖1所示。其中，每一項(xiàng)命名空間都擁有一個(gè)編號(hào)對(duì)其進(jìn)行唯一標(biāo)識(shí)，如果宿主機(jī)中兩個(gè)進(jìn)程指向的命名空間編號(hào)相同，則表示他們同在一個(gè)命名空間之下。圖1：進(jìn)程命名空間2、CGroupsCGroups（Control Groups，控制組）機(jī)制最早于2006年由Google提出，目前是Linux內(nèi)核的一種機(jī)制，可以實(shí)現(xiàn)對(duì)任務(wù)組（進(jìn)程組或線(xiàn)程組

8、）使用的物理資源（CPU、內(nèi)存、I/O等）進(jìn)行限制和記錄，通過(guò)多種度量標(biāo)準(zhǔn)為各個(gè)容器相對(duì)公平地分配資源，以防止資源濫用的情況。在實(shí)際應(yīng)用中，CGroups會(huì)為每個(gè)執(zhí)行任務(wù)創(chuàng)建一個(gè)鉤子，在任務(wù)執(zhí)行的過(guò)程中涉及到資源分配使用時(shí)，就會(huì)觸發(fā)鉤子上的函數(shù)并對(duì)相應(yīng)的資源進(jìn)行檢測(cè)，從而對(duì)資源進(jìn)行限制和優(yōu)先級(jí)分配。CGroups提供了資源限制（Resource Limitation）、優(yōu)先級(jí)分配（Prioritization）、資源統(tǒng)計(jì)（Accounting）、任務(wù)控制（Control）四個(gè)功能，包含blkio、cpu、cpuacct、cpuset、devices、freezer、memory、perf_ev

9、ent、net_cls、net_prio、ns、hugetlb等子系統(tǒng)，每種子系統(tǒng)獨(dú)立地控制一種資源，可分別實(shí)現(xiàn)塊設(shè)備輸入/輸出限制、CPU使用控制、生成CPU資源使用情況報(bào)告、內(nèi)存使用量限制等功能。幾個(gè)主要子系統(tǒng)的具體功能如表2所示。表2：CGroups子系統(tǒng)子系統(tǒng)功能blkio為塊設(shè)備（如磁盤(pán)、固態(tài)硬盤(pán)等物理驅(qū)動(dòng)設(shè)備）設(shè)定輸入/輸出限制cpu通過(guò)調(diào)度程序控制任務(wù)對(duì)CPU的使用cpuacct生成任務(wù)對(duì)CPU資源使用情況的報(bào)告cpuset為任務(wù)分配獨(dú)立的CPU和內(nèi)存devices開(kāi)啟或關(guān)閉任務(wù)對(duì)設(shè)備的訪(fǎng)問(wèn)freezer掛起或恢復(fù)任務(wù)memory設(shè)定任務(wù)對(duì)內(nèi)存的使用量限制，生成任務(wù)對(duì)內(nèi)存資源使用

10、情況的報(bào)告3、安全性傳統(tǒng)虛擬化技術(shù)與Docker容器技術(shù)在運(yùn)行時(shí)的安全性差異主要體現(xiàn)在隔離性方面，包括進(jìn)程隔離、文件系統(tǒng)隔離、設(shè)備隔離、進(jìn)程間通信隔離、網(wǎng)絡(luò)隔離、資源限制等。在Docker容器環(huán)境中，由于各容器共享操作系統(tǒng)內(nèi)核，而容器僅為運(yùn)行在宿主機(jī)上的若干進(jìn)程，其安全性特別是隔離性與傳統(tǒng)虛擬機(jī)相比在理論上與實(shí)際上都存在一定的差距。二、Docker容器安全風(fēng)險(xiǎn)分析根據(jù)Docker容器的主要特點(diǎn)及其在安全應(yīng)用中的實(shí)際問(wèn)題，本文將Docker容器技術(shù)應(yīng)用中可能存在的技術(shù)性安全風(fēng)險(xiǎn)分為鏡像安全風(fēng)險(xiǎn)、容器虛擬化安全風(fēng)險(xiǎn)、網(wǎng)絡(luò)安全風(fēng)險(xiǎn)等類(lèi)型進(jìn)行具體分析，如圖2所示。圖2：容器安全風(fēng)險(xiǎn)分類(lèi)1、鏡像安全風(fēng)險(xiǎn)

11、Docker鏡像是Docker容器的靜態(tài)表示形式，鏡像的安全決定了容器的運(yùn)行時(shí)安全。Docker容器官方鏡像倉(cāng)庫(kù)Docker Hub中的鏡像可能由個(gè)人開(kāi)發(fā)者上傳，其數(shù)量豐富、版本多樣，但質(zhì)量參差不齊，甚至存在包含惡意漏洞的惡意鏡像，因而可能存在較大的安全風(fēng)險(xiǎn)。具體而言，Docker鏡像的安全風(fēng)險(xiǎn)分布在創(chuàng)建過(guò)程、獲取來(lái)源、獲取途徑等方方面面。1、Dockerfile安全問(wèn)題Docker鏡像的生成主要包括兩種方式，一種是對(duì)運(yùn)行中的動(dòng)態(tài)容器通過(guò)docker commit命令進(jìn)行打包，另一種是通過(guò)docker build命令執(zhí)行Dockerfile文件進(jìn)行創(chuàng)建。為了確保最小安裝原則，同時(shí)考慮容器的易維

12、護(hù)性，一般推薦采用Dockerfile文件構(gòu)建容器鏡像，即在基礎(chǔ)鏡像上進(jìn)行逐層應(yīng)用添加操作。Dockerfile是包含用于組合鏡像命令的文本文件，一般由基礎(chǔ)鏡像信息（FROM）、維護(hù)者信息（MAINTAINER）、鏡像操作指令（RUN、ADD、COPY等）、容器啟動(dòng)時(shí)執(zhí)行指令（CMD等）四個(gè)部分組成，Docker可通過(guò)讀取Dockerfile中的命令創(chuàng)建容器鏡像。Dockerfile文件內(nèi)容在一定程度上決定了Docker鏡像的安全性，其安全風(fēng)險(xiǎn)具體包括但不限于以下情況：如果Dockerfile存在漏洞或被插入惡意腳本，那么生成的容器也可能產(chǎn)生漏洞或被惡意利用。例如，攻擊者可構(gòu)造特殊的Docke

13、rfile壓縮文件，在編譯時(shí)觸發(fā)漏洞獲取執(zhí)行任意代碼的權(quán)限。如果在Dockerfile中沒(méi)有指定USER，Docker將默認(rèn)以root用戶(hù)的身份運(yùn)行該Dockerfile創(chuàng)建的容器，如果該容器遭到攻擊，那么宿主機(jī)的root訪(fǎng)問(wèn)權(quán)限也可能會(huì)被獲取。如果在Dockerfile文件中存儲(chǔ)了固定密碼等敏感信息并對(duì)外進(jìn)行發(fā)布，則可能導(dǎo)致數(shù)據(jù)泄露的風(fēng)險(xiǎn)。如果在Dockerfile的編寫(xiě)中添加了不必要的應(yīng)用，如SSH、Telnet等，則會(huì)產(chǎn)生攻擊面擴(kuò)大的風(fēng)險(xiǎn)。2、鏡像漏洞對(duì)于大多數(shù)一般的開(kāi)發(fā)者而言，通常需要獲取一系列基礎(chǔ)鏡像進(jìn)行容器云的部署和進(jìn)一步開(kāi)發(fā)，因此，基礎(chǔ)鏡像的安全性在一定程度上決定了容器云環(huán)境的安

14、全性。鏡像漏洞安全風(fēng)險(xiǎn)具體包括鏡像中的軟件含有CVE漏洞、攻擊者上傳含有惡意漏洞的鏡像等情況。 CVE漏洞由于鏡像通常由基礎(chǔ)操作系統(tǒng)與各類(lèi)應(yīng)用軟件構(gòu)成，因此，含有CVE漏洞的應(yīng)用軟件同樣也會(huì)向Docker鏡像中引入CVE漏洞。鏡像的獲取通常是通過(guò)官方鏡像倉(cāng)庫(kù)Docker Hub或網(wǎng)易、阿里云等提供的第三方鏡像倉(cāng)庫(kù)。然而，根據(jù)對(duì)Docker Hub中鏡像安全漏洞的相關(guān)研究，無(wú)論是社區(qū)鏡像還是官方鏡像，其平均漏洞數(shù)均接近200個(gè)，包括nginx、mysql、redis在內(nèi)的常用鏡像都含有高危漏洞。 惡意漏洞惡意用戶(hù)可能將含有后門(mén)、病毒等惡意漏洞的鏡像上傳至官方鏡像庫(kù)。2018年6月，安全廠商For

15、tinet和Kromtech在Docker Hub上發(fā)現(xiàn)17個(gè)包含用于數(shù)字貨幣挖礦惡意程序的Docker鏡像，而這些惡意鏡像當(dāng)時(shí)已有500萬(wàn)次的下載量。目前，由于Docker應(yīng)用在世界范圍內(nèi)具有廣泛性，全網(wǎng)針對(duì)Docker容器的攻擊很多都被用于進(jìn)行數(shù)字貨幣挖礦，為攻擊者帶來(lái)實(shí)際經(jīng)濟(jì)利益，損害Docker用戶(hù)的正常使用。3、鏡像倉(cāng)庫(kù)安全作為搭建私有鏡像存儲(chǔ)倉(cāng)庫(kù)的工具，Docker Registry的應(yīng)用安全性也必須得到保證。鏡像倉(cāng)庫(kù)的安全風(fēng)險(xiǎn)主要包括倉(cāng)庫(kù)本身的安全風(fēng)險(xiǎn)和鏡像拉取過(guò)程中的傳輸安全風(fēng)險(xiǎn)。倉(cāng)庫(kù)自身安全：如果鏡像倉(cāng)庫(kù)特別是私有鏡像倉(cāng)庫(kù)被惡意攻擊者所控制，那么其中所有鏡像的安全性將無(wú)法得到

16、保證。例如，如果私有鏡像倉(cāng)庫(kù)由于配置不當(dāng)而開(kāi)啟了2357端口，將會(huì)導(dǎo)致私有倉(cāng)庫(kù)暴露在公網(wǎng)中，攻擊者可直接訪(fǎng)問(wèn)私有倉(cāng)庫(kù)并篡改鏡像內(nèi)容，造成倉(cāng)庫(kù)內(nèi)鏡像的安全隱患。鏡像拉取安全：如何保證容器鏡像從鏡像倉(cāng)庫(kù)到用戶(hù)端的完整性也是鏡像倉(cāng)庫(kù)面臨的一個(gè)重要安全問(wèn)題。由于用戶(hù)以明文形式拉取鏡像，如果用戶(hù)在與鏡像倉(cāng)庫(kù)交互的過(guò)程中遭遇了中間人攻擊，導(dǎo)致拉取的鏡像在傳輸過(guò)程中被篡改或被冒名發(fā)布惡意鏡像，會(huì)造成鏡像倉(cāng)庫(kù)和用戶(hù)雙方的安全風(fēng)險(xiǎn)。Docker已在其1.8版本后采用內(nèi)容校驗(yàn)機(jī)制解決中間人攻擊的問(wèn)題。2、容器虛擬化安全風(fēng)險(xiǎn)與傳統(tǒng)虛擬機(jī)相比，Docker容器不擁有獨(dú)立的資源配置，且沒(méi)有做到操作系統(tǒng)內(nèi)核層面的隔離，因

17、此可能存在資源隔離不徹底與資源限制不到位所導(dǎo)致的安全風(fēng)險(xiǎn)。1、容器隔離問(wèn)題對(duì)于Docker容器而言，由于容器與宿主機(jī)共享操作系統(tǒng)內(nèi)核，因此存在容器與宿主機(jī)之間、容器與容器之間隔離方面的安全風(fēng)險(xiǎn)，具體包括進(jìn)程隔離、文件系統(tǒng)隔離、進(jìn)程間通信隔離等。雖然Docker通過(guò)Namespaces進(jìn)行了文件系統(tǒng)資源的基本隔離，但仍有/sys、/proc/sys、/proc/bus、/dev、time、syslog等重要系統(tǒng)文件目錄和命名空間信息未實(shí)現(xiàn)隔離，而是與宿主機(jī)共享相關(guān)資源。針對(duì)容器隔離安全風(fēng)險(xiǎn)問(wèn)題，主要存在以下兩種隔離失效的情況：攻擊者可能通過(guò)對(duì)宿主機(jī)內(nèi)核進(jìn)行攻擊達(dá)到攻擊其中某個(gè)容器的目的。由于容器

18、所在主機(jī)文件系統(tǒng)存在聯(lián)合掛載的情況，惡意用戶(hù)控制的容器也可能通過(guò)共同掛載的文件系統(tǒng)訪(fǎng)問(wèn)其他容器或宿主機(jī)，造成數(shù)據(jù)安全問(wèn)題。2、容器逃逸攻擊容器逃逸攻擊指的是容器利用系統(tǒng)漏洞，“逃逸”出了其自身所擁有的權(quán)限，實(shí)現(xiàn)了對(duì)宿主機(jī)和宿主機(jī)上其他容器的訪(fǎng)問(wèn)。由于容器與宿主機(jī)共享操作系統(tǒng)內(nèi)核，為了避免容器獲取宿主機(jī)的root權(quán)限，通常不允許采用特權(quán)模式運(yùn)行Docker容器。在容器逃逸案例中，最為著名的是shocker.c程序，其通過(guò)調(diào)用open_by_handle_at函數(shù)對(duì)宿主機(jī)文件系統(tǒng)進(jìn)行暴力掃描，以獲取宿主機(jī)的目標(biāo)文件內(nèi)容。由于Docker1.0之前版本對(duì)容器能力（Capability）使用黑名單策略

19、進(jìn)行管理，并沒(méi)有限制CAP_DAC_READ_SEARCH能力，賦予了shocker.c程序調(diào)用open_by_handle_at函數(shù)的能力，導(dǎo)致容器逃逸的發(fā)生。因此，對(duì)容器能力的限制不當(dāng)是可能造成容器逃逸等安全問(wèn)題的風(fēng)險(xiǎn)成因之一。所幸的是，Docker在后續(xù)版本中對(duì)容器能力采用白名單管理，避免了默認(rèn)創(chuàng)建的容器通過(guò)shocker.c案例實(shí)現(xiàn)容器逃逸的情況。此外，在Black Hat USA 2019會(huì)議中，來(lái)自Capsule8的研究員也給出了若干Docker容器引擎漏洞與容器逃逸攻擊方法，包括CVE-2019-5736、CVE-2018-18955、CVE-2016-5195等可能造成容器逃逸

20、的漏洞。CVE-2019-5736是runC的一個(gè)安全漏洞，導(dǎo)致18.09.2版本前的Docker允許惡意容器覆蓋宿主機(jī)上的runC二進(jìn)制文件。runC是用于創(chuàng)建和運(yùn)行Docker容器的CLI工具，該漏洞使攻擊者能夠以root身份在宿主機(jī)上執(zhí)行任意命令。CVE-2018-18955漏洞涉及到User命名空間中的嵌套用戶(hù)命名空間，用戶(hù)命名空間中針對(duì)uid（用戶(hù)ID）和gid（用戶(hù)組ID）的ID映射機(jī)制保證了進(jìn)程擁有的權(quán)限不會(huì)逾越其父命名空間的范疇。該漏洞利用創(chuàng)建用戶(hù)命名空間的子命名空間時(shí)損壞的ID映射實(shí)現(xiàn)提權(quán)。CVE-2016-5195臟牛（Dirty CoW）Linux內(nèi)核提權(quán)漏洞可以使低權(quán)限

21、用戶(hù)在多版本Linux系統(tǒng)上實(shí)現(xiàn)本地提權(quán)，進(jìn)而可能導(dǎo)致容器逃逸的發(fā)生。Linux內(nèi)核函數(shù)get_user_page在處理Copy-on-Write時(shí)可能產(chǎn)生競(jìng)態(tài)條件，導(dǎo)致出現(xiàn)向進(jìn)程地址空間內(nèi)只讀內(nèi)存區(qū)域?qū)憯?shù)據(jù)的機(jī)會(huì)，攻擊者可進(jìn)一步修改su或者passwd程序以獲取root權(quán)限。3、拒絕服務(wù)攻擊由于容器與宿主機(jī)共享CPU、內(nèi)存、磁盤(pán)空間等硬件資源，且Docker本身對(duì)容器使用的資源并沒(méi)有默認(rèn)限制，如果單個(gè)容器耗盡宿主機(jī)的計(jì)算資源或存儲(chǔ)資源（例如進(jìn)程數(shù)量、存儲(chǔ)空間等）可能導(dǎo)致宿主機(jī)或其他容器的拒絕服務(wù)。 計(jì)算型DoS攻擊Fork Bomb是一類(lèi)典型的針對(duì)計(jì)算資源的拒絕服務(wù)攻擊手段，其可通過(guò)遞歸方式

22、無(wú)限循環(huán)調(diào)用fork()系統(tǒng)函數(shù)快速創(chuàng)建大量進(jìn)程。由于宿主機(jī)操作系統(tǒng)內(nèi)核支持的進(jìn)程總數(shù)有限，如果某個(gè)容器遭到了Fork Bomb攻擊，那么就有可能存在由于短時(shí)間內(nèi)在該容器內(nèi)創(chuàng)建過(guò)多進(jìn)程而耗盡宿主機(jī)進(jìn)程資源的情況，宿主機(jī)及其他容器就無(wú)法再創(chuàng)建新的進(jìn)程。 存儲(chǔ)型DoS攻擊針對(duì)存儲(chǔ)資源，雖然Docker通過(guò)Mount命名空間實(shí)現(xiàn)了文件系統(tǒng)的隔離，但CGroups并沒(méi)有針對(duì)AUFS文件系統(tǒng)進(jìn)行單個(gè)容器的存儲(chǔ)資源限制，因此采用AUFS作為存儲(chǔ)驅(qū)動(dòng)具有一定的安全風(fēng)險(xiǎn)。如果宿主機(jī)上的某個(gè)容器向AUFS文件系統(tǒng)中不斷地進(jìn)行寫(xiě)文件操作，則可能會(huì)導(dǎo)致宿主機(jī)存儲(chǔ)設(shè)備空間不足，無(wú)法再滿(mǎn)足其自身及其他容器的數(shù)據(jù)存儲(chǔ)需求

23、。3、網(wǎng)絡(luò)安全風(fēng)險(xiǎn)網(wǎng)絡(luò)安全風(fēng)險(xiǎn)是互聯(lián)網(wǎng)中所有信息系統(tǒng)所面臨的重要風(fēng)險(xiǎn)，不論是物理設(shè)備還是虛擬機(jī)，都存在難以完全規(guī)避的網(wǎng)絡(luò)安全風(fēng)險(xiǎn)問(wèn)題。而在輕量級(jí)虛擬化的容器網(wǎng)絡(luò)環(huán)境中，其網(wǎng)絡(luò)安全風(fēng)險(xiǎn)較傳統(tǒng)網(wǎng)絡(luò)而言更為復(fù)雜嚴(yán)峻。1、容器網(wǎng)絡(luò)攻擊Docker提供橋接網(wǎng)絡(luò)、MacVLAN、覆蓋網(wǎng)絡(luò)（Overlay）等多種組網(wǎng)模式，可分別實(shí)現(xiàn)同一宿主機(jī)內(nèi)容器互聯(lián)、跨宿主機(jī)容器互聯(lián)、容器集群網(wǎng)絡(luò)等功能。 網(wǎng)橋模式Docker默認(rèn)采用網(wǎng)橋模式，利用iptables進(jìn)行NAT轉(zhuǎn)換和端口映射。Docker將所有容器都通過(guò)虛擬網(wǎng)絡(luò)接口對(duì)連接在一個(gè)名為docker0的虛擬網(wǎng)橋上，作為容器的默認(rèn)網(wǎng)關(guān)，而該網(wǎng)橋與宿主機(jī)直接相連。容器

24、內(nèi)部的數(shù)據(jù)包經(jīng)過(guò)虛擬網(wǎng)絡(luò)接口對(duì)到達(dá)docker0，實(shí)現(xiàn)同一子網(wǎng)內(nèi)不同容器間的通信。在網(wǎng)橋模式下，同一宿主機(jī)內(nèi)各容器間可以互相通信，而宿主機(jī)外部無(wú)法通過(guò)分配給容器的IP地址對(duì)容器進(jìn)行外部訪(fǎng)問(wèn)。由于缺乏容器間的網(wǎng)絡(luò)安全管理機(jī)制，無(wú)法對(duì)同一宿主機(jī)內(nèi)各容器之間的網(wǎng)絡(luò)訪(fǎng)問(wèn)權(quán)限進(jìn)行限制。具體而言，由于各容器之間通過(guò)宿主機(jī)內(nèi)部網(wǎng)絡(luò)的docker0網(wǎng)橋連接以實(shí)現(xiàn)路由和NAT轉(zhuǎn)換，如果容器間沒(méi)有防火墻等保護(hù)機(jī)制，則攻擊者可通過(guò)某個(gè)容器對(duì)宿主機(jī)內(nèi)的其他容器進(jìn)行ARP欺騙、嗅探、廣播風(fēng)暴等攻擊，導(dǎo)致信息泄露、影響網(wǎng)絡(luò)正常運(yùn)行等安全后果。因此，如果在同一臺(tái)宿主機(jī)上部署的多個(gè)容器沒(méi)有進(jìn)行合理的網(wǎng)絡(luò)配置進(jìn)行訪(fǎng)問(wèn)控制邊界隔

25、離，將可能產(chǎn)生容器間的網(wǎng)絡(luò)安全風(fēng)險(xiǎn)。 MacVLANMacVLAN是一種輕量級(jí)網(wǎng)絡(luò)虛擬化技術(shù)，通過(guò)與主機(jī)的網(wǎng)絡(luò)接口連接實(shí)現(xiàn)了與實(shí)體網(wǎng)絡(luò)的隔離性。MacVLAN允許為同一個(gè)物理網(wǎng)卡配置多個(gè)擁有獨(dú)立MAC地址的網(wǎng)絡(luò)接口并可分別配置IP地址，實(shí)現(xiàn)了網(wǎng)卡的虛擬化。MacVLAN模式無(wú)需創(chuàng)建網(wǎng)橋，即無(wú)需NAT轉(zhuǎn)換和端口映射就可以直接通過(guò)網(wǎng)絡(luò)接口連接到物理網(wǎng)絡(luò)，不同MacVLAN網(wǎng)絡(luò)間不能在二層網(wǎng)絡(luò)上進(jìn)行通信。然而，處于同一虛擬網(wǎng)絡(luò)下各容器間同樣沒(méi)有進(jìn)行訪(fǎng)問(wèn)權(quán)限控制，因此MacVLAN模式依然存在與網(wǎng)橋模式類(lèi)似的內(nèi)部網(wǎng)絡(luò)攻擊的安全風(fēng)險(xiǎn)。 Overlay網(wǎng)絡(luò)Overlay網(wǎng)絡(luò)架構(gòu)主要用于構(gòu)建分布式容器集群，

26、通過(guò)VxLAN技術(shù)在不同主機(jī)之間的Underlay網(wǎng)絡(luò)上建立虛擬網(wǎng)絡(luò)，以搭建跨主機(jī)容器集群，實(shí)現(xiàn)不同物理主機(jī)中同一Overlay網(wǎng)絡(luò)下的容器間通信。與其他組網(wǎng)模式一樣，Overlay網(wǎng)絡(luò)也沒(méi)有對(duì)同一網(wǎng)絡(luò)內(nèi)各容器間的連接進(jìn)行訪(fǎng)問(wèn)控制。此外，由于VxLAN網(wǎng)絡(luò)流量沒(méi)有加密，需要在設(shè)定IPSec隧道參數(shù)時(shí)選擇加密以保證容器網(wǎng)絡(luò)傳輸內(nèi)容安全。因此，無(wú)論采用何種網(wǎng)絡(luò)連接模式，都難以避免容器間互相攻擊的安全風(fēng)險(xiǎn)。2、網(wǎng)絡(luò)DoS攻擊由于網(wǎng)絡(luò)虛擬化的存在，容器網(wǎng)絡(luò)面臨著與傳統(tǒng)網(wǎng)絡(luò)不同的DoS攻擊安全風(fēng)險(xiǎn)。Docker容器網(wǎng)絡(luò)的DoS攻擊分為內(nèi)部威脅和外部威脅兩種主要形式。內(nèi)部威脅：針對(duì)Docker容器網(wǎng)絡(luò)環(huán)境

27、，DoS攻擊可不通過(guò)物理網(wǎng)卡而在宿主機(jī)內(nèi)部的容器之間進(jìn)行，攻擊者通過(guò)某個(gè)容器向其他容器發(fā)起DoS攻擊可能降低其他容器的網(wǎng)絡(luò)數(shù)據(jù)處理能力。因此，存在容器虛擬網(wǎng)絡(luò)間的DoS攻擊風(fēng)險(xiǎn)。外部威脅：由于同一臺(tái)宿主機(jī)上的所有容器共享宿主機(jī)的物理網(wǎng)卡資源，若外部攻擊者使用包含大量受控主機(jī)的僵尸網(wǎng)絡(luò)向某一個(gè)目標(biāo)容器發(fā)送大量數(shù)據(jù)包進(jìn)行DDoS攻擊，將可能占滿(mǎn)宿主機(jī)的網(wǎng)絡(luò)帶寬資源，造成宿主機(jī)和其他容器的拒絕服務(wù)。三、Docker容器安全機(jī)制與解決方案1、容器虛擬化安全在傳統(tǒng)虛擬化技術(shù)架構(gòu)中，Hypervisor虛擬機(jī)監(jiān)視器是虛擬機(jī)資源的管理與調(diào)度模塊。而在容器架構(gòu)中，由于不含有Hypervisor層，因此需要依靠

28、操作系統(tǒng)內(nèi)核層面的相關(guān)機(jī)制對(duì)容器進(jìn)行安全的資源管理。1、容器資源隔離與限制在資源隔離方面，與采用虛擬化技術(shù)實(shí)現(xiàn)操作系統(tǒng)內(nèi)核級(jí)隔離不同，Docker通過(guò)Linux內(nèi)核的Namespace機(jī)制實(shí)現(xiàn)容器與宿主機(jī)之間、容器與容器之間資源的相對(duì)獨(dú)立。通過(guò)為各運(yùn)行容器創(chuàng)建自己的命名空間，保證了容器中進(jìn)程的運(yùn)行不會(huì)影響到其他容器或宿主機(jī)中的進(jìn)程。在資源限制方面，Docker通過(guò)CGroups實(shí)現(xiàn)宿主機(jī)中不同容器的資源限制與審計(jì)，包括對(duì)CPU、內(nèi)存、I/O等物理資源進(jìn)行均衡化配置，防止單個(gè)容器耗盡所有資源造成其他容器或宿主機(jī)的拒絕服務(wù)，保證所有容器的正常運(yùn)行。但是，CGroups未實(shí)現(xiàn)對(duì)磁盤(pán)存儲(chǔ)資源的限制。若

29、宿主機(jī)中的某個(gè)容器耗盡了宿主機(jī)的所有存儲(chǔ)空間，那么宿主機(jī)中的其他容器無(wú)法再進(jìn)行數(shù)據(jù)寫(xiě)入。Docker提供的storage-opt=磁盤(pán)限額僅支持Device Mapper文件系統(tǒng)，而Linux系統(tǒng)本身采用的磁盤(pán)限額機(jī)制是基于用戶(hù)和文件系統(tǒng)的quota技術(shù)，難以針對(duì)Docker容器實(shí)現(xiàn)基于進(jìn)程或目錄的磁盤(pán)限額。因此，可考慮采用以下方法實(shí)現(xiàn)容器的磁盤(pán)存儲(chǔ)限制：為每個(gè)容器創(chuàng)建單獨(dú)用戶(hù)，限制每個(gè)用戶(hù)的磁盤(pán)使用量；選擇XFS等支持針對(duì)目錄進(jìn)行磁盤(pán)使用量限制的文件系統(tǒng)；為每個(gè)容器創(chuàng)建單獨(dú)的虛擬文件系統(tǒng)，具體步驟為創(chuàng)建固定大小的磁盤(pán)文件，并從該磁盤(pán)文件創(chuàng)建虛擬文件系統(tǒng)，然后將該虛擬文件系統(tǒng)掛載到指定的容器目

30、錄。此外，在默認(rèn)情況下，容器可以使用主機(jī)上的所有內(nèi)存?？梢允褂脙?nèi)存限制機(jī)制來(lái)防止一個(gè)容器消耗所有主機(jī)資源的拒絕服務(wù)攻擊，具體可使用使用-m或-memory參數(shù)運(yùn)行容器。（命令示例：dockerrun運(yùn)行參數(shù)-memory內(nèi)存大小容器鏡像名或ID命令）2、容器能力限制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等等，具

31、體功能如表3所示。表3：容器默認(rèn)能力容器默認(rèn)能力作用CHOWN允許任意更改文件UID以及GIDDAC_OVERRIDE允許忽略文件的讀、寫(xiě)、執(zhí)行訪(fǎng)問(wèn)權(quán)限檢查FSETID允許文件修改后保留setuid/setgid標(biāo)志位SETGID允許改變進(jìn)程組IDSETUID允許改變進(jìn)程用戶(hù)IDSETFCAP允許向其他進(jìn)程轉(zhuǎn)移或刪除能力NET_RAW允許創(chuàng)建RAW和PACKET套接字MKNOD允許使用mknod創(chuàng)建指定文件SYS_REBOOT允許使用reboot或者kexec_loadSYS_CHROOT允許使用chrootKILL允許發(fā)送信號(hào)NET_BIND_SERVICE允許綁定常用端口號(hào)（端口號(hào)小于10

32、24）AUDIT_WRITE允許審計(jì)日志寫(xiě)入如果對(duì)容器能力不加以適當(dāng)限制，可能會(huì)存在以下安全隱患：內(nèi)部因素：在運(yùn)行Docker容器時(shí)，如果采用默認(rèn)的內(nèi)核功能配置可能會(huì)產(chǎn)生容器的隔離問(wèn)題。外部因素：不必要的內(nèi)核功能可能導(dǎo)致攻擊者通過(guò)容器實(shí)現(xiàn)對(duì)宿主機(jī)內(nèi)核的攻擊。因此，不當(dāng)?shù)娜萜髂芰ε渲每赡軙?huì)擴(kuò)大攻擊面，增加容器與宿主機(jī)面臨的安全風(fēng)險(xiǎn)，在執(zhí)行docker run命令運(yùn)行Docker容器時(shí)可根據(jù)實(shí)際需求通過(guò)cap-add或cap-drop配置接口對(duì)容器的能力進(jìn)行增刪。（命令示例：docker run -cap-drop ALL -cap-add SYS_TIME ntpd /bin/sh）3、強(qiáng)制訪(fǎng)問(wèn)

33、控制強(qiáng)制訪(fǎng)問(wèn)控制（Mandatory Access Control, MAC）是指每一個(gè)主體（包括用戶(hù)和程序）和客體都擁有固定的安全標(biāo)記，主體能否對(duì)客體進(jìn)行相關(guān)操作，取決于主體和客體所擁有安全標(biāo)記的關(guān)系。在Docker容器應(yīng)用環(huán)境下，可通過(guò)強(qiáng)制訪(fǎng)問(wèn)控制機(jī)制限制容器的訪(fǎng)問(wèn)資源。Linux內(nèi)核的強(qiáng)制訪(fǎng)問(wèn)控制機(jī)制包括SELinux、AppArmor等。 SELinux機(jī)制SELinux（Security-Enhanced Linux）是Linux內(nèi)核的強(qiáng)制訪(fǎng)問(wèn)控制實(shí)現(xiàn)，由美國(guó)國(guó)家安全局（NSA）發(fā)起，用以限制進(jìn)程的資源訪(fǎng)問(wèn)，即進(jìn)程僅能訪(fǎng)問(wèn)其任務(wù)所需的文件資源。因此，可通過(guò)SELinux對(duì)Docker

34、容器的資源訪(fǎng)問(wèn)進(jìn)行控制。在啟動(dòng)Docker daemon守護(hù)進(jìn)程時(shí)，可通過(guò)將selinux-enabled參數(shù)設(shè)為true，從而在Docker容器中使用SELinux。SELinux可以使經(jīng)典的shocker.c程序失效，使其無(wú)法逃逸出Docker容器實(shí)現(xiàn)對(duì)宿主機(jī)資源的訪(fǎng)問(wèn)。（命令示例：docker daemon -selinux-enabled = true） AppArmor機(jī)制與SELinux類(lèi)似，AppArmor（Application Armor，應(yīng)用程序防護(hù)）也是Linux的一種強(qiáng)制訪(fǎng)問(wèn)控制機(jī)制，其作用是對(duì)可執(zhí)行程序進(jìn)行目錄和文件讀寫(xiě)、網(wǎng)絡(luò)端口訪(fǎng)問(wèn)和讀寫(xiě)等權(quán)限的控制。在Docker

35、 daemon啟動(dòng)后會(huì)在/etc/apparmor.d/docker自動(dòng)創(chuàng)建AppArmor的默認(rèn)配置文件docker-default，可通過(guò)在該默認(rèn)配置文件中新增訪(fǎng)問(wèn)控制規(guī)則的方式對(duì)容器進(jìn)行權(quán)限控制，同時(shí)可在啟動(dòng)容器時(shí)通過(guò)security-opt指定其他配置文件。例如，在配置文件中加入一行deny /etc/hosts rwklx限制對(duì)/etc/hosts的獲取，同樣可使shocker.c容器逃逸攻擊失效。（命令示例：docker run -rm -ti -cap-add=all -security-opt apparmor:docker-default shocker bash）4、Sec

36、comp機(jī)制Seccomp（Secure Computing Mode）是Linux內(nèi)核提供的安全特性，可實(shí)現(xiàn)應(yīng)用程序的沙盒機(jī)制構(gòu)建，以白名單或黑名單的方式限制進(jìn)程能夠進(jìn)行的系統(tǒng)調(diào)用范圍。在Docker中，可通過(guò)為每個(gè)容器編寫(xiě)json格式的seccomp profile實(shí)現(xiàn)對(duì)容器中進(jìn)程系統(tǒng)調(diào)用的限制。在seccomp profile中，可定義以下行為對(duì)進(jìn)程的系統(tǒng)調(diào)用做出響應(yīng)：SCMP_ACT_KILL：當(dāng)進(jìn)程進(jìn)行對(duì)應(yīng)的系統(tǒng)調(diào)用時(shí)，內(nèi)核發(fā)出SIGSYS信號(hào)終止該進(jìn)程，該進(jìn)程不會(huì)接受到這個(gè)信號(hào)；SCMP_ACT_TRAP：當(dāng)進(jìn)程進(jìn)行對(duì)應(yīng)的系統(tǒng)調(diào)用時(shí)，該進(jìn)程會(huì)接收到SIGSYS信號(hào)，并改變自身行為；

37、SCMP_ACT_ERRNO：當(dāng)進(jìn)程進(jìn)行對(duì)應(yīng)的系統(tǒng)調(diào)用時(shí)，系統(tǒng)調(diào)用失敗，進(jìn)程會(huì)接收到errno返回值；SCMP_ACT_TRACE：當(dāng)進(jìn)程進(jìn)行對(duì)應(yīng)的系統(tǒng)調(diào)用時(shí)，進(jìn)程會(huì)被跟蹤；SCMP_ACT_ALLOW：允許進(jìn)程進(jìn)行對(duì)應(yīng)的系統(tǒng)調(diào)用行為。默認(rèn)情況下，在Docker容器的啟動(dòng)過(guò)程中會(huì)使用默認(rèn)的seccomp profile，可使用security-opt seccomp選項(xiàng)使用特定的seccomp profile。（命令示例：docker run -rm -it -security-opt seccomp:/path/to/seccomp/profile.jsonhello-world）2、容器安

38、全管理1、鏡像倉(cāng)庫(kù)安全 內(nèi)容信任機(jī)制Docker的內(nèi)容信任（Content Trust）機(jī)制可保護(hù)鏡像在鏡像倉(cāng)庫(kù)與用戶(hù)之間傳輸過(guò)程中的完整性。目前，Docker的內(nèi)容信任機(jī)制默認(rèn)關(guān)閉，需要手動(dòng)開(kāi)啟。內(nèi)容信任機(jī)制啟用后，鏡像發(fā)布者可對(duì)鏡像進(jìn)行簽名，而鏡像使用者可以對(duì)鏡像簽名進(jìn)行驗(yàn)證。具體而言，鏡像構(gòu)建者在通過(guò)docker build命令運(yùn)行Dockerfile文件前，需要通過(guò)手動(dòng)或腳本方式將DOCKER_CONTENT_TRUST環(huán)境變量置為1進(jìn)行啟用。在內(nèi)容信任機(jī)制開(kāi)啟后，push、build、create、pull、run等命令均與內(nèi)容信任機(jī)制綁定，只有通過(guò)內(nèi)容信任驗(yàn)證的鏡像才可成功運(yùn)行這些

39、操作。例如，Dockerfile中如果包含未簽名的基礎(chǔ)鏡像，將無(wú)法成功通過(guò)docker build進(jìn)行鏡像構(gòu)建。（命令示例：export DOCKER_CONTENT_TRUST = 1） Notary項(xiàng)目Notary是一個(gè)從Docker中剝離的獨(dú)立開(kāi)源項(xiàng)目，提供數(shù)據(jù)收集的安全性。Notary用于發(fā)布內(nèi)容的安全管理，可對(duì)發(fā)布的內(nèi)容進(jìn)行數(shù)字簽名，并允許用戶(hù)驗(yàn)證內(nèi)容的完整性和來(lái)源。Notary的目標(biāo)是保證服務(wù)器與客戶(hù)端之間使用可信連接進(jìn)行交互，用于解決互聯(lián)網(wǎng)內(nèi)容發(fā)布的安全性，并未局限于容器應(yīng)用。在Docker容器場(chǎng)景中，Notary可支持Docker內(nèi)容信任機(jī)制。因此，可使用Notary構(gòu)建鏡像倉(cāng)

40、庫(kù)服務(wù)器，實(shí)現(xiàn)對(duì)容器鏡像的簽名，對(duì)鏡像源認(rèn)證、鏡像完整性等安全需求提供更好的支持。2、鏡像安全掃描為了保證容器運(yùn)行的安全性，在從公共鏡像倉(cāng)庫(kù)獲取鏡像時(shí)需要對(duì)鏡像進(jìn)行安全檢查，防止存在安全隱患甚至惡意漏洞的鏡像運(yùn)行，從源頭端預(yù)防安全事故的發(fā)生。鏡像漏洞掃描工具是一類(lèi)常用的鏡像安全檢查輔助工具，可檢測(cè)出容器鏡像中含有的CVE漏洞。針對(duì)Docker鏡像的漏洞掃描，目前已經(jīng)有許多相關(guān)工具與解決方案，包括Docker Security Scanning、Clair、Anchore、Trivy、Aqua等等。 Docker Security Scanning服務(wù)Docker Security Scanni

41、ng是Docker官方推出的不開(kāi)源鏡像漏洞掃描服務(wù)，用于檢測(cè)Docker Cloud服務(wù)中私有倉(cāng)庫(kù)和Docker Hub官方倉(cāng)庫(kù)中的鏡像是否安全。Docker Security Scanning包括掃描觸發(fā)、掃描器、數(shù)據(jù)庫(kù)、附加元件框架以及CVE漏洞數(shù)據(jù)庫(kù)比對(duì)等服務(wù)。當(dāng)倉(cāng)庫(kù)中有鏡像發(fā)生更新時(shí)，會(huì)自動(dòng)啟動(dòng)漏洞掃描；當(dāng)CVE漏洞數(shù)據(jù)庫(kù)發(fā)生更新時(shí)，也會(huì)實(shí)時(shí)更新鏡像漏洞掃描結(jié)果。 Clair工具Clair是一款開(kāi)源的Docker鏡像漏洞掃描工具。與Docker Security Scanning類(lèi)似，Clair通過(guò)對(duì)Docker鏡像進(jìn)行靜態(tài)分析并與公共漏洞數(shù)據(jù)庫(kù)關(guān)聯(lián)，得到相應(yīng)的漏洞分析結(jié)果。Clair

42、主要包括以下模塊：Fetcher（獲取器）：從公共的CVE漏洞源收集漏洞數(shù)據(jù)；Detector（檢測(cè)器）：對(duì)鏡像的每一個(gè)Layer進(jìn)行掃描，提取鏡像特征；Notifier（通知器）：用于接收WebHook從公開(kāi)CVE漏洞庫(kù)中的最新漏洞信息并進(jìn)行漏洞庫(kù)更新；Databases（數(shù)據(jù)庫(kù)）：PostSQL數(shù)據(jù)庫(kù)存儲(chǔ)容器中的各個(gè)層和CVE漏洞； Trivy工具Trivy是一個(gè)簡(jiǎn)單而全面的開(kāi)源容器漏洞掃描程序。Trivy可檢測(cè)操作系統(tǒng)軟件包（Alpine、RHEL、CentOS等）和應(yīng)用程序依賴(lài)項(xiàng)（Bundler、Composer、npm、yarn等）的漏洞。此外，Trivy具有較高的易用性，只需安裝二

43、進(jìn)制文件并指定掃描容器的鏡像名稱(chēng)即可執(zhí)行掃描。Trivy提供了豐富的功能接口，相比于其他容器鏡像漏洞掃描工具更適合自動(dòng)化操作，可更好地滿(mǎn)足持續(xù)集成的需求。（命令示例：trivy 鏡像名）3、容器運(yùn)行時(shí)監(jiān)控為了在系統(tǒng)運(yùn)維層面保證容器運(yùn)行的安全性，實(shí)現(xiàn)安全風(fēng)險(xiǎn)的即時(shí)告警與應(yīng)急響應(yīng)，需要對(duì)Docker容器運(yùn)行時(shí)的各項(xiàng)性能指標(biāo)進(jìn)行實(shí)時(shí)監(jiān)控。針對(duì)Docker容器監(jiān)控的工具與解決方案包括docker stats、cAdvisor、Scout、DataDog、Sensu等等，其中最常見(jiàn)的是Docker原生的docker stats命令和Google的cAdvisor開(kāi)源工具。 docker stats命令d

44、ocker stats是Docker自帶的容器資源使用統(tǒng)計(jì)命令，可用于對(duì)宿主機(jī)上的Docker容器的資源使用情況進(jìn)行手動(dòng)監(jiān)控，具體內(nèi)容包括容器的基本信息、容器的CPU使用率、內(nèi)存使用率、內(nèi)存使用量與限制、塊設(shè)備I/O使用量、網(wǎng)絡(luò)I/O使用量、進(jìn)程數(shù)等信息。用戶(hù)可根據(jù)自身需求設(shè)置format參數(shù)控制docker stats 命令輸出的內(nèi)容格式。（命令示例：docker stats 容器名） cAdvisor工具由于docker stats只是簡(jiǎn)單的容器資源查看命令，其可視化程度不高，同時(shí)不支持監(jiān)控?cái)?shù)據(jù)的存儲(chǔ)。cAdvisor是由Google開(kāi)源的容器監(jiān)控工具，優(yōu)化了docker stats在可視

45、化展示與數(shù)據(jù)存儲(chǔ)方面的缺陷。cAdvisor在宿主機(jī)上以容器方式運(yùn)行，通過(guò)掛載在本地卷，可對(duì)同一臺(tái)宿主機(jī)上運(yùn)行的所有容器進(jìn)行實(shí)時(shí)監(jiān)控和性能數(shù)據(jù)采集，具體包括CPU使用情況、內(nèi)存使用情況、網(wǎng)絡(luò)吞吐量、文件系統(tǒng)使用情況等信息，并提供本地基礎(chǔ)查詢(xún)界面和API接口，方便與其他第三方工具進(jìn)行搭配使用。cAdvisor默認(rèn)將數(shù)據(jù)緩存在內(nèi)存中，同時(shí)也提供不同的持久化存儲(chǔ)后端支持，可將監(jiān)控?cái)?shù)據(jù)保存Google BigQuery、InfluxDB或Redis等數(shù)據(jù)庫(kù)中。cAdvisor基于Go語(yǔ)言開(kāi)發(fā)，利用CGroups獲取容器的資源使用信息，目前已被集成在Kubernetes中的Kubelet組件里作為默認(rèn)啟

46、動(dòng)項(xiàng)。（命令示例：docker run -v /var/run:/var/run:rw-v/sys:/sys:ro-v/var/lib/docker:/var/lib/docker:ro-p8080:8080-d-namecadvisorgoogle/cadvisor）4、容器安全審計(jì) Docker守護(hù)進(jìn)程審計(jì)在安全審計(jì)方面，對(duì)于運(yùn)行Docker容器的宿主機(jī)而言，除需對(duì)主機(jī)Linux文件系統(tǒng)等進(jìn)行審計(jì)外，還需對(duì)Docker守護(hù)進(jìn)程的活動(dòng)進(jìn)行審計(jì)。由于系統(tǒng)默認(rèn)不會(huì)對(duì)Docker守護(hù)進(jìn)程進(jìn)行審計(jì)，需要通過(guò)主動(dòng)添加審計(jì)規(guī)則或修改規(guī)則文件進(jìn)行。（命令示例：auditctl -w /usr/bin/do

47、cker -k docker或修改/etc/audit/audit.rules文件） Docker相關(guān)文件目錄審計(jì)除Docker守護(hù)進(jìn)程之外，還需對(duì)與Docker的運(yùn)行相關(guān)的文件和目錄進(jìn)行審計(jì)，同樣需要通過(guò)命令行添加審計(jì)規(guī)則或修改規(guī)則配置文件，具體文件和目錄如表4所示。表4：Docker相關(guān)文件和目錄審計(jì)需要審計(jì)的文件或目錄備注/var/lib/docker包含有關(guān)容器的所有信息/etc/docker包含Docker守護(hù)進(jìn)程和客戶(hù)端TLS通信的密鑰和證書(shū)docker.serviceDocker守護(hù)進(jìn)程運(yùn)行參數(shù)配置文件docker.socket守護(hù)進(jìn)程運(yùn)行socket/etc/default/d

48、ocker支持Docker守護(hù)進(jìn)程各種參數(shù)/etc/default/daemon.json支持Docker守護(hù)進(jìn)程各種參數(shù)/usr/bin/docker-containerdDocker可用containerd生成容器/usr/bin/docker-runcDocker可用runC生成容器Docker公司與美國(guó)互聯(lián)網(wǎng)安全中心（CIS）聯(lián)合制定了Docker最佳安全實(shí)踐CIS Docker Benchmark，目前最新版本為1.2.0。為了幫助Docker用戶(hù)對(duì)其部署的容器環(huán)境進(jìn)行安全檢查，Docker官方提供了Docker Bench for Security安全配置檢查腳本工具docker-bench-security，其檢查依據(jù)便是CIS制定的Docker最佳安全實(shí)踐。3、容器網(wǎng)絡(luò)安全1、容器間流量限制由于Docker容器默認(rèn)的網(wǎng)橋模式不會(huì)對(duì)網(wǎng)絡(luò)流量進(jìn)行控制和限制，為了防止?jié)撛诘木W(wǎng)絡(luò)DoS攻擊風(fēng)險(xiǎn)，需要根據(jù)實(shí)際需求對(duì)網(wǎng)絡(luò)流量進(jìn)行相應(yīng)的配置