導(dǎo)讀

?近年來(lái)，容器憑借能在任意環(huán)境中運(yùn)行、開(kāi)銷低、秒級(jí)啟動(dòng)、鏡像占用小等優(yōu)勢(shì)，越來(lái)越受世界各種行業(yè)追捧。例如Google從Gmail到Y(jié)ouTube和Google搜索，幾乎所有產(chǎn)品都在容器中運(yùn)行，每個(gè)星期都要啟動(dòng)超過(guò)20億個(gè)容器；京東構(gòu)建了全球最大的容器集群，其內(nèi)部99%都做了容器化，當(dāng)前已有20萬(wàn)的容器集群規(guī)模，保證了京東618和雙11大促銷。

但容器早期發(fā)展主要考慮易用性和功能實(shí)現(xiàn)，對(duì)安全考慮不是很充分，存在方方面面的安全隱患。隨著容器化的重要性與日俱增，容器安全的重要性也在不斷提高。作為一項(xiàng)依然處于發(fā)展階段的新技術(shù)，容器的安全性在不斷地提高，也在不斷地受到挑戰(zhàn)。在其面臨的所有安全問(wèn)題當(dāng)中，逃逸問(wèn)題穩(wěn)居首位——它直接影響到了承載容器的底層基礎(chǔ)設(shè)施的機(jī)密性、完整性和可用性，危害了底層宿主機(jī)和整個(gè)云計(jì)算系統(tǒng)的安全。本文針對(duì)容器逃逸技術(shù)做全面的講解。

1、容器安全風(fēng)險(xiǎn)

在容器時(shí)代，安全面臨新舊威脅的雙重挑戰(zhàn)。一方面，傳統(tǒng)的攻擊手段依然有效，如注入漏洞、暴力破解、權(quán)限提升等。另一方面，新的攻擊方式層出不窮，包括容器逃逸、投毒鏡像、集群管理漏洞等，讓人防不勝防。

1.1 容器作為輕量的虛擬化技術(shù)面臨的主要安全風(fēng)險(xiǎn)

圖1 虛擬機(jī) vs 容器

從圖中可以看出：

• 容器沒(méi)有hypervisor，安全性強(qiáng)依賴于Host OS內(nèi)核，受內(nèi)核漏洞影響；
  
  
• 容器技術(shù)在OS層面實(shí)現(xiàn)了對(duì)計(jì)算機(jī)系統(tǒng)的虛擬化，在操作系統(tǒng)中，通過(guò)namespace技術(shù)對(duì)CPU、內(nèi)存和文件系統(tǒng)等資源進(jìn)行隔離、劃分和控制，實(shí)現(xiàn)進(jìn)程之間透明的資源使用，其安全性與內(nèi)核隔離技術(shù)的成熟度強(qiáng)相關(guān);
  
  
• 要從虛擬機(jī)攻破到宿主機(jī)或其他虛擬機(jī)，需要先攻破Hypervisor層，這是極其困難的。而docker容器與宿主機(jī)共享內(nèi)核、文件系統(tǒng)等資源，更有可能對(duì)其他容器、宿主機(jī)產(chǎn)生影響。容器的隔離層次更少，攻擊路徑更短，攻擊面更大，危及整個(gè)系統(tǒng)的安全。

1.2 從容器生命周期看容器的關(guān)鍵安全風(fēng)險(xiǎn)

圖2 Docker容器典型使用流程

Docker作為容器引擎的代表，從它的使用流程可以看出，容器安全風(fēng)險(xiǎn)貫徹容器構(gòu)建、部署、運(yùn)行整個(gè)生命周期。例如，在構(gòu)建階段，可能會(huì)遇到的軟件供應(yīng)鏈攻擊，包括基礎(chǔ)鏡像污染、CI工具攻擊、制品庫(kù)漏洞攻擊等。在部署階段也可能面臨針對(duì)云原生基礎(chǔ)設(shè)施平臺(tái)攻擊，包括開(kāi)源組件編排工具、安全合規(guī)檢查等。在運(yùn)行時(shí)階段，還可能面臨針對(duì)云原生應(yīng)用的攻擊，包括逃逸攻擊、安全隔離、注入漏洞、弱口令等。

容器的生命周期短，動(dòng)態(tài)變化快，超過(guò)50%容器從上線到下架的整個(gè)生命周期不超過(guò)1天。快速檢測(cè)和響應(yīng)容器入侵事件，把損失降到最低，成為了一大安全難題。

1.3 歷年容器安全漏洞情況表明，容器逃逸占比最高、影響較大

