開源容器技術安全分析

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

【關鍵詞】 容器技術 Docker Kubernetes 容器安全

1 引言

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

2 開源容器技術發展應用分析

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

2.1 容器技術發展迅速且應用廣泛

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

2.2 開源技術推動了容器技術發展

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

2.3 基于容器技術的敏捷開發模式日趨流行

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

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

基于容器技術的DevOps各個階段都可能存在安全漏洞，應該實施安全控制措施，如構建時安全、基礎鏡像的安全、Docker基礎設施安全、運行時安全等，要加強容器鏡像掃描、容器編排

配置錯誤控制、網絡身份訪問管理、檢測和事件響應等。

3 開源容器技術面臨的安全挑戰分析

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

Docker容器技術應用中可能存在的技術性安全風險分為鏡像安全風險、容器虛擬化安全風險、網絡安全風險等類型。

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

與傳統虛擬機相比，Docker容器不擁有獨立的資源配置，且沒有做到操作系統內核層面的隔離，因此可能存在資源隔離不徹底與資源限制不到位所導致的容器虛擬化安全風險。

網絡安全風險是互聯網中所有信息系統所面臨的重要風險，不論是物理設備還是虛擬機，都存在難以完全規避的網絡安全風險問題。而在輕量級虛擬化的容器網絡和容器編排環境中，其網絡安全風險較傳統網絡而言更為復雜嚴峻。

3.1 開源容器技術Docker面臨的安全隱患

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

3.1.1 Docker自身漏洞

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

3.1.2 Docker鏡像源的安全問題

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

3.1.3 Docker架構缺陷與安全機制

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

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

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

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

3.2.2 鏡像帶來的安全問題

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

3.2.3 K8S本身的安全隱患

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

編號CVE-2020-8558的漏洞：

發現版本1.1.0-1.16.10、1.17.0-1.17.6和1.18.0-1.18.3中的Kubelet和kube-proxy組件允許相鄰主機訪問TCP和UDP服務綁定到節點上或在節點的網絡名稱空間中運行的127.0.0.1。通常認為此類服務僅可由同一主機上的其他進程訪問，但是由于這種缺陷，與該節點在同一LAN上的其他主機或與該服務在同一節點上運行的容器可以訪問該服務。

編號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將大量數據寫入/etc/hosts文件，則可能會填充節點的存儲空間并導致節點故障。

編號CVE-2020-8558的漏洞：

利用K8s節點之間網絡訪問控制的安全隱患造成的漏洞，沒有實現主機之間的隔離造成安全隱患。

3.3 基于容器的開發交付機制安全問題

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

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

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

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

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

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

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

3.4 企業利用容器技術將面臨新的發展機遇和安全問題

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

4 開源容器技術安全應對建議

4.1 開源容器技術安全的頂層設計和監管建議

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

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

開源容器在使用過程中，要從構建時、容器基礎設施、運行時等方面進行安全控制的考慮。對此提出以下4點建議。

（1）強化容器運行環境（宿主機）的安全。底層操作系統應受到良好保護，以防止對容器的攻擊影響到實體主機。對此，Linux有一些現成的安全模塊可用。

（2）保護DevOps開發運維流水線。在整個開發運維流水線上應用特權管理操作，確保只有經授權的用戶可以訪問該環境，并限制未授權用戶在環境中的橫向移動。

（3）鏡像的漏洞掃描。在運行前對容器鏡像執行深度漏洞掃描。

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

4.3 企業利用容器技術的安全建議

對于企業而言，利用容器技術時，建議圍繞應用安全和數據安全開展工作。

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

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

5 結語

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

 

（原載于《保密科學技術》雜志2021年1月刊）