【摘   要】 隨著容器技術(shù)的快速發(fā)展和廣泛應(yīng)用，其面臨的安全問題也越來越突出。本文在分析開源容器技術(shù)典型代表Docker和Kubernetes應(yīng)用過程中面臨的安全問題及挑戰(zhàn)的基礎(chǔ)上，提出應(yīng)對建議。

【關(guān)鍵詞】 容器技術(shù) Docker Kubernetes 容器安全

1 引言

高德納（Gartner）預(yù)測，到2023年，70%的組織將在生產(chǎn)中運(yùn)行3個或更多容器化應(yīng)用程序。容器、容器編排技術(shù)（Kubernetes，K8S）和微服務(wù)應(yīng)用模式是企業(yè)IT創(chuàng)新和數(shù)字化轉(zhuǎn)型的三大驅(qū)動力，很多公司已經(jīng)采用這些技術(shù)，發(fā)揮其在應(yīng)用程序開發(fā)和部署方面的優(yōu)勢。隨著容器技術(shù)的快速發(fā)展和廣泛應(yīng)用，其面臨的安全問題也越來越突出。本文在分析開源容器技術(shù)典型代表Docker和K8S應(yīng)用過程中面臨的安全問題及挑戰(zhàn)的基礎(chǔ)上，提出應(yīng)對建議。

2 開源容器技術(shù)發(fā)展應(yīng)用分析

相比于系統(tǒng)級虛擬化，容器技術(shù)是進(jìn)程級別的，具有啟動快、體積小等優(yōu)勢，為軟件開發(fā)、應(yīng)用部署帶來了諸多便利。如使用開源容器Docker技術(shù)，應(yīng)用程序打包推送到鏡像中心后，使用時拉取直接運(yùn)行，實現(xiàn)了“一次打包，到處運(yùn)行”，非常方便、快捷；使用開源容器編排技術(shù)K8S能夠?qū)崿F(xiàn)應(yīng)用程序的彈性擴(kuò)容和自動化部署，滿足企業(yè)靈活擴(kuò)展信息系統(tǒng)的需求。但是，隨著Docker和K8S應(yīng)用的日益廣泛和深入，安全問題也越來越凸顯。

2.1 容器技術(shù)發(fā)展迅速且應(yīng)用廣泛

2013年，Docker公司提出Docker開源容器項目，隨后發(fā)布了一系列工具鏈來支持容器使用；到2020年，Docker容器官方鏡像倉庫Docker Hub的鏡像中心累計下載了1300億次，用戶創(chuàng)建了約600萬個容器鏡像庫。Docker開源技術(shù)能實現(xiàn)對容器的治理和編排，已成為容器管理領(lǐng)域事實上的行業(yè)標(biāo)準(zhǔn)。根據(jù)云原生計算基金會于2020年3月發(fā)布的最新調(diào)查，在亞馬遜公司云計算平臺（Amazon Web Services，AWS）和谷歌公司云平臺（Google Cloud Platform，GCP）的托管服務(wù)中，K8S的生產(chǎn)使用率從58%躍升至78%。

2.2 開源技術(shù)推動了容器技術(shù)發(fā)展

Docker技術(shù)和K8S技術(shù)之所以能夠快速發(fā)展和廣泛應(yīng)用，除了技術(shù)本身的優(yōu)勢之外，重要的原因就是由于開源社區(qū)管理和支持。開源社區(qū)具有限制少、交付快捷、迭代快速、參與人員多、大公司支持等優(yōu)勢，大大促進(jìn)了容器技術(shù)的演進(jìn)。開源容器技術(shù)生態(tài)體系日趨完善，已貫穿現(xiàn)代化軟件工程的整個生命周期，其復(fù)雜度也在不斷提升。

2.3 基于容器技術(shù)的敏捷開發(fā)模式日趨流行

在移動應(yīng)用、互聯(lián)網(wǎng)背景下，企業(yè)競爭日趨激烈，應(yīng)用程序快速迭代、持續(xù)交付顯得尤為重要。容器技術(shù)的應(yīng)用大大推動了軟件交付模式的革新，基于容器的敏捷開發(fā)模式DevOps（開發(fā)運(yùn)維一體化）大大提高了軟件的交付速度、部署頻率。常見的DevOps流程，包括拉取代碼、代碼構(gòu)建、項目打包、Docker構(gòu)建、拉取鏡像和Docker運(yùn)行6個步驟，通過多種工具的集成，構(gòu)成了自動化DevOps開發(fā)運(yùn)維流水線，開發(fā)人員提交的代碼能夠自動部署到生產(chǎn)環(huán)境，如圖1所示。

