李俊灝

【摘 要】伴隨著云計算的發(fā)展，Docker容器技術(shù)以其輕量級和高性能的優(yōu)勢迅速取得了廣泛的市場應(yīng)用。Docker具有共享內(nèi)核的特性，這帶來了一些安全上的問題。本文從安全隔離、資源限制、內(nèi)容信任和內(nèi)核安全防護(hù)四個維度對Docker的固有安全特性進(jìn)行了闡述，分析實(shí)際應(yīng)用過程中可能存在的七大安全風(fēng)險，并提出針對性的防護(hù)建議。

【關(guān)鍵字】虛擬化;容器;Docker;安全;風(fēng)險;威脅;安全防護(hù)

中圖分類號： TP309 文獻(xiàn)標(biāo)識碼： A 文章編號： 2095-2457（2019）20-0240-002

DOI：10.19694/j.cnki.issn2095-2457.2019.20.112

0 引言

近年來，伴隨著云計算的迅猛發(fā)展，虛擬化技術(shù)得到了廣泛的應(yīng)用，以滿足云計算環(huán)境對密集計算、靈活擴(kuò)展以及安全可靠的需求。當(dāng)前主流的虛擬化技術(shù)可以分為兩類，分別是基于虛擬機(jī)的虛擬化技術(shù)（hypervisor-based）和基于容器的虛擬化技術(shù)（container-based）。相較而言，虛擬機(jī)技術(shù)在安全隔離方面更勝一籌，而容器技術(shù)則具備輕量而高效的優(yōu)勢。

Docker開源容器項(xiàng)目在2013年一經(jīng)推出便備受矚目，短短幾年里迅速成為了容器虛擬化領(lǐng)域的主流方案。本文從安全角度出發(fā)，詳細(xì)分析了Docker本身的安全特性，并對可能存在的安全風(fēng)險提出了針對性的安全防護(hù)建議。

1 Docker概述

Docker致力于提供一整套從開發(fā)、交付到運(yùn)行的一體化應(yīng)用解決方案。Docker的成功絕非偶然，2013年Docker項(xiàng)目啟動的時候，容器技術(shù)已經(jīng)有了十余年的發(fā)展，在前輩LXC（Linux container）的基礎(chǔ)上，Docker帶來了全新的特性：提供了能夠簡單而安全的創(chuàng)建和控制容器的接口，提供了一次打包、隨處運(yùn)行的便利，實(shí)現(xiàn)了相比其它技術(shù)更高的硬件資源利用效率，以及與第三方工具配合工作以簡化管理部署流程的能力。

Docker基于CS架構(gòu)設(shè)計，主要組件包括Docker client、Docker daemon、Docker registry三部分。

Docker daemon是Docker的功能核心，它負(fù)責(zé)偵聽Docker API請求并管理Docker對象，比如鏡像（image）、容器（container）、網(wǎng)絡(luò)和卷（volume）。一個Docker daemon還可以與其它Docker daemon通信來實(shí)現(xiàn)服務(wù)管理。

Docker client是Docker為用戶提供的操作接口，可通過該接口輸入命令完成對鏡像、容器、倉庫的操作。一個Docker client可同時與多個Docker daemon進(jìn)行通信。

Docker registry用于存儲Docker鏡像。Docker Hub是一個公開的Docker registry，默認(rèn)配置下，Docker會在Docker Hub上查找所需的鏡像。通過使用Docker Datacenter（DDC）內(nèi)含的Docker Trusted Registry（DTR）組件，任何人都可以搭建私有的Docker registry。

2 Docker安全特性

2.1 安全隔離

虛擬化技術(shù)在多租戶環(huán)境下必須首先解決安全隔離的問題，Docker借助Linux內(nèi)核的namespace（命名空間）功能和Cgroups機(jī)制來實(shí)現(xiàn)安全隔離。以下從進(jìn)程、文件系統(tǒng)、設(shè)備、進(jìn)程間通信（IPC）、網(wǎng)絡(luò)等5個方面來評估Docker安全隔離的實(shí)現(xiàn)程度。

2.1.1 進(jìn)程隔離

