關(guān)于容器網(wǎng)絡(luò)安全困境的路徑探析

◆陳遠(yuǎn)崢 郭 岳

（中國移動通信集團(tuán)浙江有限公司 浙江 310030）

1 K8S環(huán)境下的容器網(wǎng)絡(luò)與安全

1.1 安全風(fēng)險

關(guān)于容器和K8S的安全性與隔離的問題已經(jīng)被暴露過很多的BUG和漏洞，并引發(fā)了廣泛的討論。從根本來說，Docker使用了cgroup來做了運(yùn)行時隔離，從本質(zhì)而言，每一個Docker Host的容器，都是一個操作系統(tǒng)（OS）下的不同環(huán)境，但是仍然共享內(nèi)核，即使容器和K8S可以通過Namespace（命名空間）為安全邊界來實(shí)現(xiàn)租戶級別的隔離，但是還是無法解決安全隱患。

從整個社區(qū)來看，共用內(nèi)核的容器在安全隔離上還是比較弱。雖然內(nèi)核在不斷地增強(qiáng)自身的安全特性，但由于內(nèi)核自身代碼極端復(fù)雜，漏洞層出不窮。比較典型的是容器挖礦程序，利用某一個服務(wù)漏洞入侵容器環(huán)境，占用CPU資源進(jìn)行挖礦，并且在內(nèi)網(wǎng)中迅速蔓延、滲透，侵占數(shù)據(jù)中心資源，造成業(yè)務(wù)停滯。曾被爆出在Docker Hub上有17個容器鏡像帶有挖礦后門，這些鏡像一共被下載了500萬次[1]，這個病毒在容器社區(qū)造成嚴(yán)重影響。

在企業(yè)內(nèi)部來說，我們歷經(jīng)多年的微服務(wù)化改造，目前在運(yùn)行的容器環(huán)境已經(jīng)初具規(guī)模，容器數(shù)量多，并且和虛擬機(jī)相比，容器的物理整合比更高，在幾百臺服務(wù)器的集群上就運(yùn)行了幾萬個容器。每個服務(wù)器原來就一個或幾個地址對外服務(wù)，而運(yùn)行容器環(huán)境時，每個服務(wù)器的容器對外訪問的需求大大增多，這樣一來整個集群所暴露的安全風(fēng)險點(diǎn)，也同樣放大了幾十倍，安全運(yùn)維難度也同比增大幾十倍。

2 容器安全問題分析

通過幾年下來的容器運(yùn)維經(jīng)驗(yàn)積累，在容器安全方面，我們遇到了幾個較為棘手的難題：

2.1 如何進(jìn)行容器的精確安全隔離

業(yè)務(wù)微服務(wù)化拆分后，內(nèi)部的東西向的流量急劇放大，如何做好東西向的容器安全分級管控和安全隔離？

集群中有著來自不同業(yè)務(wù)域的容器應(yīng)用，如果想管理不同業(yè)務(wù)域的容器間的流量，目前還只能夠在硬件級進(jìn)行隔離，這樣所有的流量都不得不經(jīng)過硬件交換設(shè)備，增加容器環(huán)境的網(wǎng)絡(luò)復(fù)雜度，并且會形成“發(fā)夾效應(yīng)”，從而降低了數(shù)據(jù)傳輸效率，增加了網(wǎng)絡(luò)流量和硬件設(shè)備的傳輸壓力。

如CNCF的K8S容器平臺的安全最佳實(shí)踐文檔中[2]的第6條：創(chuàng)建和定義集群網(wǎng)絡(luò)策略的要求；和第7條：運(yùn)行集群范圍的Pod安全策略。都是要求從容器級別實(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ì)顆粒度的安全隔離？

2.2 如何實(shí)現(xiàn)容器的精細(xì)化流量控制

如前面所說，隨著物理服務(wù)器的CPU和內(nèi)存配置越來越高，一臺物理服務(wù)器上運(yùn)行的容器數(shù)量不斷增多，而物理機(jī)的業(yè)務(wù)網(wǎng)卡總數(shù)量和吞吐量有限，如果其中一個或幾個Pod占用服務(wù)器過高帶寬，造成了網(wǎng)絡(luò)帶寬資源不平衡，從而造成同服務(wù)器上其他所有的容器的吞吐受限，響應(yīng)時間變差。

針對業(yè)務(wù)激增或異常，如何將有效關(guān)鍵帶寬資源預(yù)留和限制，如何針對容器設(shè)置網(wǎng)絡(luò)的流量和帶寬管理，一直沒有良好精細(xì)化容器網(wǎng)絡(luò)QoS的手段。