DevOps生命周期是以下各項工作的反復(fù)迭代：計劃、編碼、構(gòu)建、測試、發(fā)布、部署、運(yùn)維、監(jiān)控。從開發(fā)人員提交代碼開始，直到在生產(chǎn)環(huán)境中運(yùn)行，形成自動流水線過程；一旦運(yùn)行，就反復(fù)迭代、循環(huán)運(yùn)行。任一環(huán)節(jié)出現(xiàn)安全問題，就會影響開發(fā)、交付，同時也增加了安全控制的復(fù)雜度和難度。

基于容器技術(shù)的DevOps各個階段都可能存在安全漏洞，應(yīng)該實施安全控制措施，如構(gòu)建時安全、基礎(chǔ)鏡像的安全、Docker基礎(chǔ)設(shè)施安全、運(yùn)行時安全等，要加強(qiáng)容器鏡像掃描、容器編排

配置錯誤控制、網(wǎng)絡(luò)身份訪問管理、檢測和事件響應(yīng)等。

3 開源容器技術(shù)面臨的安全挑戰(zhàn)分析

2020年，Prevasio公司發(fā)布Docker容器官方鏡像倉庫Docker Hub分析報告：通過對400萬容器鏡像的掃描發(fā)現(xiàn)51%的鏡像存在高危漏洞，6432個鏡像包含病毒或惡意程序。

Docker容器技術(shù)應(yīng)用中可能存在的技術(shù)性安全風(fēng)險分為鏡像安全風(fēng)險、容器虛擬化安全風(fēng)險、網(wǎng)絡(luò)安全風(fēng)險等類型。

Docker Hub中的鏡像可由個人開發(fā)者上傳，其數(shù)量豐富、版本多樣，但質(zhì)量參差不齊，甚至存在包含惡意漏洞的惡意鏡像，因而可能存在較大的安全風(fēng)險。具體而言，Docker鏡像的安全風(fēng)險分布在創(chuàng)建過程、獲取來源、獲取途徑等方方面面。

與傳統(tǒng)虛擬機(jī)相比，Docker容器不擁有獨(dú)立的資源配置，且沒有做到操作系統(tǒng)內(nèi)核層面的隔離，因此可能存在資源隔離不徹底與資源限制不到位所導(dǎo)致的容器虛擬化安全風(fēng)險。

網(wǎng)絡(luò)安全風(fēng)險是互聯(lián)網(wǎng)中所有信息系統(tǒng)所面臨的重要風(fēng)險，不論是物理設(shè)備還是虛擬機(jī)，都存在難以完全規(guī)避的網(wǎng)絡(luò)安全風(fēng)險問題。而在輕量級虛擬化的容器網(wǎng)絡(luò)和容器編排環(huán)境中，其網(wǎng)絡(luò)安全風(fēng)險較傳統(tǒng)網(wǎng)絡(luò)而言更為復(fù)雜嚴(yán)峻。

3.1 開源容器技術(shù)Docker面臨的安全隱患

Docker的安全問題主要可能來源于3個方面。

3.1.1 Docker自身漏洞

Docker作為一款軟件，自然也跟軟件一樣，技術(shù)實現(xiàn)上會有代碼缺陷。MITRE公司共發(fā)布了134項Docker安全漏洞（截至2020年12月28日）。 編號CVE-2020-35467的安全漏洞顯示，2020年12月14日之前的Docker Docs映像包含根用戶的空白密碼。使用受影響的Docker Docs容器版本部署的系統(tǒng)可能允許遠(yuǎn)程攻擊者使用空白密碼來實現(xiàn)根用戶訪問。該安全漏洞實際就是根用戶的訪問控制漏洞，攻擊者很容易利用該漏洞實現(xiàn)越權(quán)訪問。

3.1.2 Docker鏡像源的安全問題