Docker通過PID namespace來實(shí)現(xiàn)進(jìn)程隔離，從而讓運(yùn)行中的容器無法感知到運(yùn)行在其它容器或者宿主機(jī)上的進(jìn)程。PID namespace具有層次結(jié)構(gòu)，父namespace可以感知到子namespace中的進(jìn)程，反之或平級之間則不行，這就保證了宿主機(jī)系統(tǒng)進(jìn)程可以控制容器進(jìn)程，但容器進(jìn)程卻無法感知宿主機(jī)或者其它容器上的進(jìn)程。另外，容器中的進(jìn)程編號（PID）都是獨(dú)立的，這樣每個容器都可以有PID為1的類init進(jìn)程，當(dāng)發(fā)現(xiàn)異常時，只要管理員結(jié)束掉這個類init進(jìn)程，這個容器就被徹底的關(guān)閉了。

2.1.2 文件系統(tǒng)隔離

Docker通過mount namespace來實(shí)現(xiàn)容器間的文件系統(tǒng)隔離，讓各個容器以及宿主機(jī)上的文件系統(tǒng)掛載操作保持獨(dú)立且互不干擾。但需要注意的是，為了保證容器內(nèi)的正常操作，宿主機(jī)上的一些特殊目錄（例如/sys、/proc/sys、/proc/sysrq-trigger、/proc/irq以及/proc/bus等）并不受namespace限制，換句話說，容器內(nèi)可以直接訪問這些宿主機(jī)目錄。為了降低該問題導(dǎo)致的風(fēng)險，Docker做了兩點(diǎn)限制：（1）容器對這些特殊的目錄沒有寫入權(quán)限。（2）移除容器的CAP_SYS_ADMIN能力，從而使容器內(nèi)無法重新掛載這些特殊目錄。

此外，由于多個容器可以共用同一個鏡像，每個容器在運(yùn)行過程中都會生成私有的數(shù)據(jù)，為了最大化的重用資源，Docker使用了COW（寫時拷貝）技術(shù)和unionFS文件系統(tǒng)，在只讀文件系統(tǒng)上為每個容器疊加一層可寫入文件系統(tǒng)，保證不同容器的數(shù)據(jù)操作完全獨(dú)立，互不影響。

2.1.3 設(shè)備隔離

Docker利用Cgroups來控制容器可訪問的設(shè)備，并阻止容器內(nèi)的進(jìn)程創(chuàng)建新的設(shè)備節(jié)點(diǎn)。另外，Docker在掛載時使用了nodev選項(xiàng)，這樣即便在鏡像中創(chuàng)建了設(shè)備節(jié)點(diǎn)，容器中也同樣無法使用這些節(jié)點(diǎn)來與內(nèi)核通信。需要指出的是，以上均假設(shè)容器未運(yùn)行在“特權(quán)模式”下，以“特權(quán)模式”啟動的容器可以訪問所有設(shè)備。

2.1.4 進(jìn)程間通信隔離

Docker通過IPC namespace來實(shí)現(xiàn)進(jìn)程間通信隔離，不同的IPC namespace中的進(jìn)程無法互相通信，Docker為每個容器都分配了一個IPC namespace，以此來保證容器之間的進(jìn)程通信隔離。

2.1.5 網(wǎng)絡(luò)隔離

Docker通過network namespace來為每個容器分配了一塊獨(dú)立的網(wǎng)絡(luò)協(xié)議棧，使每個容器都有自己的IP地址、路由表以及網(wǎng)絡(luò)設(shè)備等。

為了實(shí)現(xiàn)容器間以及容器與宿主機(jī)間的網(wǎng)絡(luò)通信，默認(rèn)情況下Docker會在宿主機(jī)上創(chuàng)建一個虛擬以太網(wǎng)網(wǎng)橋docker0，所有容器的eth0接口均通過一定的方式與該虛擬網(wǎng)橋相連，以此來實(shí)現(xiàn)網(wǎng)絡(luò)通信。由于默認(rèn)情況下虛擬網(wǎng)橋不進(jìn)行包過濾，這會造成一定的安全風(fēng)險。

2.2 資源限制