在容器集群中，若攻陷一個(gè)容器，就可以橫向移動(dòng)到其它容器上，或者逃逸到node節(jié)點(diǎn)上進(jìn)行持久化，控制整個(gè)節(jié)點(diǎn)。下一步，攻擊者還可以通過(guò)漏洞利用或者調(diào)用API SERVER控制整個(gè)集群。容器的攻擊價(jià)值高，儼然成為攻擊者眼中“香餑餑”。

從下圖的歷年容器安全問(wèn)題分布及容器運(yùn)行時(shí)入侵事件統(tǒng)計(jì)分布可以看出，容器逃逸是用戶最關(guān)注的安全問(wèn)題，同時(shí)也是業(yè)務(wù)場(chǎng)景中遇到最多的安全問(wèn)題。

圖3 容器安全問(wèn)題分布

圖4 2021年容器運(yùn)行時(shí)入侵事件統(tǒng)計(jì)分布

2、容器逃逸技術(shù)及原理

容器逃逸，是指“流氓”容器嘗試突破正常隔離環(huán)境限制，借助一些手段獲得容器所在的直接宿主機(jī)、宿主機(jī)上的其他容器或集群內(nèi)其他主機(jī)、其他容器的某種權(quán)限下的命令執(zhí)行能力，進(jìn)行惡意攻擊或執(zhí)行越權(quán)訪問(wèn)的行為。如下圖所示，容器逃逸漏洞可能打穿容器節(jié)點(diǎn)，甚至整個(gè)集群。

圖5 從攻擊方視角看容器逃逸攻擊路徑

容器逃逸的前提是已經(jīng)獲得了容器內(nèi)某種權(quán)限下的命令執(zhí)行能力，然后捅破隔離。容器的隔離技術(shù)不是新發(fā)明的，它借助Linux資源隔離的核心技術(shù)namespace來(lái)實(shí)現(xiàn)。

圖6 應(yīng)用層容器逃逸原理分析

從圖6可以得知，Linux內(nèi)核先天性隔離性不足，盡管目前namespace已經(jīng)提供了非常多的資源隔離類型如PID、mount、network、UTS、IPC、user等，但除namespace外其它內(nèi)核資源并未隔離或隔離不充分，其中包括一些系統(tǒng)的關(guān)鍵性目錄（如/sys、/proc等），這些關(guān)鍵性的目錄可能會(huì)泄露主機(jī)上一些關(guān)鍵信息，讓攻擊者利用這些信息對(duì)宿主機(jī)發(fā)起攻擊，使得容器逃逸到宿主機(jī)。

特權(quán)模式在6.0版本的時(shí)候被引入Docker，其核心作用是允許容器內(nèi)的root擁有宿主機(jī)的root權(quán)限。使用特權(quán)模式啟動(dòng)容器后（docker run --privileged），Docker容器被允許訪問(wèn)宿主機(jī)上的所有設(shè)備、可以獲取大量設(shè)備文件的訪問(wèn)權(quán)限、可以執(zhí)行mount命令進(jìn)行掛載。當(dāng)Docker管理員可通過(guò)mount命令將宿主機(jī)磁盤設(shè)備掛載進(jìn)容器內(nèi)部，即可獲取對(duì)整個(gè)宿主機(jī)的文件讀寫權(quán)限，也可以通過(guò)寫入計(jì)劃任務(wù)等方式在宿主機(jī)執(zhí)行命令，成功逃逸。

Linux內(nèi)核自版本2.2引入了Capabilities機(jī)制，將傳統(tǒng)的root用戶的特權(quán)劃分為30+個(gè)不同的單元，進(jìn)行精細(xì)化管理。但如果Capabilities設(shè)置不正確，就會(huì)讓攻擊者有機(jī)可乘，實(shí)現(xiàn)權(quán)限提升。例如當(dāng)容器以--cap-add=SYSADMIN啟動(dòng)，Container進(jìn)程就被允許執(zhí)行mount、umount等一系列系統(tǒng)管理命令，如果攻擊者此時(shí)再將外部設(shè)備目錄掛載在容器中就會(huì)發(fā)生Docker逃逸。可見(jiàn)，capabilities控制不當(dāng)同樣會(huì)引入容器逃逸，當(dāng)前業(yè)界已識(shí)別SYSADMIN、DAC_READ_SEARCH、SYS_MODULE、SYS_PTRACE引入了逃逸漏洞。

3、基于業(yè)務(wù)的容器逃逸場(chǎng)景分析