Docker提供了Docker Hub可以讓用戶上傳創(chuàng)建的鏡像，以便用戶下載，快速搭建環(huán)境。但同時有一些安全問題需要應(yīng)對，如Docker鏡像存在黑客上傳惡意鏡像、鏡像使用有漏洞的軟件、中間人攻擊篡改鏡像等。這些問題都與我們在網(wǎng)絡(luò)上下載軟件所遇到的問題相同。

3.1.3 Docker架構(gòu)缺陷與安全機(jī)制

Docker本身的架構(gòu)與機(jī)制可能產(chǎn)生的攻擊場景是在黑客已經(jīng)控制了宿主機(jī)上的一些容器（或者通過在公有云上建立容器的方式獲得這個條件）后，對宿主機(jī)或其他容器發(fā)起攻擊來產(chǎn)生影響。存在容器之間的局域網(wǎng)攻擊、耗盡資源造成拒絕服務(wù)攻擊、調(diào)用有漏洞的系統(tǒng)、通過Docker提權(quán)等安全隱患。

3.2 開源容器編排技術(shù)K8S面臨的安全隱患

3.2.1 容器之間通信帶來的安全隱患

容器和Pod（K8S最小運(yùn)行單元）需要在部署中相互通信，也需要與其他內(nèi)部和外部端點(diǎn)通信才能正常工作。如果某個容器被破壞，攻擊者可影響的環(huán)境范圍與該容器的通信范圍直接相關(guān)，這意味著與該容器通信的其他容器以及Pod可能會遭受攻擊。

3.2.2 鏡像帶來的安全問題

K8S是對容器的管理和多個容器的編排、互操作，容器運(yùn)行需要拉取鏡像。因此容器鏡像帶來的安全問題在容器編排過程中依然存在，而且波及范圍更廣。

3.2.3 K8S本身的安全隱患

2020年，MITRE CVE發(fā)布30個K8S漏洞（截至2020年12月28日），這里舉例以下典型漏洞。

編號CVE-2020-8558的漏洞：

發(fā)現(xiàn)版本1.1.0-1.16.10、1.17.0-1.17.6和1.18.0-1.18.3中的Kubelet和kube-proxy組件允許相鄰主機(jī)訪問TCP和UDP服務(wù)綁定到節(jié)點(diǎn)上或在節(jié)點(diǎn)的網(wǎng)絡(luò)名稱空間中運(yùn)行的127.0.0.1。通常認(rèn)為此類服務(wù)僅可由同一主機(jī)上的其他進(jìn)程訪問，但是由于這種缺陷，與該節(jié)點(diǎn)在同一LAN上的其他主機(jī)或與該服務(wù)在同一節(jié)點(diǎn)上運(yùn)行的容器可以訪問該服務(wù)。

編號CVE-2020-8557的漏洞：

版本1.1-1.16.12、1.17.0-1.17.8和1.18.0-1.18.5中的K8S kubelet組件不考慮Pod寫入其自己的/etc/ hosts文件的磁盤使用情況。計算Pod的臨時存儲使用量時，kubelet刨除管理器不包括kubelet掛載在Pod中的/etc/ hosts文件。如果Pod將大量數(shù)據(jù)寫入/etc/hosts文件，則可能會填充節(jié)點(diǎn)的存儲空間并導(dǎo)致節(jié)點(diǎn)故障。

編號CVE-2020-8558的漏洞：

利用K8s節(jié)點(diǎn)之間網(wǎng)絡(luò)訪問控制的安全隱患造成的漏洞，沒有實現(xiàn)主機(jī)之間的隔離造成安全隱患。

3.3 基于容器的開發(fā)交付機(jī)制安全問題

容器的使用為軟件開發(fā)交付帶來了便利，如DevOps模式。但由于種種原因，安全問題沒有得到足夠重視，例如：

（1）DevOps偏向于設(shè)計開發(fā)和交付，由于大量使用自動化流水線工具，安全人員沒有及時參與；

（2）大多數(shù)安全人員不熟悉開發(fā)運(yùn)維流水線中的常用工具，尤其是與其互操作和自動化流水線功能相關(guān)的技術(shù)；

（3）大多數(shù)安全人員不了解容器是什么，更不用說容器獨(dú)特的安全問題是哪些了；

