開源容器技術(shù)安全分析

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

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

1 引言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

與傳統(tǒng)虛擬機(jī)相比，Docker容器不擁有獨(dú)立的資源配置，且沒有做到操作系統(tǒng)內(nèi)核層面的隔離，因此可能存在資源隔離不徹底與資源限制不到位所導(dǎo)致的容器虛擬化安全風(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)問題。而在輕量級(jí)虛擬化的容器網(wǎng)絡(luò)和容器編排環(huán)境中，其網(wǎng)絡(luò)安全風(fēng)險(xiǎn)較傳統(tǒng)網(wǎng)絡(luò)而言更為復(fù)雜嚴(yán)峻。

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

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

3.1.1 Docker自身漏洞

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

3.1.2 Docker鏡像源的安全問題

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

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

Docker本身的架構(gòu)與機(jī)制可能產(chǎn)生的攻擊場景是在黑客已經(jīng)控制了宿主機(jī)上的一些容器（或者通過在公有云上建立容器的方式獲得這個(gè)條件）后，對(duì)宿主機(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)通信才能正常工作。如果某個(gè)容器被破壞，攻擊者可影響的環(huán)境范圍與該容器的通信范圍直接相關(guān)，這意味著與該容器通信的其他容器以及Pod可能會(huì)遭受攻擊。

3.2.2 鏡像帶來的安全問題

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

3.2.3 K8S本身的安全隱患

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

編號(hào)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ù)。

編號(hào)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文件的磁盤使用情況。計(jì)算Pod的臨時(shí)存儲(chǔ)使用量時(shí)，kubelet刨除管理器不包括kubelet掛載在Pod中的/etc/ hosts文件。如果Pod將大量數(shù)據(jù)寫入/etc/hosts文件，則可能會(huì)填充節(jié)點(diǎn)的存儲(chǔ)空間并導(dǎo)致節(jié)點(diǎn)故障。

編號(hào)CVE-2020-8558的漏洞：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（2）數(shù)據(jù)安全方面：①數(shù)據(jù)存儲(chǔ)：對(duì)于傳統(tǒng)的事務(wù)型數(shù)據(jù)使用關(guān)系型數(shù)據(jù)庫更易于管理，因此不建議納入容器管理。②數(shù)據(jù)流動(dòng)：通過身份認(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ái)，只能將固定目錄掛載到容器中。⑤分布式文件系統(tǒng)：用戶通過統(tǒng)一運(yùn)維管理平臺(tái)申請(qǐng)數(shù)據(jù)文件，通過apikey/secrekey訪問平臺(tái)提供的分布式文件。⑥數(shù)據(jù)故障恢復(fù)：采取集群技術(shù)，同時(shí)做好數(shù)據(jù)備份。

5 結(jié)語

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

 

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