【摘 要】 隨著容器技術的快速發(fā)展和廣泛應用,其面臨的安全問題也越來越突出。本文在分析開源容器技術典型代表Docker和Kubernetes應用過程中面臨的安全問題及挑戰(zhàn)的基礎上,提出應對建議。
【關鍵詞】 容器技術 Docker Kubernetes 容器安全
1 引言
高德納(Gartner)預測,到2023年,70%的組織將在生產(chǎn)中運行3個或更多容器化應用程序。容器、容器編排技術(Kubernetes,K8S)和微服務應用模式是企業(yè)IT創(chuàng)新和數(shù)字化轉(zhuǎn)型的三大驅(qū)動力,很多公司已經(jīng)采用這些技術,發(fā)揮其在應用程序開發(fā)和部署方面的優(yōu)勢。隨著容器技術的快速發(fā)展和廣泛應用,其面臨的安全問題也越來越突出。本文在分析開源容器技術典型代表Docker和K8S應用過程中面臨的安全問題及挑戰(zhàn)的基礎上,提出應對建議。
2 開源容器技術發(fā)展應用分析
相比于系統(tǒng)級虛擬化,容器技術是進程級別的,具有啟動快、體積小等優(yōu)勢,為軟件開發(fā)、應用部署帶來了諸多便利。如使用開源容器Docker技術,應用程序打包推送到鏡像中心后,使用時拉取直接運行,實現(xiàn)了“一次打包,到處運行”,非常方便、快捷;使用開源容器編排技術K8S能夠?qū)崿F(xiàn)應用程序的彈性擴容和自動化部署,滿足企業(yè)靈活擴展信息系統(tǒng)的需求。但是,隨著Docker和K8S應用的日益廣泛和深入,安全問題也越來越凸顯。
2.1 容器技術發(fā)展迅速且應用廣泛
2013年,Docker公司提出Docker開源容器項目,隨后發(fā)布了一系列工具鏈來支持容器使用;到2020年,Docker容器官方鏡像倉庫Docker Hub的鏡像中心累計下載了1300億次,用戶創(chuàng)建了約600萬個容器鏡像庫。Docker開源技術能實現(xiàn)對容器的治理和編排,已成為容器管理領域事實上的行業(yè)標準。根據(jù)云原生計算基金會于2020年3月發(fā)布的最新調(diào)查,在亞馬遜公司云計算平臺(Amazon Web Services,AWS)和谷歌公司云平臺(Google Cloud Platform,GCP)的托管服務中,K8S的生產(chǎn)使用率從58%躍升至78%。
2.2 開源技術推動了容器技術發(fā)展
Docker技術和K8S技術之所以能夠快速發(fā)展和廣泛應用,除了技術本身的優(yōu)勢之外,重要的原因就是由于開源社區(qū)管理和支持。開源社區(qū)具有限制少、交付快捷、迭代快速、參與人員多、大公司支持等優(yōu)勢,大大促進了容器技術的演進。開源容器技術生態(tài)體系日趨完善,已貫穿現(xiàn)代化軟件工程的整個生命周期,其復雜度也在不斷提升。
2.3 基于容器技術的敏捷開發(fā)模式日趨流行
在移動應用、互聯(lián)網(wǎng)背景下,企業(yè)競爭日趨激烈,應用程序快速迭代、持續(xù)交付顯得尤為重要。容器技術的應用大大推動了軟件交付模式的革新,基于容器的敏捷開發(fā)模式DevOps(開發(fā)運維一體化)大大提高了軟件的交付速度、部署頻率。常見的DevOps流程,包括拉取代碼、代碼構建、項目打包、Docker構建、拉取鏡像和Docker運行6個步驟,通過多種工具的集成,構成了自動化DevOps開發(fā)運維流水線,開發(fā)人員提交的代碼能夠自動部署到生產(chǎn)環(huán)境,如圖1所示。
DevOps生命周期是以下各項工作的反復迭代:計劃、編碼、構建、測試、發(fā)布、部署、運維、監(jiān)控。從開發(fā)人員提交代碼開始,直到在生產(chǎn)環(huán)境中運行,形成自動流水線過程;一旦運行,就反復迭代、循環(huán)運行。任一環(huán)節(jié)出現(xiàn)安全問題,就會影響開發(fā)、交付,同時也增加了安全控制的復雜度和難度。
基于容器技術的DevOps各個階段都可能存在安全漏洞,應該實施安全控制措施,如構建時安全、基礎鏡像的安全、Docker基礎設施安全、運行時安全等,要加強容器鏡像掃描、容器編排
配置錯誤控制、網(wǎng)絡身份訪問管理、檢測和事件響應等。
3 開源容器技術面臨的安全挑戰(zhàn)分析
2020年,Prevasio公司發(fā)布Docker容器官方鏡像倉庫Docker Hub分析報告:通過對400萬容器鏡像的掃描發(fā)現(xiàn)51%的鏡像存在高危漏洞,6432個鏡像包含病毒或惡意程序。
Docker容器技術應用中可能存在的技術性安全風險分為鏡像安全風險、容器虛擬化安全風險、網(wǎng)絡安全風險等類型。
Docker Hub中的鏡像可由個人開發(fā)者上傳,其數(shù)量豐富、版本多樣,但質(zhì)量參差不齊,甚至存在包含惡意漏洞的惡意鏡像,因而可能存在較大的安全風險。具體而言,Docker鏡像的安全風險分布在創(chuàng)建過程、獲取來源、獲取途徑等方方面面。
與傳統(tǒng)虛擬機相比,Docker容器不擁有獨立的資源配置,且沒有做到操作系統(tǒng)內(nèi)核層面的隔離,因此可能存在資源隔離不徹底與資源限制不到位所導致的容器虛擬化安全風險。
網(wǎng)絡安全風險是互聯(lián)網(wǎng)中所有信息系統(tǒng)所面臨的重要風險,不論是物理設備還是虛擬機,都存在難以完全規(guī)避的網(wǎng)絡安全風險問題。而在輕量級虛擬化的容器網(wǎng)絡和容器編排環(huán)境中,其網(wǎng)絡安全風險較傳統(tǒng)網(wǎng)絡而言更為復雜嚴峻。
3.1 開源容器技術Docker面臨的安全隱患
Docker的安全問題主要可能來源于3個方面。
3.1.1 Docker自身漏洞
Docker作為一款軟件,自然也跟軟件一樣,技術實現(xiàn)上會有代碼缺陷。MITRE公司共發(fā)布了134項Docker安全漏洞(截至2020年12月28日)。 編號CVE-2020-35467的安全漏洞顯示,2020年12月14日之前的Docker Docs映像包含根用戶的空白密碼。使用受影響的Docker Docs容器版本部署的系統(tǒng)可能允許遠程攻擊者使用空白密碼來實現(xiàn)根用戶訪問。該安全漏洞實際就是根用戶的訪問控制漏洞,攻擊者很容易利用該漏洞實現(xiàn)越權訪問。
3.1.2 Docker鏡像源的安全問題
Docker提供了Docker Hub可以讓用戶上傳創(chuàng)建的鏡像,以便用戶下載,快速搭建環(huán)境。但同時有一些安全問題需要應對,如Docker鏡像存在黑客上傳惡意鏡像、鏡像使用有漏洞的軟件、中間人攻擊篡改鏡像等。這些問題都與我們在網(wǎng)絡上下載軟件所遇到的問題相同。
3.1.3 Docker架構缺陷與安全機制
Docker本身的架構與機制可能產(chǎn)生的攻擊場景是在黑客已經(jīng)控制了宿主機上的一些容器(或者通過在公有云上建立容器的方式獲得這個條件)后,對宿主機或其他容器發(fā)起攻擊來產(chǎn)生影響。存在容器之間的局域網(wǎng)攻擊、耗盡資源造成拒絕服務攻擊、調(diào)用有漏洞的系統(tǒng)、通過Docker提權等安全隱患。
3.2 開源容器編排技術K8S面臨的安全隱患
3.2.1 容器之間通信帶來的安全隱患
容器和Pod(K8S最小運行單元)需要在部署中相互通信,也需要與其他內(nèi)部和外部端點通信才能正常工作。如果某個容器被破壞,攻擊者可影響的環(huán)境范圍與該容器的通信范圍直接相關,這意味著與該容器通信的其他容器以及Pod可能會遭受攻擊。
3.2.2 鏡像帶來的安全問題
K8S是對容器的管理和多個容器的編排、互操作,容器運行需要拉取鏡像。因此容器鏡像帶來的安全問題在容器編排過程中依然存在,而且波及范圍更廣。
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組件允許相鄰主機訪問TCP和UDP服務綁定到節(jié)點上或在節(jié)點的網(wǎng)絡名稱空間中運行的127.0.0.1。通常認為此類服務僅可由同一主機上的其他進程訪問,但是由于這種缺陷,與該節(jié)點在同一LAN上的其他主機或與該服務在同一節(jié)點上運行的容器可以訪問該服務。
編號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é)點的存儲空間并導致節(jié)點故障。
編號CVE-2020-8558的漏洞:
利用K8s節(jié)點之間網(wǎng)絡訪問控制的安全隱患造成的漏洞,沒有實現(xiàn)主機之間的隔離造成安全隱患。
3.3 基于容器的開發(fā)交付機制安全問題
容器的使用為軟件開發(fā)交付帶來了便利,如DevOps模式。但由于種種原因,安全問題沒有得到足夠重視,例如:
(1)DevOps偏向于設計開發(fā)和交付,由于大量使用自動化流水線工具,安全人員沒有及時參與;
(2)大多數(shù)安全人員不熟悉開發(fā)運維流水線中的常用工具,尤其是與其互操作和自動化流水線功能相關的技術;
(3)大多數(shù)安全人員不了解容器是什么,更不用說容器獨特的安全問題是哪些了;
(4)安全常被視為與開發(fā)運維敏捷性相對立的東西,因為DevOps追求快速交付、持續(xù)交付,而從安全角度看,在快速交付的同時,應盡量落實安全控制;
(5)安全基礎設施依然建立在硬件設計上,而硬件設計往往落后于軟件定義和可編程性的概念,這就造成了很難將安全控制措施以自動化的方式集成到DevOps開發(fā)運維流水線的局面。
與其他新興技術一樣,容器和DevOps并非從一開始就將安全考慮了進去。在大多數(shù)企業(yè)中,容器和DevOps尚未納入企業(yè)整體安全計劃,但由于可能已經(jīng)部署到了企業(yè)中某些地方,這些技術理應被當做需要保護的對象。
3.4 企業(yè)利用容器技術將面臨新的發(fā)展機遇和安全問題
在傳統(tǒng)企業(yè)如制造業(yè)中,智能制造、信息物理系統(tǒng)、數(shù)字孿生、物聯(lián)網(wǎng)、5G等新興信息技術正逐漸得到應用,容器技術能為新興信息技術的利用注入活力,比如輕量化的容器能夠為設備的數(shù)字化、智能化升級賦能。由于開源容器技術的易獲得、易運行、易維護、易移植等優(yōu)勢,為傳統(tǒng)企業(yè)的數(shù)字化轉(zhuǎn)型提供了動能。同時,存在的安全問題也不能忽視,容器物理運行環(huán)境的安全、容器的故障恢復能力都應該得到關注;數(shù)據(jù)和數(shù)據(jù)流動的安全依然是企業(yè)應用容器技術的安全防護的重中之重,容器與傳統(tǒng)技術不同,用戶無須關心容器內(nèi)部的運行情況,拉出應用程序直接運行即可,因此對于容器是否安全,數(shù)據(jù)和數(shù)據(jù)流動是否安全,用戶“看”不出來,這無疑會造成容器是否能在企業(yè)安全落地的難題。
4 開源容器技術安全應對建議
4.1 開源容器技術安全的頂層設計和監(jiān)管建議
目前,開源容器技術發(fā)展很快,應用也很廣泛。但是我國尚未正式發(fā)布專門針對開源容器技術安全利用的相關規(guī)章制度。面對眼花繚亂的容器技術市場和琳瑯滿目的容器安全技術,普通開發(fā)者和用戶很難分辨哪些鏡像是安全的,哪些鏡像是不安全的。因此,建議相關部門定期發(fā)布不安全的鏡像信息;加強容器安全技術的授信,確保容器安全防護技術本身的安全可靠;對企業(yè)安全使用Docker和K8S技術提供具體指導意見。
4.2 開源容器使用的安全建議
開源容器在使用過程中,要從構建時、容器基礎設施、運行時等方面進行安全控制的考慮。對此提出以下4點建議。
(1)強化容器運行環(huán)境(宿主機)的安全。底層操作系統(tǒng)應受到良好保護,以防止對容器的攻擊影響到實體主機。對此,Linux有一些現(xiàn)成的安全模塊可用。
(2)保護DevOps開發(fā)運維流水線。在整個開發(fā)運維流水線上應用特權管理操作,確保只有經(jīng)授權的用戶可以訪問該環(huán)境,并限制未授權用戶在環(huán)境中的橫向移動。
(3)鏡像的漏洞掃描。在運行前對容器鏡像執(zhí)行深度漏洞掃描。
(4)持續(xù)監(jiān)測容器鏡像。在運行時檢測容器和托管主機中的root提權、端口掃描、逆向Shell和其他可疑活動,防止漏洞利用攻擊和突破。
4.3 企業(yè)利用容器技術的安全建議
對于企業(yè)而言,利用容器技術時,建議圍繞應用安全和數(shù)據(jù)安全開展工作。
(1)應用安全方面:①容器可視化:容器內(nèi)部對企業(yè)而言是“黑盒”,要力圖實現(xiàn)容器內(nèi)部信息的外部可視化,把內(nèi)部的業(yè)務邏輯和信息交互邏輯,通過可視化的形式展現(xiàn)給管理用戶。②容器應用安全措施:規(guī)范鏡像構建,實行鏡像簽名,建立鏡像中心拉取等的操作審計日志,使用可信的容器鏡像等。③強化管理:定義運營、開發(fā)、安全團隊之間的角色。職責分離是一種最佳實踐,應以明確的角色和責任記錄在案。在DevOps的基礎上,實施DevSecOps(開發(fā)—安全—運維一體化)。④DevSecOps:是指先在應用程序開發(fā)的生命周期中引入安全性,從而盡可能地減少漏洞并使安全性更接近IT和業(yè)務目標。構成真正的DevSecOps環(huán)境的3個關鍵因素是:安全測試由開發(fā)團隊完成;測試期間發(fā)現(xiàn)的問題由開發(fā)團隊管理;解決這些問題的責任在于開發(fā)團隊。⑤連續(xù)身份認證和授權:容器應用一般都是通過流水線的形式進行開發(fā)、測試、發(fā)布、上線的,對于每個環(huán)節(jié)都要進行身份認證和授權,保證安全。⑥應用安全恢復:采取各種措施,保證應用具有快速恢復的能力,比如采用集群技術。
(2)數(shù)據(jù)安全方面:①數(shù)據(jù)存儲:對于傳統(tǒng)的事務型數(shù)據(jù)使用關系型數(shù)據(jù)庫更易于管理,因此不建議納入容器管理。②數(shù)據(jù)流動:通過身份認證和授權,保障數(shù)據(jù)安全和范圍控制;數(shù)據(jù)按照重要程度進行分類;不同用戶之間容器網(wǎng)絡隔離。默認設置為:不同用戶的容器與容器之間不能互相訪問;同一用戶的所有容器可以互相訪問。③數(shù)據(jù)備份:做好數(shù)據(jù)備份工作。④宿主機掛載目錄:用戶通過統(tǒng)一運維管理平臺,只能將固定目錄掛載到容器中。⑤分布式文件系統(tǒng):用戶通過統(tǒng)一運維管理平臺申請數(shù)據(jù)文件,通過apikey/secrekey訪問平臺提供的分布式文件。⑥數(shù)據(jù)故障恢復:采取集群技術,同時做好數(shù)據(jù)備份。
5 結語
開源容器技術如Docker、K8S等已廣泛被應用于實際生產(chǎn)環(huán)境,隨著我國云計算平臺的快速發(fā)展,容器技術將獲得更大范圍、更深層次的應用。在一些傳統(tǒng)行業(yè),特別是制造業(yè),將會迎來容器化技術帶來的創(chuàng)新機遇。一方面我們要做好規(guī)劃和設計,大力推進基于容器技術的應用創(chuàng)新;另一方面我們要加大對開源容器技術的安全漏洞防范,保護應用安全和數(shù)據(jù)安全。
? 2019-2021 All rights reserved. 北京轉(zhuǎn)創(chuàng)國際管理咨詢有限公司 京ICP備19055770號-1
Beijing TransVenture International Management Consulting Co., Ltd.
地址:北京市大興區(qū)新源大街25號院恒大未來城7號樓1102室
北京市豐臺區(qū)南四環(huán)西路128號諾德中心2號樓5層
北京市海淀區(qū)西禪寺(華北項目部)
深圳市南山區(qū)高新科技園南區(qū)R2-B棟4樓12室
深圳市福田區(qū)華能大廈
佛山順德區(qū)北滘工業(yè)大道云創(chuàng)空間
汕頭市龍湖區(qū)泰星路9號壹品灣三區(qū)
長沙市芙蓉區(qū)韶山北路139號文化大廈
梅州市豐順縣大潤發(fā)大廈
歡迎來到本網(wǎng)站,請問有什么可以幫您?
稍后再說 現(xiàn)在咨詢 靖远县| 铜梁县| 洪洞县| 山阴县| 延长县| 苗栗市| 永泰县| 九龙坡区| 新邵县| 泰来县|