基于大量業(yè)界容器安全CVE漏洞的研究，對(duì)產(chǎn)品業(yè)務(wù)場(chǎng)景中運(yùn)行態(tài)的容器安全薄弱環(huán)節(jié)進(jìn)行了分類，識(shí)別出容器逃逸主要分布在應(yīng)用層、服務(wù)層和系統(tǒng)層。

圖7 在產(chǎn)品業(yè)務(wù)場(chǎng)景中識(shí)別的容器逃逸問(wèn)題

應(yīng)用層的逃逸，主要體現(xiàn)在特權(quán)模式與配置不當(dāng)，如利用特權(quán)模式逃逸、借助Capability逃逸。為了方便容器與宿主機(jī)進(jìn)行數(shù)據(jù)交換，幾乎所有主流的解決方案都會(huì)提供掛載宿主機(jī)目錄到容器的功能，由此而來(lái)的容器逃逸問(wèn)題也呈上升趨勢(shì)，當(dāng)容器以讀寫形式掛載宿主機(jī)上的敏感文件或目錄如docker.sock、主機(jī)procfs時(shí)，從容器中逃逸出去易如反掌，手段也多種多樣。

除了應(yīng)用本身的脆弱性引入的攻擊外，服務(wù)層集群、容器運(yùn)行時(shí)本身的脆弱性問(wèn)題也不容忽視。例如攻擊者借助k8s的8080、6443未授權(quán)訪問(wèn)，可通過(guò)容器訪問(wèn)K8S master api進(jìn)行惡意調(diào)用；參與到容器生態(tài)中的服務(wù)端、客戶端程序自身存在的漏洞如runc、Containerd組件漏洞，同樣可被容器利用從而獲取宿主機(jī)的控制權(quán)。

此外，從系統(tǒng)層面來(lái)看，Docker直接共享宿主機(jī)的內(nèi)核，所以當(dāng)宿主機(jī)內(nèi)核存在安全漏洞時(shí)會(huì)一并影響Docker的安全，導(dǎo)致可能會(huì)造成Docker逃逸。例如著名的臟牛漏洞CVE-2016-5195是Linux內(nèi)核中的權(quán)限提升漏洞，通過(guò)它可實(shí)現(xiàn)Docker容器逃逸，獲得root權(quán)限的shell。

4、解決容器逃逸的方案

4.1 Docker自身安全性改進(jìn)

容器發(fā)展早期，容器內(nèi)的root等同于宿主機(jī)上的root，若容器被攻破或容器本身存在惡意程序時(shí)，在容器內(nèi)就可以獲取到宿主機(jī)的root權(quán)限。Docker 1.10版本，引入U(xiǎn)ser Namespace技術(shù)進(jìn)行用戶隔離，可將容器內(nèi)的root用戶映射到宿主機(jī)上的非root用戶，大大減輕了容器逃逸的風(fēng)險(xiǎn)。容器社區(qū)持續(xù)在努力將縱深防御、最小權(quán)限等理念和原則落地，因此建議盡可能使用最新版Docker。且使用最新版本docker，已知的CVE漏洞都已修復(fù)，如更新Docker版本到19.03.1及更高版本，不再受CVE-2019-14271、CVE-2019-5736等漏洞影響。

4.2 安全配置及掛載

應(yīng)用層大多容器相關(guān)漏洞，均由不安全配置或掛載引入。無(wú)論是細(xì)粒度權(quán)限控制還是其他安全機(jī)制，用戶都可以通過(guò)修改容器環(huán)境配置或在運(yùn)行容器時(shí)指定參數(shù)來(lái)調(diào)整。建議docker容器或k8s pod啟動(dòng)時(shí)，做到：

• 不以root權(quán)限運(yùn)行Docker服務(wù)；
• 不將宿主機(jī)敏感目錄掛載至容器目錄；
• 不開(kāi)啟特權(quán)模式，如需添加相應(yīng)的權(quán)限可以使用-cap-add參數(shù);
• 不將容器以-cap-add=SYSADMIN、-cap-add=DAC_READ_SEARCH、-cap-add=SYS_MODULE、-cap-add=SYS_PTRACE等高Capabilities啟動(dòng)。如攻擊者借助容器的CAP_DAC_READ_SEARCH權(quán)限，采用著名的Shocker攻擊方式，可在容器內(nèi)逃逸讀取到host的/etc/shadow文件。

4.3 加強(qiáng)內(nèi)核安全和管理

盡量安裝最新補(bǔ)丁的主機(jī)內(nèi)核版本，如Linux內(nèi)核版本>=2.6.22解決了CVE-2016-5195(臟牛)，Linux內(nèi)核版本>=4.14解決了CVE-2017–1000405(大臟牛)。