2.3 如何防止容器的IP地址假冒攻擊

容器平臺的容器數(shù)量越來越多，對外暴露的風(fēng)險點(diǎn)也會成倍增加，一旦有一個容器被攻破，會嘗試做修改IP、嗅探內(nèi)部漏洞等動作，繞過簡單的容器安全防護(hù)，對其他容器業(yè)務(wù)、甚至虛擬機(jī)、物理機(jī)進(jìn)行內(nèi)部探測和破壞。可見，當(dāng)攻擊行為成功繞過南北防火墻之后，對內(nèi)部造成的破壞會是非常巨大且很危險。

不僅是攻破一個容器，前面描述的漏洞中還會可能通過攻破容器再獲取整個主機(jī)的管理權(quán)限，在整個網(wǎng)絡(luò)內(nèi)部做更深度的攻擊和破壞，如何能夠避免此類攻擊，一直是一個重要問題。

2.4 如何防止容器挖礦類型病毒

容器挖礦病毒的到處肆虐，利用多個軟件不同版本的各種漏洞，滲透到內(nèi)部環(huán)境，來注入挖礦木馬，并且在內(nèi)部網(wǎng)到處嗅探、傳染，此前的解決方法往往是發(fā)生了一次后，升級解決某個軟件版本的漏洞，刪除被感染環(huán)境的木馬程序，但是各個軟件升級調(diào)整又有新的漏洞以及源源不斷的新木馬變種，層出不窮。希望能找到一種有效的方法來避免此類問題的發(fā)生。

3 開源容器網(wǎng)絡(luò)組件的現(xiàn)狀

在數(shù)據(jù)中心發(fā)展多年以來，現(xiàn)有網(wǎng)絡(luò)環(huán)境有各種安全管理手段，但是容器作為一個新興環(huán)境，是獨(dú)立于其他資源池獨(dú)立存在。容器池功能都還在小規(guī)模測試、試用階段，對于容器資源池的安全，業(yè)內(nèi)考慮不多，都以單獨(dú)組網(wǎng)，做物理的南北向管理為主。

Docker容器默認(rèn)可以配置基本的網(wǎng)絡(luò)組件，但是還遠(yuǎn)遠(yuǎn)不夠。CNCF（cloud native computing foundation）創(chuàng)建了一個統(tǒng)一的網(wǎng)絡(luò)框架CNI（container network interface）來規(guī)范網(wǎng)絡(luò)插件接口，讓容器運(yùn)行時與插件進(jìn)行協(xié)作。目前流行的網(wǎng)絡(luò)插件主要有：Flannel、Calico、Macvlan 和 NSX-T。

K8S的網(wǎng)絡(luò)功能：

K8S自身設(shè)立了租戶-Namespace來進(jìn)行資源分配和管理，但是每個租戶內(nèi)地址是雜亂無章的，并且租戶之間網(wǎng)絡(luò)完全互通。各個節(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ò)之間無對應(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è)級容器網(wǎng)絡(luò)其不足非常明顯。

（1）NameSpace和網(wǎng)絡(luò)之間無對應(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)的路由模式，無須每個節(jié)點(diǎn)配置NAT。

缺點(diǎn)：

（1）節(jié)點(diǎn)擴(kuò)展時，外部物理網(wǎng)絡(luò)手動修改路由；

（2）沒有統(tǒng)一IP地址管理，節(jié)點(diǎn)的擴(kuò)展很容易造成Ip地址的沖突；