拒絕服務(wù)（DoS）是最常見的攻擊方式之一，通過控制某些進(jìn)程去消耗系統(tǒng)的所有資源，從而破壞其他進(jìn)程的正常運(yùn)行。在容器環(huán)境下，所有容器共享內(nèi)核資源，如果未作限制，一旦某個容器被攻擊者以一定方式控制，宿主機(jī)資源將很可能被消耗殆盡。為了防范DoS，每個容器的可用資源必須受到合理的限制。

Docker借助linux的Cgroups來實(shí)現(xiàn)這種限制，以控制單個容器可用的CPU、內(nèi)存和磁盤I/O等資源，從而確保每個容器獲得公平的資源份額，并防止任何容器消耗所有資源。

2.3 內(nèi)容信任

Docker內(nèi)容信任（DCT）提供了在與遠(yuǎn)程Docker registry數(shù)據(jù)通信過程中使用數(shù)字簽名的能力，這些簽名可被用來驗(yàn)證鏡像的發(fā)行方以及數(shù)據(jù)的完整性。通過DCT，鏡像發(fā)布者可以對其鏡像進(jìn)行簽名，而鏡像使用者可以確保他們使用的鏡像已簽名。

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

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

3 安全風(fēng)險及防護(hù)建議

3.1 宿主機(jī)及內(nèi)核安全

3.1.1 風(fēng)險描述

Docker引擎及容器都運(yùn)行在宿主機(jī)上，一旦宿主機(jī)被攻破，Docker的安全便無從談起。

3.1.2 防護(hù)建議

（1）做好訪問控制及通信加密。

（2）保證系統(tǒng)和軟件（包括docker本身）能夠得到及時的更新。

（3）盡量使用最小化系統(tǒng)，比如CoreOS、Red Hat Atomic、RancherOS等。

（4）啟用強(qiáng)制訪問控制（MAC），如Seccomp、AppArmor、SELinux等。

3.2 容器逃逸

3.2.1 風(fēng)險描述

容器逃逸指的是某個Docker容器繞過了隔離檢查，訪問到了宿主機(jī)的敏感信息或者取得了宿主機(jī)的控制權(quán)限。

3.2.2 防護(hù)建議

（1）去除非必要的能力（capabilities），例如CAP_SYS_ADMIN。

（2）如無必要，不要以特權(quán)模式運(yùn)行容器，必須這樣做的情況下，要確認(rèn)鏡像來源可信。

3.3 鏡像認(rèn)證

3.3.1 風(fēng)險描述

默認(rèn)情況下，Docker并不對鏡像做認(rèn)證和校驗(yàn)，從任何渠道獲取的鏡像都可以直接運(yùn)行。如果無法保證鏡像的發(fā)布者是可信的，并且鏡像在傳遞的過程中內(nèi)容沒有被篡改，那么就存在著鏡像內(nèi)容被惡意植入的風(fēng)險。

3.3.2 防護(hù)建議

（1）不使用未經(jīng)驗(yàn)證的軟件，不使用未在信任列表中的源。

（2）強(qiáng)制使用鏡像的簽名驗(yàn)證機(jī)制。

3.4 容器資源濫用

3.4.1 風(fēng)險描述

一臺宿主機(jī)上往往會同時運(yùn)行數(shù)量龐大的容器群，雖然這是充分利用資源的一種表現(xiàn)，但同時也意味著更激烈的資源競爭。如果資源使用上不加限制，那么很容易就能夠發(fā)起一次拒絕服務(wù)（DoS）攻擊。常見的資源類型包括CPU、內(nèi)存、存儲、網(wǎng)絡(luò)帶寬、I/O帶寬、交換文件等。

3.4.2 防護(hù)建議

（1）雖然Docker默認(rèn)情況下不做資源限制，但只要按需添加命令行參數(shù)就可以做到這一點(diǎn)。試著通過一系列的測試來確定正常情況下一個容器需要的資源量范圍，并以此為標(biāo)準(zhǔn)進(jìn)行限制。

（2）如果決定暫時不做實(shí)際限制，至少應(yīng)該配置相關(guān)的監(jiān)控和告警，在資源使用量超限時第一時間得到通知。

3.5 鏡像內(nèi)漏洞