4.4 使用安全加固組件

Linux的SELinux、AppArmor、GRSecurity組件都是Docker官方推薦的安全加固組件，這三個(gè)組件可以限制容器對(duì)主機(jī)的內(nèi)核或其他資源的訪問(wèn)控制權(quán)限。下面說(shuō)明下這些安全加固組件：

• SELinux：是Linux的一個(gè)內(nèi)核安全模塊，提供了安全訪問(wèn)的策略機(jī)制，通過(guò)設(shè)置SELinux策略可以指定如何嚴(yán)格或?qū)捤傻剡M(jìn)行檢查，實(shí)現(xiàn)某些進(jìn)程允許訪問(wèn)某些文件;
• AppArmor：類似于SELinux，也是一個(gè)Linux的內(nèi)核安全模塊，普通的訪問(wèn)控制僅能控制到用戶的訪問(wèn)權(quán)限，而AppArmor可以控制到用戶程序的訪問(wèn)權(quán)限，也能識(shí)別0day漏洞和未知的應(yīng)用程序漏洞所導(dǎo)致的攻擊;
• GRSecurity：是一個(gè)對(duì)內(nèi)核的安全擴(kuò)展，可通過(guò)智能訪問(wèn)控制，提供內(nèi)存破壞防御，文件系統(tǒng)增強(qiáng)等多種防御形式。它提供了一些工具讓用戶配置、使用這些安全特性。

4.5 使用安全容器

容器有著輕便快速啟動(dòng)的優(yōu)點(diǎn)，虛擬機(jī)有著安全隔離的優(yōu)點(diǎn)，安全容器可以兼顧兩者的優(yōu)點(diǎn)，做到既輕量又安全。

安全容器與普通容器的主要區(qū)別在于，安全容器中的每個(gè)容器都運(yùn)行在一個(gè)單獨(dú)的微型虛擬機(jī)中，擁有獨(dú)立的操作系統(tǒng)和內(nèi)核，并且有虛擬機(jī)般的安全隔離性。

安全容器目前推薦的主流技術(shù)方案是Kata Containers，它并不包含一個(gè)完整的操作系統(tǒng)，只有一個(gè)精簡(jiǎn)版的Guest Kernel運(yùn)行著容器本身的應(yīng)用，可以通過(guò)使用共享內(nèi)存來(lái)進(jìn)一步減少內(nèi)存的開(kāi)銷。另外，它還實(shí)現(xiàn)了OCI規(guī)范，可以直接使用Docker的鏡像啟動(dòng)Kata容器，具有開(kāi)銷更小、秒級(jí)啟動(dòng)、安全隔離等許多優(yōu)點(diǎn)。

圖8 普通容器與安全容器對(duì)比

5、后記

正如前文所述，容器已經(jīng)成為黑客的重點(diǎn)攻擊目標(biāo)，而應(yīng)用層的容器逃逸漏洞占比最高。容器在應(yīng)用層的安全很大程度上取決于其配置的安全性，我們?cè)跇I(yè)務(wù)場(chǎng)景中尤為重要的就是Capabilities的賦予，一定要做到權(quán)限最小化，丟棄沒(méi)有用到的特權(quán)。借助Capabilities逃逸只是冰山一角，還有大量逃逸場(chǎng)景待進(jìn)一步研究。盡管有些Capabilities當(dāng)前還沒(méi)有被惡意利用，但無(wú)法確保后續(xù)不會(huì)成為攻擊者逃逸的手段，因此務(wù)必做到維持業(yè)務(wù)必須的最小權(quán)限。

權(quán)限過(guò)多，難免疏忽。權(quán)限最小化的同時(shí)也要參考業(yè)界最佳實(shí)踐：?jiǎn)⒂胾ser namespace進(jìn)行用戶隔離并且以非root運(yùn)行，這就好比使用預(yù)編譯語(yǔ)句防御SQL注入，從根源上防御，切斷所有的攻擊路徑，盡管這個(gè)方案可能對(duì)現(xiàn)有業(yè)務(wù)部署方案有大量的改動(dòng)，但仍然應(yīng)該成為容器防御的最終目標(biāo)之一。

當(dāng)前Docker的隔離性還遠(yuǎn)達(dá)不到虛擬機(jī)的水平，應(yīng)該避免把Docker容器當(dāng)成虛擬機(jī)來(lái)使用，除非在虛擬機(jī)里部署容器，否則建議Docker容器里只跑可信應(yīng)用。