（3）NameSpace和網(wǎng)絡(luò)之間無對應(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的低下的效率和性能，對于生產(chǎn)環(huán)境是一大瓶頸；缺乏南北向負(fù)載均衡，缺乏全面安全管控，缺乏可視化運(yùn)維工具和可靠的支持。這幾個開源組件目前都無法解決當(dāng)前已經(jīng)遇到的容器網(wǎng)絡(luò)安全問題。

NSX-T作為商業(yè)數(shù)據(jù)中心網(wǎng)絡(luò)和安全組件，經(jīng)過多輪測試和使用，我們發(fā)現(xiàn)，NSX-T可以針對每個Namespace分配一個交換機(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)快速排障。

4 解決方法

容器網(wǎng)絡(luò)一直是K8S中的弱項(xiàng)，雖然有多種開源的容器網(wǎng)絡(luò)工具，但是功能全、安全可靠、方便運(yùn)維的網(wǎng)絡(luò)工具一直比較缺乏。經(jīng)過一系列的對比和功能調(diào)試，我們選用了NSX-T軟件定義網(wǎng)絡(luò)軟件，目前是K8S容器平臺的非常強(qiáng)大的組件，除了很好的支持容器網(wǎng)絡(luò)，還能打通VM、裸機(jī)、KVM等多資源池的網(wǎng)絡(luò)環(huán)境。接下來詳細(xì)介紹下，NSX-T如何解決上面提出的兩個容器網(wǎng)絡(luò)難題。

4.1 容器的安全隔離

首先，NSX-T和K8S的API server深度集成，在通過kubectl命令創(chuàng)建Namespace時，NSX-T會自動分配獨(dú)立的路由器、地址段，如下圖1所示。這樣基于容器應(yīng)用安全的要求，可以基于單個Pod或一組Pod進(jìn)行網(wǎng)絡(luò)的微分段。

圖1 容器分段1

然后是控制業(yè)務(wù)網(wǎng)絡(luò)的路由策略，將來自不同業(yè)務(wù)的容器，如CRM和BOSS應(yīng)用，按照標(biāo)簽對應(yīng)用分類標(biāo)記，或Network Policy（k8s 1.7發(fā)布功能），如圖2、圖3來為容器細(xì)致分段。

圖2 容器細(xì)致分段2

圖3 容器細(xì)致分段3

最后，通過定制安全規(guī)則，指定源、目的、服務(wù)類別、動作、實(shí)施范圍的五元組，來實(shí)現(xiàn)網(wǎng)絡(luò)的精細(xì)流向限制、端口限制等高級策略和精細(xì)化管理，訪問規(guī)則既可以提前預(yù)定，也可以用命令實(shí)時創(chuàng)建，如圖4。流量管理在物理機(jī)的網(wǎng)卡層即可實(shí)現(xiàn)控制，既可以減少需要屏蔽的流量對于網(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)一的安全策略的集中管控，這個在后續(xù)文章中詳細(xì)探討。

4.2 容器的精細(xì)化流量控制

NSX-T可以根據(jù)業(yè)務(wù)需要基于每個pod的端口進(jìn)行入向或出向端口的流量限速，以保證不同應(yīng)用訪問的服務(wù)質(zhì)量，同時也可以對每個POD端口的廣播流量進(jìn)行入口限速，如圖5、圖6。另外也可以根據(jù)需要對每個POD端口進(jìn)行DSCP或CoS值的設(shè)定。這樣針對突發(fā)業(yè)務(wù)激增或異常，可以有效管理帶寬資源預(yù)留和限制。

4.3 防止容器的IP地址假冒攻擊

網(wǎng)絡(luò)的攻擊常會從安全重視程度不高的邊緣、非核心業(yè)務(wù)入手，容器一旦被攻破，攻擊會嘗試各種辦法來突破防御。對于嘗試更改IP地址的攻擊行為，NSX-T使用Spoofguard功能，維護(hù)容器名稱和 IP地址的引用表來防止 IP欺騙，如圖7。在容器的初始啟動過程中，用檢索到的信息填充它與每個容器的IP地址，可阻止未知的虛擬機(jī)發(fā)送或接受流量，大大提高了容器網(wǎng)絡(luò)的整體安全性。

圖4 安全規(guī)則

圖5 應(yīng)用場景

圖6 測試結(jié)果

4.4 容器挖礦病毒處理

容器挖礦病毒，例如minerd挖礦程序。利用Jenkins、Redis等中間件的漏洞發(fā)起攻擊，獲得root權(quán)限，植入挖礦木馬，消耗CPU、GPU資源來進(jìn)行挖礦，并且利用masscan端口掃描特定端口如TCP 2375和2376，來獲取可以通訊的服務(wù)器進(jìn)行傳染。了解了基本原理可以進(jìn)行一步步的容器環(huán)境安全加固：

（1）在整個容器集群，屏蔽常見的挖礦網(wǎng)站的服務(wù)器地址列表；

（2）限定可以連接如Redis服務(wù)器的IP范圍，只有特定的地址可以訪問，減少對外暴露，并修改redis的默認(rèn)端口6379；

（3）容器集群封堵高風(fēng)險端口，如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)行掃描和攻擊，由于容器地址假冒被策略禁止，可以解決這個隱患；如果宿主機(jī)權(quán)限因?yàn)楫惓１挥脩臬@取，并更新了主機(jī)信息，假冒一個新的主機(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)限。

5 結(jié)論

針對容器網(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ù)中心中建立了一個安全可靠的容器環(huán)境。