（4）安全常被視為與開發(fā)運(yùn)維敏捷性相對立的東西，因為DevOps追求快速交付、持續(xù)交付，而從安全角度看，在快速交付的同時，應(yīng)盡量落實安全控制；

（5）安全基礎(chǔ)設(shè)施依然建立在硬件設(shè)計上，而硬件設(shè)計往往落后于軟件定義和可編程性的概念，這就造成了很難將安全控制措施以自動化的方式集成到DevOps開發(fā)運(yùn)維流水線的局面。

與其他新興技術(shù)一樣，容器和DevOps并非從一開始就將安全考慮了進(jìn)去。在大多數(shù)企業(yè)中，容器和DevOps尚未納入企業(yè)整體安全計劃，但由于可能已經(jīng)部署到了企業(yè)中某些地方，這些技術(shù)理應(yīng)被當(dāng)做需要保護(hù)的對象。

3.4 企業(yè)利用容器技術(shù)將面臨新的發(fā)展機(jī)遇和安全問題

在傳統(tǒng)企業(yè)如制造業(yè)中，智能制造、信息物理系統(tǒng)、數(shù)字孿生、物聯(lián)網(wǎng)、5G等新興信息技術(shù)正逐漸得到應(yīng)用，容器技術(shù)能為新興信息技術(shù)的利用注入活力，比如輕量化的容器能夠為設(shè)備的數(shù)字化、智能化升級賦能。由于開源容器技術(shù)的易獲得、易運(yùn)行、易維護(hù)、易移植等優(yōu)勢，為傳統(tǒng)企業(yè)的數(shù)字化轉(zhuǎn)型提供了動能。同時，存在的安全問題也不能忽視，容器物理運(yùn)行環(huán)境的安全、容器的故障恢復(fù)能力都應(yīng)該得到關(guān)注；數(shù)據(jù)和數(shù)據(jù)流動的安全依然是企業(yè)應(yīng)用容器技術(shù)的安全防護(hù)的重中之重，容器與傳統(tǒng)技術(shù)不同，用戶無須關(guān)心容器內(nèi)部的運(yùn)行情況，拉出應(yīng)用程序直接運(yùn)行即可，因此對于容器是否安全，數(shù)據(jù)和數(shù)據(jù)流動是否安全，用戶“看”不出來，這無疑會造成容器是否能在企業(yè)安全落地的難題。

4 開源容器技術(shù)安全應(yīng)對建議

4.1 開源容器技術(shù)安全的頂層設(shè)計和監(jiān)管建議

目前，開源容器技術(shù)發(fā)展很快，應(yīng)用也很廣泛。但是我國尚未正式發(fā)布專門針對開源容器技術(shù)安全利用的相關(guān)規(guī)章制度。面對眼花繚亂的容器技術(shù)市場和琳瑯滿目的容器安全技術(shù)，普通開發(fā)者和用戶很難分辨哪些鏡像是安全的，哪些鏡像是不安全的。因此，建議相關(guān)部門定期發(fā)布不安全的鏡像信息；加強(qiáng)容器安全技術(shù)的授信，確保容器安全防護(hù)技術(shù)本身的安全可靠；對企業(yè)安全使用Docker和K8S技術(shù)提供具體指導(dǎo)意見。

4.2 開源容器使用的安全建議

開源容器在使用過程中，要從構(gòu)建時、容器基礎(chǔ)設(shè)施、運(yùn)行時等方面進(jìn)行安全控制的考慮。對此提出以下4點(diǎn)建議。

（1）強(qiáng)化容器運(yùn)行環(huán)境（宿主機(jī)）的安全。底層操作系統(tǒng)應(yīng)受到良好保護(hù)，以防止對容器的攻擊影響到實體主機(jī)。對此，Linux有一些現(xiàn)成的安全模塊可用。

（2）保護(hù)DevOps開發(fā)運(yùn)維流水線。在整個開發(fā)運(yùn)維流水線上應(yīng)用特權(quán)管理操作，確保只有經(jīng)授權(quán)的用戶可以訪問該環(huán)境，并限制未授權(quán)用戶在環(huán)境中的橫向移動。

（3）鏡像的漏洞掃描。在運(yùn)行前對容器鏡像執(zhí)行深度漏洞掃描。