3.5.1 風(fēng)險描述

每個Docker鏡像常常被設(shè)計為實(shí)現(xiàn)某一功能的黑盒，在這種情況下如果容器運(yùn)行時功能正常，使用者往往會忽略鏡像中存在的安全問題。舉例而言，一個Apache服務(wù)器鏡像內(nèi)包含的Apache版本可能非常老舊，以至于存在大量的未修補(bǔ)漏洞，攻擊者很容易利用這些已知的漏洞對服務(wù)器發(fā)動攻擊，并有可能進(jìn)一步影響到整個容器甚至整個宿主機(jī)的安全。

3.5.2 防護(hù)建議

（1）定期為鏡像中的軟件升級安全補(bǔ)丁，然后重新編譯和發(fā)布新版本鏡像。

（2）盡量保持鏡像功能單一，如果有可能，將復(fù)雜功能的鏡像拆分為多個單一功能的鏡像。

（3）定期進(jìn)行安全掃描，并及時對掃描出的漏洞進(jìn)行修補(bǔ)。

3.6 敏感信息

3.6.1 風(fēng)險描述

在Docker容器運(yùn)行過程中，不可避免的會接收、保存和傳遞一些敏感信息，比如密鑰、憑據(jù)和證書等。如果處理不得當(dāng)?shù)脑?，非常容易造成敏感信息的泄露?/p>

3.6.2 防護(hù)建議

（1）不通過環(huán)境變量傳遞敏感信息。

（2）不將任何敏感信息保存在鏡像中。

（3）如有必要，部署一套Docker憑據(jù)管理軟件。

3.7 運(yùn)行時安全監(jiān)控

3.7.1 風(fēng)險描述

即便做到了以上說到的每一條，安全風(fēng)險仍然存在，比如攻擊者利用的是使用者自身代碼的漏洞或者0day漏洞。運(yùn)行時的安全風(fēng)險千變?nèi)f化，必須要有動態(tài)的風(fēng)險監(jiān)測機(jī)制來發(fā)現(xiàn)問題并及時處置。

3.7.2 防護(hù)建議

（1）做好運(yùn)行時安全的監(jiān)控和告警。例如借助態(tài)勢感知系統(tǒng)進(jìn)行綜合性的攻擊和入侵預(yù)判。

（2）非本地化的保存運(yùn)行日志信息，以供事后追溯分析。

4 結(jié)束語

通過對Docker固有安全特性的分析，能看到Docker的設(shè)計者為Docker創(chuàng)建了一整套的安全防護(hù)體系，能夠較好的覆蓋整個Docker應(yīng)用生命周期。當(dāng)然，默認(rèn)配置下，Docker是存在一定的安全隱患的，通過啟用鏡像簽名機(jī)制、限制容器資源使用、以非特權(quán)模式運(yùn)行容器以及啟用MAC方案等，Docker的安全能力將得到極大的提升。安全和效率在生產(chǎn)實(shí)踐中始終是一對矛盾體，如何采取有效的管理手段，將Docker環(huán)境的風(fēng)險暴露面降低到一個合理可接受的水平，這將是一個需要長期探討和研究的課題。

【參考文獻(xiàn)】

[1]謝超群.高校數(shù)據(jù)中心Docker容器應(yīng)用的安全體系設(shè)計[J].網(wǎng)絡(luò)安全技術(shù)與應(yīng)用，2019（05）：53-55.

[2]艾明振.基于Docker平臺的安全信息管理的研究與實(shí)現(xiàn)[D].北京郵電大學(xué)，2018.

[3]魯濤，陳杰，史軍.Docker安全性研究[J].計算機(jī)技術(shù)與發(fā)展，2018，28（06）：115-120.

[4]張遙，王森林.Docker安全性研究[J].網(wǎng)絡(luò)安全技術(shù)與應(yīng)用，2017（08）：32-33.

[5]胡家發(fā).Docker容器安全隔離機(jī)制研究[D].西安建筑科技大學(xué)，2017.

[6]楊文林，譚曦，郭俊廷，王碩.Docker脆弱性分析與安全增強(qiáng)[J].信息安全與技術(shù)，2016，7（04）：21-23+55.