容器云常见安全威胁与防范 | 技术干货
戳藍字“CSDN云計算”關注我們哦!
技術頭條:干貨、簡潔、多維全面。更多云計算精華知識盡在眼前,get要點、solve難題,統統不在話下!
?
除了應對常見云平臺和傳統數據中心常見的安全威脅,容器云平臺還存在一些自己獨有的新的安全威脅與挑戰。隨著容器云的廣泛使用,安全方面的問題越來越不容忽視。
?
下面我會帶大家一起看下和傳統的云平臺相比容器云在安全方面的一些問題。
?
容器云平臺安全價值
?
1.?全面的安全策略
?
和傳統的云計算平臺一樣,容器云計算平臺也將計算資源進行了集中化的管理,計算資源集中化管理的好處是容器云平臺的邊界防護更加容易部署。我們可以針對容器云平臺的計算資源提供全面的安全策略管理、全面的安全補丁管理,另外也可提供統一的數據管理以及突發事件管理等安全管理措施。由于容器云平臺已經提供了我們講到的這些安全防護,因此容器云平臺上的用戶不需要組建專業的安全專家團隊來對自己的計算資源和數據進行專門的防護。
?
?
容器云平臺一般會有自己專門的鏡像倉庫,且一般會周期性的從權威的CVE漏洞資料庫中獲取最新的一些漏洞信息,定時更新鏡像倉庫CVE漏洞字典庫。然后接下來會主動對包含了此漏洞的鏡像進行及時的更新或者下線,另外這個時候一般還會對用戶進行漏洞更新的提醒(常見途徑有郵件通知、短信通知、站內信通知等)。這樣平臺上的用戶在使用平臺上提供的容器鏡像時不需要再去考慮一系列的容器鏡像安全問題。
?
2.?用戶低安全成本
?
容器云平臺一般都會進行多租戶的支持,多個租戶共用云平臺上的計算資源。這種情況下我們可以在云平臺集中化的資源上進行統一的安全配置,統一安全配置可以降低各個用戶在安全措施上的平均成本,且平臺級別的安全防護一般要比用戶部署的安全防護要專業的多,這樣的話用戶可以以更低的安全成本使用到更好的安全防護。
?
?
3.?安全防護按需提供
?
云平臺提供的安全防護一般都會進行等級的劃分,較低的安全防護等級一般會免費提供給用戶進行使用,比如較低帶寬的DdoS防護,對于需要更高防護帶寬的用戶可以按需進行購買。
?
除了防護按需購買這種情況之外,容器云平臺還可以利用快速、彈性分配資源的優勢為過濾、流量整型、加密、認證等提供安全防護措施,另外還可根據用戶業務實際的負載情況動態調整計算資源的數量,提高安全措施的處理效率。
?
網絡安全威脅
?
相比傳統的云平臺,容器云平臺在網絡方面一般會有比較大的差異,伴隨著這些差異的引入,也引入了一些網絡方面的安全問題。比如因為網絡隔離模型的變化、資源共享方式的變化而出現的新的安全隱患,針對這兩點變化我們分別看下他們帶來的安全問題。
?
1.?網絡模型
?
容器云平臺中網絡隔離大多使用邏輯隔離代替物理隔離。
?
物理隔離一般不會直接或者間接的連接公共網絡,企業采用物理隔離網絡一般是為了保護自己的各種各樣的硬件設備和通信鏈路不被攻擊,常見的攻擊來自自然災害、人為破壞等,被保護的硬件實體設備常見的有企業的路由器、工作站和其他的各種網絡服務器等。從實際情況來看,一般只有使用了內網和公共網進行的物理隔離才能真正保證內部信息網絡不被來自外界的攻擊影響,比如來自黑客的攻擊。
?
?
網絡的邏輯隔離一般需要借助邏輯隔離設備來實現,從名稱即可看出邏輯隔離器是不同網絡間的一種中間件,用于連接不同的網絡,常見的網絡邏輯設備主要有防火墻、網關等。需要注意的是被隔離的網絡之間仍然有物理的數據鏈路進行聯通,被聯通的兩個網絡之間不能直接的進行數據交換。
?
相比邏輯隔離物理隔離的安全性更高,企業網絡多采用物理隔離代替邏輯隔離,以此來保證不同級別的組織或者部門的信息安全。容器云平臺網絡上采用邏輯隔離,來隔離不同的租戶或者項目,一定程度上增加了云平臺在網絡方面的安全隱患。
?
2.?資源共享
?
容器云在網絡方面的安全問題,除了上面我們講到的網絡邏輯隔離引入的問題,還有資源共享方面的問題。和傳統的云平臺一樣,容器云平臺一般也會有多租戶的需求(公有云肯定會有多租戶的存在,即使是私有云一般也會有多租戶的需求,比如不同的子公司、同公司不同的部門一般都會有多個租戶的需求)。
?
?
相比傳統的云平臺,容器云的多租戶資源共享引入了更多的風險,在容器云中多個租戶共享計算資源,很可能會因為隔離措施不當導致不同租戶的邏輯網絡被意外打通(國內某知名云廠商曾經發生過類似的問題),導致用戶的資源被其他的用戶意外的訪問到,這種情況下用戶可能會被其他的用戶惡意攻擊,導致數據泄露等嚴重的問題。容器云平臺中通常借助網絡防火墻/IPS來進行虛擬化,這種方式也是很常用的方式但是進入云平臺之后,尤其是在用戶眾多的公有云場景中,網絡防火墻這種虛擬化方式就不會暴露出虛擬化能力不足的問題,這個問題會導致已經建立的靜態網絡分區與隔離模型不能滿足容器云中動態資源的共享需求。
?
主機安全威脅
?
容器云平臺目前基本以Docker 容器和kubernetes 容器編排(kubernetes為主流,當然也有支持多種編排工具的廠商)。了解Docker 的同學應該都知道Docker 容器是通過命名空間(namespace)的方式將文件系統、進程、各種設備、網絡等資源進行了隔離。除了對資源的隔離,Docker容器還對容器具有的權限進行了限制,對CPU、內存等資源的使用也進行了相應的限制。對Docker?容器資源的限制、隔離的目的是為了讓容器之間互不影響。
?
容器與容器所在的宿主機共享內核、文件系統、各種硬件等資源。容器可以部署在物理機上,也可以選擇部署在虛擬主機上。
?
由于Docker 容器與宿主機共享內核、文件系統等資源,Docker 本身的隔離性不如虛擬機主機完善,因此如果Docker 自身出現漏洞,可能會波及問題Docker 容器所在的宿主機,由于Docker 容器所在的宿主機上可能存在當前租戶的其他容器,也可能存在其他租戶的容器,所以問題最終可能會影響到其他的容器,并可能會破壞容器云平臺上的宿主機。
?
?
除了上面提到的Docker 容器可能會影響宿主機的問題,Docker 在主機層面還面臨一些其他的問題,如容器對Hypervisor 的安全威脅、對虛擬機的安全威脅等,下面我們一起看下。
?
1.?Hypervisor 隱患
?
Hypervisor 基本可以說是當前虛擬化的核心,使用非常廣泛。Hypervisor 處在虛擬主機和宿主機之間,可以捕獲CPU指令,為訪問硬件控制器和各種各種外設設備充當中介。由于Hypervisor 可以協調各種資源的分配,因此它的權限非常之大,Hypervisor 運行在比操作系統特權還高的最高優先級。因此如果因為Docker 容器的漏洞導致Hypervisor 被攻擊,則運行在Hypervisor 之上的所有的虛擬主機都會被波及,所有的虛擬主機將無任何的安全保障,基本處于直接的攻擊之下。
?
2.?虛擬機主機隱患
?
Docker 容器出現安全漏洞時,可能會導致接入和管理虛擬機的密鑰被盜。我們知道虛擬機的動態創建、遷移(冷遷、熱遷)、都會伴隨著虛擬機安全措施的自動創建和自動遷移,如果Docker 容器出現漏洞可能會導致容器中未及時打補丁的服務遭受攻擊,比較易被攻擊的服務有FTP、SSH等,攻擊可能會導致弱密碼或者無密碼的賬號被盜用,如果這個時候主機沒有設置防火墻策略,則遭受的攻擊可能會更加嚴重。
?
??
應用安全威脅
?
容器云平臺除了在網絡層面和主機層面引入了額外的安全問題外,在我們最常接觸的應用層面和數據層面也引入了一些安全問題,下面我們先看下應用層面引入的問題。
?
我們從應用層面談到容器的時候一般首先需要考慮的是我們的容器中有什么?比如有些時候我們的應用程序和基礎設施會有很多的組件組成,這些常用的組件中可能有一些會是開源的軟件,比如linux操作系統、各種開源的Web服務器(比如Apache?web服務器、Tomcat Web 服務器、Nginx web服務器等)、Red Hat Jboss企業應用平臺、各種開源的數據庫(比如mysql數據庫、postgresql 數據庫)等。以上我們列舉的只是一部分常用的開源軟件,不同的業務場景中可能還會有自己專門需要的一些開源軟件,比如node應用中肯定會用到node.js。
?
?
上文我們列舉的那些常用的軟件基本都有自己的容器化版本,且很多軟件除了提供了常用的具備基本功能的容器版本外還額外提供了很多做過專門優化的容器化的版本。對于已經提供了容器化版本的軟件我們一般沒有必要再自己造輪子,一般不需要再重新構建一遍。但是從實際使用來看,并不是每一個容器化的版本都能滿足我們的業務需求,比如我們需要一個或者多個額外的軟件包,這個包提供了和行業相關的特殊的功能,這種情況下我們需要引入額外的第三方的包,然后進行新鏡像的構建,這個時候就會引入新的隱患,即我們可能不清楚這些第三方包的來源,不清楚這些包是否已經經過嚴格的測試,也不會清楚這些包中是否被植入惡意的代碼。
?
Docker 的容器鏡像本質上是一系列的靜態文件的集合,也可以說是容器應用運行的時候可見的文件系統。所謂的鏡像掃描就是遍歷所有的鏡像中的文件系統,遍歷文件系統時會逐個檢查文件系統中的軟件包是否有漏洞。這個過程跟我們自己的PC本中的病毒掃描軟件在掃描病毒時是一樣的,對系統中所有的文件進行掃描分析,并將掃描結果和已知的病毒數據庫中的指紋特征進行對比,從而發現病毒的存在。
?
數據安全威脅
?
我們知道容器即可被用于有狀態的應用,也可被用于無狀態的應用。如果我們使用有狀態應用的話一般還需要為有狀態應用添加額外的存儲介質,Docker在存儲介質方面容器提供了多種支持,常見的有網絡文件系統NFS、AWS彈性塊存儲EBS、GCE持久化存儲、GlusterFS存儲、ISCSI存儲、分布式存儲Ceph以及Cinder 等。
?
一個存儲卷可以通過存儲介質支持的方式掛載到目標主機上,不同的存儲介質往往具有不同的性能,且不同的持久化卷支持的訪問模式往往也是不同的,例如網絡文件系統NFS能夠支持多路客戶端的同時讀/寫。
?
容器云中引入這些存儲介質在一定程度上方便了我們的數據存儲,同時也引入了額外的安全問題,如NFS 可能會引入RPC服務的訪問權限問題等。
?
容器云平臺安全防范
?
上文中我們列舉了容器云平臺中最常遇到的安全威脅以及安全防護的必要性,根據容器云平臺領域面臨的這些威脅與挑戰,在此我們提供了一些相應的安全解決方案。
?
1.?計算節點安全
?
相比其他的部分計算節點安全方面需要做的防護工作較多,具體如下:
?
(1)?User NameSpace
?
User NameSpace 方面建議保證容器內的root權限在容器之外設置為非管理員權限,這樣即使容器出現問題用戶透過容器進入了容器所在的宿主機也不會拿到真正的管理員權限。
?
(2)?資源控制
?
利用Cgroups 對容器可以支配的資源配額和度量進行嚴格的控制,如對CPU、內存的限制等關鍵資源的限制。
?
借助資源控制可以防止某個惡意的容器占用過多的宿主機的資源。
?
(3)?命名空間
?
建議不要將容器的命名空間和宿主機進程的命名空間進行共享,這樣可以降低用戶從容器中進入容器所在的宿主機的風險,進而降低同宿主機上其他用戶的容器被攻擊的風險。
?
(4)?容器重試次數
?
容器編排工具,以kubernetes 為例,重啟策略一般分為三種:Always(默認策略)、Onfailure和Never。
?
設置的策略為Always時,當容器發生終止退出時容器會被重啟,如果重啟后容器再次發生終止退出,則再次重啟容器,循環往復。
??設置的策略為Onfaliure 時,當容器因為發生異常且退出碼不為0時,對異常的容器進行重啟。
??設置的策略為Never時,不論容器的運行狀態如何,都不會對容器進行重啟操作。
?
在實際使用中,很多情況下我們為了保證容器中的進程在遇到異常時可以及時通過重啟來恢復應用,會將重啟策略設置為always。這個時候如果容器重啟后恢復正常還好,如果容器重啟后又陷入異常,導致容器反復的重啟。為避免這種情況的出現,一般建議通過設置on-fallure?來限制容器的嘗試次數。
?
(5)?限制進程數
?
容器的正確使用姿勢中一般建議一個容器中只跑一個進程,但從筆者實際觀察來看,在容器中跑多個進程,將容器當做虛擬機使用的用戶不在少數。
?
容器中允許運行的進程數過多的話會帶來fork bomb的風險,即攻擊者可能會利用循環在容器中不斷的新建進程,導致為容器分配的資源被耗盡,如果這個時候恰好又未限制容器可以使用的資源量或者限制的數值較大的話,可能會導致容器所在宿主機上的資源被耗盡,導致當前宿主機上的其他容器觸發遷移。所以在容器云中一般也會建議大家限制下容器中可用的進程數目。
?
(6)?端口映射
?
容器中運行著我們的業務進程,為了從容器之外訪問到容器中的進程,我們需要對我們應用監聽的端口做一次映射,為防止其他人通過容器內的特權端口(1024以下的端口)攻擊容器,比如開啟22端口會增加容器中系統的賬號信息被暴力破解的風險,所以一般建議容器只映射應用監聽的端口。
?
(7)?網絡模式
?
我們知道在docker?run運行容器時可通過-net選項指定容器的網絡模式,Docker容器支持的網絡模式一般包括如下四種:
?
a.?Bridge模式
docker run 運行容器時的默認網絡模式。此模式會為每一個容器分配網絡命名空間、IP等,并且會將宿主機上的Docker容器連接到一個虛擬網橋上。
?
?
b.?Host模式
和上面講到的bridge模式不同,如果啟動容器時指定host模式,那么這個容器將不會獲得一個獨立的網絡命名空間。此時容器將會和容器所在的宿主機共用同一個網絡命名空間,且在此模式下容器不會虛擬出屬于自己的虛擬網卡以及IP地址,而是使用宿主機的IP和端口。
?
c.?None模式
?
None 模式是比較特殊的一種容器網絡模式。
??
當我們執行docker run 命令并借助參數-net指定docker 容器的網絡模式為none模式時,新建出來的docker 容器將不會擁有自己的網絡命名空間,但也不是不為Docker 容器進行任何的網絡設置。嚴格說來在none模式下Docker 容器將會沒有網卡、不會分配IP地址、沒有路由等信息,需要我們根據自己的需要為自己的Docker 容器添加網卡信息、IP地址信息、路由信息等網絡基礎配置。
?
d.?Container模式
?
Container 模式也是一種比較特殊的模式,從名字也能看出來,這個模式下需要指定新創建的容器和一個已經存在額容器共享同一個網絡命名空間,而不是和容器所在的宿主機共享命名空間。
?
需要注意的是新創建的容器并不會創建自己的網卡,也不會分配IP地址,而是完全和那個已經制定的容器共享一樣的IP地址信息、端口范圍等。需要注意的是兩個容器雖然在網絡方面是共享的,但是在網絡之外的其他方面都是獨立的,比如文件系統、進程列表等仍然是隔離開的。
?
以上我們簡述了一下容器的幾種網絡模式,通過上面的簡介相信大家可以很清楚的看出四種網絡模式的區別。這幾種網絡模式沒有優劣之分,每一種都有自己適合的場景,但是在容器云場景中我們一般不建議將網絡模式設置為host模式,因為host模式下容器和容器所在的宿主機共享同一個網絡命名空間,在容器中可以看到宿主機上的所有的網絡設備,且容器中對宿主機上的這些網絡設備具有全部的訪問權限,因此每個用戶在容器中對網絡設備進行了修改會立即影響到同宿主機上的其他的容器的網絡。為此Docker 官方也提示我們,host模式是不安全的。但是如果是在隔離性比較好的環境中也是可以使用此種模式的,比如容器運行在虛擬機中,且每臺虛擬機上的容器都屬于同一個租戶。
?
(8)?目錄映射
?
容器使用中我們經常會遇到需要將容器中的數據寫到容器所在宿主機上的情況,比如有狀態的負載中運行了mysql數據庫,由于mysql數據庫中的數據很重要,且數據量隨著業務的增長會越來越大,這個時候我們一般會將容器中的mysql數據存放到mysql容器所在的宿主機上。
?
另外一種情況,比如我們有時我們會將宿主機上的一些公共的目錄映射到容器中,防止每個容器的鏡像中反復配置,比如dns配置文件等。
?
需要注意的是,一般我們不建議將宿主機上一些比較敏感的目錄映射到容器中,比如宿主機上的內核配置文件,網卡配置文件等,防止用戶在容器中對宿主機的關鍵配置進行篡改。
?
2.?容器鏡像安全
?
據國內知名安全廠商綠盟2018年3月的研究顯示,目前Docker Hub上的鏡像很多都存在安全漏洞。研究人員拉取了Docker Hub上下載量最大的前10頁的鏡像,對其做安全測試后發現這些熱門的鏡像中76%存在安全漏洞,其中有很多是我們經常使用的,比如httpd鏡像、nginx鏡像、MySQL鏡像等,可以說目前正在被企業使用的鏡像中很多是存在安全問題的。
?
?
?
?鏡像安全方面我們一般建議在鏡像倉庫的客戶端開啟認證機制,并且對下載的每一個容器鏡像都要進行安全檢查,比如通過CVE 數據庫同步掃描鏡像,一旦發現鏡像存在漏洞,建議及時通知用戶,或者直接中斷當前問題鏡像的構建,等待用戶處理漏洞。
?
3.?網絡安全
?
網絡安全涉及方方面面,細說起來可能會有一本書的內容,由于篇幅原因,在此我們只從網絡傳輸安全這個層面給大家提供幾條建議。
?
(1)?開啟認證
?
鏡像倉庫registry 一定要開啟認證方式,即使是在內網的環境下。如果不開啟認證,任何人在容器內部可以隨意的拉取、上傳鏡像,甚至可以隨意的篡改其他用戶的鏡像。
?
(2)?鏡像校驗
?
鏡像校驗用來保證鏡像的完整的di性,以防鏡像被意外篡改。Docker 鏡像倉庫中的每個鏡像都會對應一個mainifest文件,里面包含當前鏡像的一系列的屬性信息,其中就包括鏡像的校驗信息,可以根據鏡像文件內容計算出校驗和,然后與鏡像配置中ff ID進行比較,如果diff ID 不一致則說明鏡像可能已經被篡改,此時可以通過告警機制對用戶進行通知。
?
福利
掃描添加小編微信,備注“姓名+公司職位”,加入【云計算學習交流群】,和志同道合的朋友們共同打卡學習!
推薦閱讀:
如何快速深入理解監控知識? | 技術干貨
為什么說深耕AI領域繞不開知識圖譜?
ARM 發布新一代 CPU 和 GPU,實現 20% 性能提升!
比特幣沖到9000美元, 你就能找個好工作?
1000 萬個“AI 名師”:用機器算法“解剖”應試教育
阿里面試,我掛在了第四輪……
10個爬蟲工程師必備的工具了解一下
真香,朕在看了!
總結
以上是生活随笔為你收集整理的容器云常见安全威胁与防范 | 技术干货的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: win10电脑玩游戏卡顿怎么办 Win1
- 下一篇: Boost:以协程的方式实现带有默认值的