（4）持續(xù)監(jiān)測容器鏡像。在運(yùn)行時檢測容器和托管主機(jī)中的root提權(quán)、端口掃描、逆向Shell和其他可疑活動，防止漏洞利用攻擊和突破。

4.3 企業(yè)利用容器技術(shù)的安全建議

對于企業(yè)而言，利用容器技術(shù)時，建議圍繞應(yīng)用安全和數(shù)據(jù)安全開展工作。

（1）應(yīng)用安全方面：①容器可視化：容器內(nèi)部對企業(yè)而言是“黑盒”，要力圖實現(xiàn)容器內(nèi)部信息的外部可視化，把內(nèi)部的業(yè)務(wù)邏輯和信息交互邏輯，通過可視化的形式展現(xiàn)給管理用戶。②容器應(yīng)用安全措施：規(guī)范鏡像構(gòu)建，實行鏡像簽名，建立鏡像中心拉取等的操作審計日志，使用可信的容器鏡像等。③強(qiáng)化管理：定義運(yùn)營、開發(fā)、安全團(tuán)隊之間的角色。職責(zé)分離是一種最佳實踐，應(yīng)以明確的角色和責(zé)任記錄在案。在DevOps的基礎(chǔ)上，實施DevSecOps（開發(fā)—安全—運(yùn)維一體化）。④DevSecOps：是指先在應(yīng)用程序開發(fā)的生命周期中引入安全性，從而盡可能地減少漏洞并使安全性更接近IT和業(yè)務(wù)目標(biāo)。構(gòu)成真正的DevSecOps環(huán)境的3個關(guān)鍵因素是：安全測試由開發(fā)團(tuán)隊完成；測試期間發(fā)現(xiàn)的問題由開發(fā)團(tuán)隊管理；解決這些問題的責(zé)任在于開發(fā)團(tuán)隊。⑤連續(xù)身份認(rèn)證和授權(quán)：容器應(yīng)用一般都是通過流水線的形式進(jìn)行開發(fā)、測試、發(fā)布、上線的，對于每個環(huán)節(jié)都要進(jìn)行身份認(rèn)證和授權(quán)，保證安全。⑥應(yīng)用安全恢復(fù)：采取各種措施，保證應(yīng)用具有快速恢復(fù)的能力，比如采用集群技術(shù)。

（2）數(shù)據(jù)安全方面：①數(shù)據(jù)存儲：對于傳統(tǒng)的事務(wù)型數(shù)據(jù)使用關(guān)系型數(shù)據(jù)庫更易于管理，因此不建議納入容器管理。②數(shù)據(jù)流動：通過身份認(rèn)證和授權(quán)，保障數(shù)據(jù)安全和范圍控制；數(shù)據(jù)按照重要程度進(jìn)行分類；不同用戶之間容器網(wǎng)絡(luò)隔離。默認(rèn)設(shè)置為：不同用戶的容器與容器之間不能互相訪問；同一用戶的所有容器可以互相訪問。③數(shù)據(jù)備份：做好數(shù)據(jù)備份工作。④宿主機(jī)掛載目錄：用戶通過統(tǒng)一運(yùn)維管理平臺，只能將固定目錄掛載到容器中。⑤分布式文件系統(tǒng)：用戶通過統(tǒng)一運(yùn)維管理平臺申請數(shù)據(jù)文件，通過apikey/secrekey訪問平臺提供的分布式文件。⑥數(shù)據(jù)故障恢復(fù)：采取集群技術(shù)，同時做好數(shù)據(jù)備份。

5 結(jié)語

開源容器技術(shù)如Docker、K8S等已廣泛被應(yīng)用于實際生產(chǎn)環(huán)境，隨著我國云計算平臺的快速發(fā)展，容器技術(shù)將獲得更大范圍、更深層次的應(yīng)用。在一些傳統(tǒng)行業(yè)，特別是制造業(yè)，將會迎來容器化技術(shù)帶來的創(chuàng)新機(jī)遇。一方面我們要做好規(guī)劃和設(shè)計，大力推進(jìn)基于容器技術(shù)的應(yīng)用創(chuàng)新；另一方面我們要加大對開源容器技術(shù)的安全漏洞防范，保護(hù)應(yīng)用安全和數(shù)據(jù)安全。 

 

（原載于《保密科學(xué)技術(shù)》雜志2021年1月刊）