Docker安全性分析及安全防護

李俊灝

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

【關鍵字】虛擬化;容器;Docker;安全;風險;威脅;安全防護

中圖分類號： TP309 文獻標識碼： A 文章編號： 2095-2457（2019）20-0240-002

DOI：10.19694/j.cnki.issn2095-2457.2019.20.112

0 引言

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

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

1 Docker概述

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

Docker基于CS架構設計，主要組件包括Docker client、Docker daemon、Docker registry三部分。

Docker daemon是Docker的功能核心，它負責偵聽Docker API請求并管理Docker對象，比如鏡像（image）、容器（container）、網絡和卷（volume）。一個Docker daemon還可以與其它Docker daemon通信來實現服務管理。

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

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

2 Docker安全特性

2.1 安全隔離

虛擬化技術在多租戶環境下必須首先解決安全隔離的問題，Docker借助Linux內核的namespace（命名空間）功能和Cgroups機制來實現安全隔離。以下從進程、文件系統、設備、進程間通信（IPC）、網絡等5個方面來評估Docker安全隔離的實現程度。

2.1.1 進程隔離

Docker通過PID namespace來實現進程隔離，從而讓運行中的容器無法感知到運行在其它容器或者宿主機上的進程。PID namespace具有層次結構，父namespace可以感知到子namespace中的進程，反之或平級之間則不行，這就保證了宿主機系統進程可以控制容器進程，但容器進程卻無法感知宿主機或者其它容器上的進程。另外，容器中的進程編號（PID）都是獨立的，這樣每個容器都可以有PID為1的類init進程，當發現異常時，只要管理員結束掉這個類init進程，這個容器就被徹底的關閉了。

2.1.2 文件系統隔離

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

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

2.1.3 設備隔離

Docker利用Cgroups來控制容器可訪問的設備，并阻止容器內的進程創建新的設備節點。另外，Docker在掛載時使用了nodev選項，這樣即便在鏡像中創建了設備節點，容器中也同樣無法使用這些節點來與內核通信。需要指出的是，以上均假設容器未運行在“特權模式”下，以“特權模式”啟動的容器可以訪問所有設備。

2.1.4 進程間通信隔離

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

2.1.5 網絡隔離

Docker通過network namespace來為每個容器分配了一塊獨立的網絡協議棧，使每個容器都有自己的IP地址、路由表以及網絡設備等。

為了實現容器間以及容器與宿主機間的網絡通信，默認情況下Docker會在宿主機上創建一個虛擬以太網網橋docker0，所有容器的eth0接口均通過一定的方式與該虛擬網橋相連，以此來實現網絡通信。由于默認情況下虛擬網橋不進行包過濾，這會造成一定的安全風險。

2.2 資源限制

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

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

2.3 內容信任

Docker內容信任（DCT）提供了在與遠程Docker registry數據通信過程中使用數字簽名的能力，這些簽名可被用來驗證鏡像的發行方以及數據的完整性。通過DCT，鏡像發布者可以對其鏡像進行簽名，而鏡像使用者可以確保他們使用的鏡像已簽名。

2.4 內核安全防護

確保內核安全和利用內核提供的安全技術進行自身安全加強都是Docker安全的重要方面，Docker在這方面也做了很多整合工作，主要是通過采用能力機制（capabilities）、Seccomp（secure computing mode）安全特性、強制訪問控制（MAC）對容器的權能和系統調用進行限制;通過利用內核相關安全模塊Iptables、Trafic、controller來加強自身網絡安全，以及通過利用內核相關完整性保護技術確保鏡像和系統的完整性等;通過已有安全框架Grsecurity/PAX等對內核進行安全強化。

3 安全風險及防護建議

3.1 宿主機及內核安全

3.1.1 風險描述

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

3.1.2 防護建議

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

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

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

（4）啟用強制訪問控制（MAC），如Seccomp、AppArmor、SELinux等。

3.2 容器逃逸

3.2.1 風險描述

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

3.2.2 防護建議

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

（2）如無必要，不要以特權模式運行容器，必須這樣做的情況下，要確認鏡像來源可信。

3.3 鏡像認證

3.3.1 風險描述

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

3.3.2 防護建議

（1）不使用未經驗證的軟件，不使用未在信任列表中的源。

（2）強制使用鏡像的簽名驗證機制。

3.4 容器資源濫用

3.4.1 風險描述

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

3.4.2 防護建議

（1）雖然Docker默認情況下不做資源限制，但只要按需添加命令行參數就可以做到這一點。試著通過一系列的測試來確定正常情況下一個容器需要的資源量范圍，并以此為標準進行限制。

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

3.5 鏡像內漏洞

3.5.1 風險描述

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

3.5.2 防護建議

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

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

（3）定期進行安全掃描，并及時對掃描出的漏洞進行修補。

3.6 敏感信息

3.6.1 風險描述

在Docker容器運行過程中，不可避免的會接收、保存和傳遞一些敏感信息，比如密鑰、憑據和證書等。如果處理不得當的話，非常容易造成敏感信息的泄露。

3.6.2 防護建議

（1）不通過環境變量傳遞敏感信息。

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

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

3.7 運行時安全監控

3.7.1 風險描述

即便做到了以上說到的每一條，安全風險仍然存在，比如攻擊者利用的是使用者自身代碼的漏洞或者0day漏洞。運行時的安全風險千變萬化，必須要有動態的風險監測機制來發現問題并及時處置。

3.7.2 防護建議

（1）做好運行時安全的監控和告警。例如借助態勢感知系統進行綜合性的攻擊和入侵預判。

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

4 結束語

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

【參考文獻】

[1]謝超群.高校數據中心Docker容器應用的安全體系設計[J].網絡安全技術與應用，2019（05）：53-55.

[2]艾明振.基于Docker平臺的安全信息管理的研究與實現[D].北京郵電大學，2018.

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

[4]張遙，王森林.Docker安全性研究[J].網絡安全技術與應用，2017（08）：32-33.

[5]胡家發.Docker容器安全隔離機制研究[D].西安建筑科技大學，2017.

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