◆陳遠(yuǎn)崢 郭 岳
(中國移動(dòng)通信集團(tuán)浙江有限公司 浙江 310030)
關(guān)于容器和K8S的安全性與隔離的問題已經(jīng)被暴露過很多的BUG和漏洞,并引發(fā)了廣泛的討論。從根本來說,Docker使用了cgroup來做了運(yùn)行時(shí)隔離,從本質(zhì)而言,每一個(gè)Docker Host的容器,都是一個(gè)操作系統(tǒng)(OS)下的不同環(huán)境,但是仍然共享內(nèi)核,即使容器和K8S可以通過Namespace(命名空間)為安全邊界來實(shí)現(xiàn)租戶級(jí)別的隔離,但是還是無法解決安全隱患。
從整個(gè)社區(qū)來看,共用內(nèi)核的容器在安全隔離上還是比較弱。雖然內(nèi)核在不斷地增強(qiáng)自身的安全特性,但由于內(nèi)核自身代碼極端復(fù)雜,漏洞層出不窮。比較典型的是容器挖礦程序,利用某一個(gè)服務(wù)漏洞入侵容器環(huán)境,占用CPU資源進(jìn)行挖礦,并且在內(nèi)網(wǎng)中迅速蔓延、滲透,侵占數(shù)據(jù)中心資源,造成業(yè)務(wù)停滯。曾被爆出在Docker Hub上有17個(gè)容器鏡像帶有挖礦后門,這些鏡像一共被下載了500萬次[1],這個(gè)病毒在容器社區(qū)造成嚴(yán)重影響。
在企業(yè)內(nèi)部來說,我們歷經(jīng)多年的微服務(wù)化改造,目前在運(yùn)行的容器環(huán)境已經(jīng)初具規(guī)模,容器數(shù)量多,并且和虛擬機(jī)相比,容器的物理整合比更高,在幾百臺(tái)服務(wù)器的集群上就運(yùn)行了幾萬個(gè)容器。每個(gè)服務(wù)器原來就一個(gè)或幾個(gè)地址對(duì)外服務(wù),而運(yùn)行容器環(huán)境時(shí),每個(gè)服務(wù)器的容器對(duì)外訪問的需求大大增多,這樣一來整個(gè)集群所暴露的安全風(fēng)險(xiǎn)點(diǎn),也同樣放大了幾十倍,安全運(yùn)維難度也同比增大幾十倍。
通過幾年下來的容器運(yùn)維經(jīng)驗(yàn)積累,在容器安全方面,我們遇到了幾個(gè)較為棘手的難題:
業(yè)務(wù)微服務(wù)化拆分后,內(nèi)部的東西向的流量急劇放大,如何做好東西向的容器安全分級(jí)管控和安全隔離?
集群中有著來自不同業(yè)務(wù)域的容器應(yīng)用,如果想管理不同業(yè)務(wù)域的容器間的流量,目前還只能夠在硬件級(jí)進(jìn)行隔離,這樣所有的流量都不得不經(jīng)過硬件交換設(shè)備,增加容器環(huán)境的網(wǎng)絡(luò)復(fù)雜度,并且會(huì)形成“發(fā)夾效應(yīng)”,從而降低了數(shù)據(jù)傳輸效率,增加了網(wǎng)絡(luò)流量和硬件設(shè)備的傳輸壓力。
如CNCF的K8S容器平臺(tái)的安全最佳實(shí)踐文檔中[2]的第6條:創(chuàng)建和定義集群網(wǎng)絡(luò)策略的要求;和第7條:運(yùn)行集群范圍的Pod安全策略。都是要求從容器級(jí)別實(shí)現(xiàn)隔離或者打通等安全管控。能夠在不同業(yè)務(wù)的容器之間,按照既定規(guī)則-標(biāo)簽、地址、端口等限制,來實(shí)現(xiàn)網(wǎng)絡(luò)分段,實(shí)現(xiàn)策略化的安全隔離。
大規(guī)模的復(fù)雜業(yè)務(wù)域的容器環(huán)境該如何實(shí)現(xiàn)細(xì)顆粒度的安全隔離?
如前面所說,隨著物理服務(wù)器的CPU和內(nèi)存配置越來越高,一臺(tái)物理服務(wù)器上運(yùn)行的容器數(shù)量不斷增多,而物理機(jī)的業(yè)務(wù)網(wǎng)卡總數(shù)量和吞吐量有限,如果其中一個(gè)或幾個(gè)Pod占用服務(wù)器過高帶寬,造成了網(wǎng)絡(luò)帶寬資源不平衡,從而造成同服務(wù)器上其他所有的容器的吞吐受限,響應(yīng)時(shí)間變差。
針對(duì)業(yè)務(wù)激增或異常,如何將有效關(guān)鍵帶寬資源預(yù)留和限制,如何針對(duì)容器設(shè)置網(wǎng)絡(luò)的流量和帶寬管理,一直沒有良好精細(xì)化容器網(wǎng)絡(luò)QoS的手段。
容器平臺(tái)的容器數(shù)量越來越多,對(duì)外暴露的風(fēng)險(xiǎn)點(diǎn)也會(huì)成倍增加,一旦有一個(gè)容器被攻破,會(huì)嘗試做修改IP、嗅探內(nèi)部漏洞等動(dòng)作,繞過簡單的容器安全防護(hù),對(duì)其他容器業(yè)務(wù)、甚至虛擬機(jī)、物理機(jī)進(jìn)行內(nèi)部探測和破壞??梢?,當(dāng)攻擊行為成功繞過南北防火墻之后,對(duì)內(nèi)部造成的破壞會(huì)是非常巨大且很危險(xiǎn)。
不僅是攻破一個(gè)容器,前面描述的漏洞中還會(huì)可能通過攻破容器再獲取整個(gè)主機(jī)的管理權(quán)限,在整個(gè)網(wǎng)絡(luò)內(nèi)部做更深度的攻擊和破壞,如何能夠避免此類攻擊,一直是一個(gè)重要問題。
容器挖礦病毒的到處肆虐,利用多個(gè)軟件不同版本的各種漏洞,滲透到內(nèi)部環(huán)境,來注入挖礦木馬,并且在內(nèi)部網(wǎng)到處嗅探、傳染,此前的解決方法往往是發(fā)生了一次后,升級(jí)解決某個(gè)軟件版本的漏洞,刪除被感染環(huán)境的木馬程序,但是各個(gè)軟件升級(jí)調(diào)整又有新的漏洞以及源源不斷的新木馬變種,層出不窮。希望能找到一種有效的方法來避免此類問題的發(fā)生。
在數(shù)據(jù)中心發(fā)展多年以來,現(xiàn)有網(wǎng)絡(luò)環(huán)境有各種安全管理手段,但是容器作為一個(gè)新興環(huán)境,是獨(dú)立于其他資源池獨(dú)立存在。容器池功能都還在小規(guī)模測試、試用階段,對(duì)于容器資源池的安全,業(yè)內(nèi)考慮不多,都以單獨(dú)組網(wǎng),做物理的南北向管理為主。
Docker容器默認(rèn)可以配置基本的網(wǎng)絡(luò)組件,但是還遠(yuǎn)遠(yuǎn)不夠。CNCF(cloud native computing foundation)創(chuàng)建了一個(gè)統(tǒng)一的網(wǎng)絡(luò)框架CNI(container network interface)來規(guī)范網(wǎng)絡(luò)插件接口,讓容器運(yùn)行時(shí)與插件進(jìn)行協(xié)作。目前流行的網(wǎng)絡(luò)插件主要有:Flannel、Calico、Macvlan 和 NSX-T。
K8S的網(wǎng)絡(luò)功能:
K8S自身設(shè)立了租戶-Namespace來進(jìn)行資源分配和管理,但是每個(gè)租戶內(nèi)地址是雜亂無章的,并且租戶之間網(wǎng)絡(luò)完全互通。各個(gè)節(jié)點(diǎn)Node內(nèi)所有pod的南北向流量都需要NAT成節(jié)點(diǎn)地址,無法基于租戶運(yùn)維和進(jìn)行安全策略控制
Flannel開源網(wǎng)絡(luò)優(yōu)缺點(diǎn):
優(yōu)點(diǎn):Flannel采用etcd實(shí)現(xiàn)Ip地址的統(tǒng)一管理,避免集群Scale out導(dǎo)致的Ip地址沖突等問題,并且節(jié)點(diǎn)node之間配置overlay網(wǎng)絡(luò),集群的Scale out無須配置外部物理網(wǎng)絡(luò)。
缺點(diǎn):
(1)在Flannel的網(wǎng)絡(luò)中租戶NameSpace和網(wǎng)絡(luò)之間無對(duì)應(yīng)關(guān)系;
(2)缺乏基于容器顆粒度的安全管控;
(3)不支持Network policy;
(4)南北向流量需要基于節(jié)點(diǎn)node做nat;
(5)缺乏路徑跟蹤、QOS、SPAN/netflow、可視化等端到端運(yùn)維能力;
(6)更為重要的是基于iptable的東西向負(fù)載均衡,性能無法滿足生產(chǎn)業(yè)務(wù)的需求;
(7)南北向負(fù)載均衡需要借助其他第三方開源軟件;
(8)開源網(wǎng)絡(luò)的可靠性和服務(wù)支持嚴(yán)重不足。
Calico開源網(wǎng)絡(luò)優(yōu)缺點(diǎn):
優(yōu)點(diǎn):基于Calico的容器網(wǎng)絡(luò)配置簡單,通過 BGP主機(jī)路由實(shí)現(xiàn)Pod的網(wǎng)絡(luò)連接支持跨節(jié)點(diǎn)的路由模式,支持Network Policy。
缺點(diǎn):相較企業(yè)級(jí)容器網(wǎng)絡(luò)其不足非常明顯。
(1)NameSpace和網(wǎng)絡(luò)之間無對(duì)應(yīng)關(guān)系,無法基于租戶進(jìn)行邏輯網(wǎng)絡(luò)的定義和邊界映射;
(2)南北向缺省情況下需要基于節(jié)點(diǎn)node做NAT;
(3)Network配置運(yùn)維功能不足;
(4)缺乏全面的容器顆粒度的安全管控;
(5)缺乏端到端運(yùn)維:路徑跟蹤、QOS、SPAN/netflow、可視化等;
(6)更為重要的是基于iptable的東西向負(fù)載均衡,性能無法滿足生產(chǎn)業(yè)務(wù)的需求;
(7)南北向負(fù)載均衡需要借助其他第三方開源軟件;
(8)開源網(wǎng)絡(luò)的可靠性和服務(wù)支持嚴(yán)重不足。
Macvlan開源網(wǎng)絡(luò)優(yōu)缺點(diǎn):
優(yōu)點(diǎn):基于Macvlan的容器網(wǎng)絡(luò)配置簡單,通過子接口實(shí)現(xiàn)Pod的網(wǎng)絡(luò)連接支持跨節(jié)點(diǎn)的路由模式,無須每個(gè)節(jié)點(diǎn)配置NAT。
缺點(diǎn):
(1)節(jié)點(diǎn)擴(kuò)展時(shí),外部物理網(wǎng)絡(luò)手動(dòng)修改路由;
(2)沒有統(tǒng)一IP地址管理,節(jié)點(diǎn)的擴(kuò)展很容易造成Ip地址的沖突;
(3)NameSpace和網(wǎng)絡(luò)之間無對(duì)應(yīng)關(guān)系,無法基于租戶進(jìn)行邏輯網(wǎng)絡(luò)的定義和邊界映射;
(4)缺乏基于容器顆粒度的安全管控;
(5)缺乏端到端運(yùn)維:路徑跟蹤、QOS、SPAN/netflow、可視化等;
(6)基于iptable的東西向負(fù)載均衡無法生產(chǎn)業(yè)務(wù)的需求;
(7)南北向負(fù)載均衡需要借助其他第三方開源軟件;
(8)開源網(wǎng)絡(luò)的可靠性和服務(wù)支持嚴(yán)重不足。
Flannel、Calico、Macvlan都能夠提供基本的容器網(wǎng)絡(luò)連接,但是普遍問題是東西向的Iptable的低下的效率和性能,對(duì)于生產(chǎn)環(huán)境是一大瓶頸;缺乏南北向負(fù)載均衡,缺乏全面安全管控,缺乏可視化運(yùn)維工具和可靠的支持。這幾個(gè)開源組件目前都無法解決當(dāng)前已經(jīng)遇到的容器網(wǎng)絡(luò)安全問題。
NSX-T作為商業(yè)數(shù)據(jù)中心網(wǎng)絡(luò)和安全組件,經(jīng)過多輪測試和使用,我們發(fā)現(xiàn),NSX-T可以針對(duì)每個(gè)Namespace分配一個(gè)交換機(jī)環(huán)境,分配內(nèi)網(wǎng)or外網(wǎng)地址段,來實(shí)現(xiàn)業(yè)務(wù)容器的微分段,根據(jù)業(yè)務(wù)的屬性定義標(biāo)簽,通過安全五元組來實(shí)現(xiàn)訪問與控制策略,并且將容器直接互相訪問的端到端可視化,迅速定位網(wǎng)絡(luò)訪問的故障和問題,實(shí)現(xiàn)快速排障。
容器網(wǎng)絡(luò)一直是K8S中的弱項(xiàng),雖然有多種開源的容器網(wǎng)絡(luò)工具,但是功能全、安全可靠、方便運(yùn)維的網(wǎng)絡(luò)工具一直比較缺乏。經(jīng)過一系列的對(duì)比和功能調(diào)試,我們選用了NSX-T軟件定義網(wǎng)絡(luò)軟件,目前是K8S容器平臺(tái)的非常強(qiáng)大的組件,除了很好的支持容器網(wǎng)絡(luò),還能打通VM、裸機(jī)、KVM等多資源池的網(wǎng)絡(luò)環(huán)境。接下來詳細(xì)介紹下,NSX-T如何解決上面提出的兩個(gè)容器網(wǎng)絡(luò)難題。
首先,NSX-T和K8S的API server深度集成,在通過kubectl命令創(chuàng)建Namespace時(shí),NSX-T會(huì)自動(dòng)分配獨(dú)立的路由器、地址段,如下圖1所示。這樣基于容器應(yīng)用安全的要求,可以基于單個(gè)Pod或一組Pod進(jìn)行網(wǎng)絡(luò)的微分段。
圖1 容器分段1
然后是控制業(yè)務(wù)網(wǎng)絡(luò)的路由策略,將來自不同業(yè)務(wù)的容器,如CRM和BOSS應(yīng)用,按照標(biāo)簽對(duì)應(yīng)用分類標(biāo)記,或Network Policy(k8s 1.7發(fā)布功能),如圖2、圖3來為容器細(xì)致分段。
圖2 容器細(xì)致分段2
圖3 容器細(xì)致分段3
最后,通過定制安全規(guī)則,指定源、目的、服務(wù)類別、動(dòng)作、實(shí)施范圍的五元組,來實(shí)現(xiàn)網(wǎng)絡(luò)的精細(xì)流向限制、端口限制等高級(jí)策略和精細(xì)化管理,訪問規(guī)則既可以提前預(yù)定,也可以用命令實(shí)時(shí)創(chuàng)建,如圖4。流量管理在物理機(jī)的網(wǎng)卡層即可實(shí)現(xiàn)控制,既可以減少需要屏蔽的流量對(duì)于網(wǎng)絡(luò)的影響,又能增加數(shù)據(jù)傳輸與交換的效率,減少‘發(fā)夾效應(yīng)’。這樣在k8s管理的容器集群內(nèi)部就能實(shí)現(xiàn)流量安全管控與隔離。并且,NSX-T還能夠建立跨容器、虛擬機(jī)、KVM、裸機(jī)等不同狀態(tài)的應(yīng)用使用統(tǒng)一的安全策略的集中管控,這個(gè)在后續(xù)文章中詳細(xì)探討。
NSX-T可以根據(jù)業(yè)務(wù)需要基于每個(gè)pod的端口進(jìn)行入向或出向端口的流量限速,以保證不同應(yīng)用訪問的服務(wù)質(zhì)量,同時(shí)也可以對(duì)每個(gè)POD端口的廣播流量進(jìn)行入口限速,如圖5、圖6。另外也可以根據(jù)需要對(duì)每個(gè)POD端口進(jìn)行DSCP或CoS值的設(shè)定。這樣針對(duì)突發(fā)業(yè)務(wù)激增或異常,可以有效管理帶寬資源預(yù)留和限制。
網(wǎng)絡(luò)的攻擊常會(huì)從安全重視程度不高的邊緣、非核心業(yè)務(wù)入手,容器一旦被攻破,攻擊會(huì)嘗試各種辦法來突破防御。對(duì)于嘗試更改IP地址的攻擊行為,NSX-T使用Spoofguard功能,維護(hù)容器名稱和 IP地址的引用表來防止 IP欺騙,如圖7。在容器的初始啟動(dòng)過程中,用檢索到的信息填充它與每個(gè)容器的IP地址,可阻止未知的虛擬機(jī)發(fā)送或接受流量,大大提高了容器網(wǎng)絡(luò)的整體安全性。
圖4 安全規(guī)則
圖5 應(yīng)用場景
圖6 測試結(jié)果
容器挖礦病毒,例如minerd挖礦程序。利用Jenkins、Redis等中間件的漏洞發(fā)起攻擊,獲得root權(quán)限,植入挖礦木馬,消耗CPU、GPU資源來進(jìn)行挖礦,并且利用masscan端口掃描特定端口如TCP 2375和2376,來獲取可以通訊的服務(wù)器進(jìn)行傳染。了解了基本原理可以進(jìn)行一步步的容器環(huán)境安全加固:
(1)在整個(gè)容器集群,屏蔽常見的挖礦網(wǎng)站的服務(wù)器地址列表;
(2)限定可以連接如Redis服務(wù)器的IP范圍,只有特定的地址可以訪問,減少對(duì)外暴露,并修改redis的默認(rèn)端口6379;
(3)容器集群封堵高風(fēng)險(xiǎn)端口,如TCP 2375和2376等;
(4)嚴(yán)格限定同業(yè)務(wù)域以及不同業(yè)務(wù)域的容器之間的訪問規(guī)則,如限制訪問來源為特定的IP地址加上特定端口。
圖7 防止容器的IP地址假冒攻擊
總的來說如果容器被攻擊,流量已經(jīng)被NSX-T的安全隔離的微分段策略進(jìn)行了訪問限制、端口限制等嚴(yán)格管理;如果嘗試手工修改地址來嘗試在內(nèi)部進(jìn)行掃描和攻擊,由于容器地址假冒被策略禁止,可以解決這個(gè)隱患;如果宿主機(jī)權(quán)限因?yàn)楫惓1挥脩臬@取,并更新了主機(jī)信息,假冒一個(gè)新的主機(jī)來嘗試內(nèi)部攻擊,NSX-T也能很好解決,因?yàn)橹鳈C(jī)的流量都是通過NSX-T的overlay來管理,新的主機(jī)網(wǎng)絡(luò)無法在NSX-T環(huán)境中合法注冊,因而無法獲得在業(yè)務(wù)網(wǎng)絡(luò)中運(yùn)行的權(quán)限。
針對(duì)容器網(wǎng)絡(luò)的安全問題,結(jié)合了商業(yè)化的容器網(wǎng)絡(luò)組件NSX-T,解決了前期困擾許久的容器網(wǎng)絡(luò)安全隱患,實(shí)現(xiàn)了容器環(huán)境微分段管理,精細(xì)化控制管理容器環(huán)境內(nèi)部東西向流量,加強(qiáng)了容器網(wǎng)絡(luò)安全邊界,有效預(yù)防了容器被攻擊,控制了容器被攻破后的影響訪問,在當(dāng)前數(shù)據(jù)中心中建立了一個(gè)安全可靠的容器環(huán)境。