一、云原生的技術(shù)背景

當(dāng)前，數(shù)字化變革已逐漸滲透到每一個具體產(chǎn)業(yè)，彈性算力已成為各行各業(yè)的“水電煤”，云計(jì)算則成為數(shù)字化世界的基石，從底層驅(qū)動產(chǎn)業(yè)變革。隨著云計(jì)算發(fā)展進(jìn)入成熟階段，以“生在云上、長在云上”為核心理念的云原生技術(shù)被視為云計(jì)算未來十年的重要發(fā)展方向。在數(shù)字化大潮中，上云并非是一種時尚，而是一種剛需，從“上云”到“全面上云”，從“云化”到“云原生化”，是企業(yè)數(shù)字化轉(zhuǎn)型的必由之路。

相較傳統(tǒng) IT 架構(gòu)，云原生具有無法比擬的優(yōu)勢，將為企業(yè)帶來降低成本、提升效率、快速試錯、促進(jìn)創(chuàng)新等業(yè)務(wù)增益價(jià)值。

云原生的技術(shù)理念始于 Netflix 等廠商從 2009 年起在公有云上的開發(fā)和部署實(shí)踐。2015年云原生計(jì)算基金會（CNCF）成立，標(biāo)志著云原生從技術(shù)理念轉(zhuǎn)化為開源實(shí)現(xiàn)。云原生的代表技術(shù)包括容器、服務(wù)網(wǎng)格、微服務(wù)、不可變基礎(chǔ)設(shè)施和聲明式 API。這些技術(shù)能夠構(gòu)建容錯性好、易于管理和便于觀察的松耦合系統(tǒng)。結(jié)合可靠的自動化手段，云原生技術(shù)使工程師能夠輕松地對系統(tǒng)作出頻繁和可預(yù)測的重大變更。

云原生的運(yùn)用使本身復(fù)雜多變的企業(yè)業(yè)務(wù)可敏捷靈活、及時響應(yīng)、快速迭代，從而讓數(shù)字化轉(zhuǎn)型和運(yùn)營過程中的持續(xù)創(chuàng)新成為可能。目前業(yè)界較為認(rèn)可的構(gòu)成云原生的四大核心技術(shù)要素是微服務(wù)、DevOps、持續(xù)交付和容器化。

二、云原生環(huán)境的網(wǎng)絡(luò)隔離訴求

原生技術(shù)能夠有效解決傳統(tǒng)云實(shí)踐中應(yīng)用升級緩慢、架構(gòu)臃腫、無法快速迭代等“痛點(diǎn)”問題，并為業(yè)務(wù)創(chuàng)新提供動力。然而，云原生技術(shù)在創(chuàng)造效益的同時，也面臨著切實(shí)存在日益嚴(yán)峻的安全風(fēng)險(xiǎn)。

例如，2018年特斯拉AWS上部署的K8S Dashboard暴露在公網(wǎng)，沒有做認(rèn)證和授權(quán)控制，也沒有對網(wǎng)絡(luò)訪問做控制，黑客直接從dashboard中獲取S3憑證，從而獲取遙測數(shù)據(jù)，惡意拉取POD，進(jìn)行挖礦行為。

而“隔離”技術(shù)是最早、最基礎(chǔ)、也始終是最為核心的安全技術(shù)手段之一。Gartner 提出的容器安全控制分層理論，將容器安全能力按照優(yōu)先級由高至低分為基礎(chǔ)控制（Foundational Controls）、基本控制（Basic Controls）和基于風(fēng)險(xiǎn)的控制（Risk-Based Controls），其中網(wǎng)絡(luò)隔離（L3 Network Segmentation）被劃分為必備的基礎(chǔ)控制能力。

CNCF 于 2021 年發(fā)布的《云原生安全白皮書》指出，作為微服務(wù)部署的容器化應(yīng)用程序的邊界就是微服務(wù)本身。因此，有必要設(shè)定策略，只允許在得到許可的微服務(wù)間進(jìn)行通信。

在微服務(wù)架構(gòu)中引入零信任，可以在一個微服務(wù)被攻陷時阻止其橫向移動，從而縮小影響范圍。運(yùn)維人員應(yīng)確保他們正在使用網(wǎng)絡(luò)策略等功能，確保一個容器部署內(nèi)的東西向網(wǎng)絡(luò)通信只限于授權(quán)網(wǎng)絡(luò)。

三、傳統(tǒng)防火墻在云原生中的捉襟見肘

基于所承載業(yè)務(wù)的屬性和安全級別，傳統(tǒng)數(shù)據(jù)中心往往將其內(nèi)部劃分為多個安全域并進(jìn)行定制化的安全管理，在安全域間通常會部署防火墻系統(tǒng)實(shí)現(xiàn)訪問控制。在云平臺建設(shè)初期，此類架構(gòu)被相當(dāng)一部分用戶繼續(xù)采用，并利用防火墻實(shí)施域間的訪問控制策略，一些管理水平較高的用戶則基于訪問源和目的 IP 進(jìn)行了細(xì)粒度的策略規(guī)則設(shè)定。

然而，隨著云平臺向云原生架構(gòu)演進(jìn)遷移，基于防火墻進(jìn)行域間控制已顯得與云原生環(huán)境格格不入，無法真正滿足容器平臺的隔離需求。

防火墻的部署位置和控制對象決定了其僅能針對跨域流量進(jìn)行控制，而無法實(shí)現(xiàn)更細(xì)粒度的業(yè)務(wù)級、工作負(fù)載級控制。此外，鑒于策略規(guī)模對防火墻性能的影響，其安全策略的控制對象往往僅能做到網(wǎng)段級。因此，確切來說，此類方案至多能夠提供用于維護(hù)數(shù)據(jù)中心基礎(chǔ)架構(gòu)完整性的“宏分段（Macro-Segmentation）”，而無法實(shí)現(xiàn)云原生環(huán)境中真正所需的“微隔離（Micro-Segmentation）”。

此外，穩(wěn)定不變的 IP 地址是防火墻訪問控制持續(xù)生效的“錨點(diǎn)”，而在云原生環(huán)境中，容器 IP 的頻繁無規(guī)律變化則徹底動搖了傳統(tǒng)架構(gòu)中這一確定因素，一旦容器開始新的生命周期，新的 IP 將直接逃逸原有靜態(tài)策略的有效管控。與此同時，由于容器的消亡與新建在云原生環(huán)境中是高頻發(fā)生的，即便能夠?qū)崟r感知其變化，依靠人工刪除原有策略并建立新的策略也毫無可能，而已失效的策略長時間堆積，又勢必帶來防火墻系統(tǒng)策略冗余、性能下降的副作用。

云原生環(huán)境中，微服務(wù)的架構(gòu)勢必指數(shù)級的增加服務(wù)間的互訪調(diào)用情況和橫向連接關(guān)系，給原本就復(fù)雜度較高的東西向流量控制又帶來了新的難度。在 DevOps 的加持下，應(yīng)用敏捷、快速、持續(xù)交付部署，而安全控制措施則必須找到合適的切入點(diǎn)，并跟上瞬息萬變的節(jié)奏。

容器成為新的最小控制單元，其生命周期規(guī)律則更加難尋，每次新業(yè)務(wù)上線、應(yīng)用更新、擴(kuò)縮容等，均會帶來容器的消亡和新建，而在此過程中傳統(tǒng)用于標(biāo)識基礎(chǔ)設(shè)施的 IP、主機(jī)名等均將發(fā)生變化，傳統(tǒng)的安全策略框架則將被輕易繞過逃逸。

由此看來，即便放棄用防火墻實(shí)現(xiàn)集群內(nèi)流量微隔離的預(yù)期，其在云原生環(huán)境中也難以起到集群間流量的有效隔離控制作用，在云原生架構(gòu)下甚至已經(jīng)失去了原先的部署位置。事實(shí)上，開始規(guī)模化部署容器的用戶，往往在第一時間即發(fā)現(xiàn)了防火墻系統(tǒng)幾乎徹底失效的問題，從而釋放出更為迫切的隔離控制需求。

四、現(xiàn)有容器云平臺隔離方案分析

1.基于 Network Policy 的容器隔離

防火墻因“水土不服”而在云原生環(huán)境下徹底失效，再次鮮活證明了“安全原生化”對于云原生環(huán)境的重要性。事實(shí)上，已成為容器編排平臺事實(shí)標(biāo)準(zhǔn)的 Kubernetes（以下簡稱“K8S”），通過集成 Network Policy 功能提供了容器間的網(wǎng)絡(luò)隔離能力。

在 K8S 中，Network Policy 定義了一組 Pod 之間的訪問控制規(guī)范，其通過 Label 指定Namespace 和 Pod，并利用節(jié)點(diǎn)（Node）主機(jī)操作系統(tǒng)的 IPTABLES 實(shí)現(xiàn) Namespace 和Pod 級的網(wǎng)絡(luò)訪問控制。

與外掛式的防火墻相比，Network Policy 實(shí)現(xiàn)了原生化的安全能力內(nèi)嵌，但大量實(shí)踐表明，對于多數(shù)用戶而言其運(yùn)用落地依然受到較大制約，存在以下突出問題：

1)環(huán)境適應(yīng)性的局限

Network Policy 只定義了策略規(guī)則的規(guī)范，而訪問控制能力的具體實(shí)現(xiàn)則需依賴 K8S 平臺的網(wǎng)絡(luò)插件。事實(shí)上，當(dāng)前流行的 K8S 網(wǎng)絡(luò)插件中，并非所有均支持 Network Policy 功能。例如相當(dāng)一部分用戶使用的 Flannel 插件即無法支持該項(xiàng)功能，而對于多數(shù)用戶而言，為了實(shí)現(xiàn) Network Policy 能力而替換遷移原網(wǎng)絡(luò)插件的成本無疑是高昂的。

此外，一套 Network Policy 策略僅能適用于一個獨(dú)立的 K8S 集群，對于普遍具有多套K8S 集群的用戶而言，期望利用 Network Policy 實(shí)現(xiàn)全局管理，則必須進(jìn)行更為復(fù)雜的定制開發(fā)，其實(shí)現(xiàn)難度和管理成本令多數(shù)用戶望塵莫及。

2)規(guī)?；芾黼y度大

Network Policy 僅在商用版才提供了流量可視化能力，對于開源版用戶而言，不得不在未了解流量關(guān)系的情況下“盲配”安全策略，準(zhǔn)確性和效率將大大降低，且隨著管理規(guī)模的增大，定制貼合業(yè)務(wù)、符合最小特權(quán)原則的安全策略則越來越不可能。

同時，在規(guī)模較大的容器環(huán)境中，東西向連接關(guān)系極其復(fù)雜，大量實(shí)操經(jīng)驗(yàn)證明，管理者制定策略規(guī)則時“首發(fā)命中”的可能性微乎其微，安全策略從設(shè)計(jì)到執(zhí)行通常需要仿真測試、細(xì)化調(diào)優(yōu)等階段，否則大概率發(fā)生的誤阻斷將直接造成服務(wù)間的調(diào)用失敗。而在 Network Policy 即時生效的機(jī)制下，管理者的配置難度和試錯成本極高，對策略下發(fā)執(zhí)行造成阻滯。

3)管理操作易用性差

對于多數(shù)用戶而言，Network Policy 的管理交互并不友好，例如其僅能基于 Namespace和 Pod 標(biāo)簽定義策略，對于容器平臺管理不規(guī)范的用戶，策略的靈活性將受到極大限制。又如，策略定義需通過手工編輯 YAML 文件實(shí)現(xiàn)，配置效率低、誤配置風(fēng)險(xiǎn)高。這些問題均不利于在復(fù)雜的容器環(huán)境下配置生效微隔離策略。

混合架構(gòu)無法統(tǒng)管云原生環(huán)境中容器是工作負(fù)載的主流類型，但即便是在徹底完成云原生化改造后，容器也并不會完全替代虛擬機(jī)實(shí)例。換言之，在多數(shù)用戶的數(shù)據(jù)中心內(nèi)，物理機(jī)實(shí)例、虛擬機(jī)實(shí)例、容器將長期并存，作為承載不同應(yīng)用的工作負(fù)載，它們之間依然會產(chǎn)生密切的橫向連接，需被統(tǒng)一納入微隔離的管控范圍，而 Network Policy 顯然僅適用于容器平臺內(nèi)部的隔離控制。

綜合以上，K8S 內(nèi)置的 Network Policy 能在容器平臺中提供基于策略的內(nèi)部流量控制能力，但其更傾向于一個單純的“策略執(zhí)行點(diǎn)”。事實(shí)上，在云原生環(huán)境下實(shí)施微隔離本身是非常復(fù)雜的，對于策略從設(shè)計(jì)、到定義、再到運(yùn)維等全生命周期的管理，現(xiàn)階段的 Network Policy 并不能完全勝任。

2、主機(jī)代理形態(tài)的工作負(fù)載微隔離

Network Policy 原生于云卻“舉步維艱”，同樣印證了云原生環(huán)境對于專業(yè)安全功能深度、廣度和易用度的訴求。事實(shí)上，云工作負(fù)載的微隔離防護(hù)并非是在云原生時代才有的產(chǎn)物，該技術(shù)早在 2015 年便被 Gartner 提出，并在近幾年間快速進(jìn)入主流技術(shù)航道，只是在微隔離誕生之初，其面向的隔離對象以云平臺內(nèi)的虛擬機(jī)實(shí)例為主，容器還并未得到大范圍運(yùn)用。

作為面向新型基礎(chǔ)設(shè)施的創(chuàng)新技術(shù)，早期的微隔離存在多種技術(shù)路線，各有優(yōu)劣及對應(yīng)的適用場景。云廠商面向其用戶推出了適用于自身平臺的安全組件，可與云管理平臺緊密結(jié)合，但對第三方云平臺的適應(yīng)性具有明顯局限。防火墻廠商通過與虛擬化平臺的適配，將東西向流量牽引至其防火墻系統(tǒng)實(shí)現(xiàn)訪問控制，可利用較成熟的安全能力對流量進(jìn)行檢測和控制，但性能上存在較大難點(diǎn)，且實(shí)際效果往往受制于虛擬化平臺的兼容適配水平。獨(dú)立的微隔離廠商則采用主機(jī)代理（Agent）的方式，通過控制工作負(fù)載操作系統(tǒng)的主機(jī)防火墻程序（IPTABLES）實(shí)現(xiàn)面向工作負(fù)載的隔離控制，能夠充分適應(yīng)混合云、多云及各類云平臺，最大程度實(shí)現(xiàn)基礎(chǔ)架構(gòu)無關(guān)。

多數(shù) K8S 網(wǎng)絡(luò)插件是利用節(jié)點(diǎn)（Node）主機(jī)內(nèi)核的固有能力實(shí)現(xiàn)容器平臺內(nèi)部的網(wǎng)絡(luò)轉(zhuǎn)發(fā)，這給基于主機(jī)代理（Agent）的微隔離系統(tǒng)適應(yīng)容器環(huán)境提供了天然的技術(shù)條件，可將 Agent 部署于容器 Node 的操作系統(tǒng)，并通過控制其內(nèi)核的網(wǎng)絡(luò)轉(zhuǎn)發(fā)進(jìn)而實(shí)現(xiàn)容器間通信的訪問控制。因此，基于已較為完善的微隔離功能，并憑借對容器環(huán)境的天然兼容性，基于主機(jī)代理形態(tài)的微隔離系統(tǒng)在相當(dāng)長一段時期內(nèi)，幾乎是面向容器平臺及虛擬機(jī)、容器并存的混合環(huán)境下，唯一可行的微隔離方案。

然而，此類方案在數(shù)據(jù)中心由“應(yīng)用容器化”演進(jìn)至“全面云原生化”后，依然顯現(xiàn)出了諸多與云原生思想相悖的弊端，而核心在于其必須通過在 Node 安裝 Agent 的方式實(shí)現(xiàn)部署。

在 K8S 集群中，Pod 是最小的計(jì)算單元，而 Node 則是 Pod 的承載體，在 Node 按需部署的過程中，Agent 無法隨其建立而自動化部署，反而必須執(zhí)行額外的安裝，勢必拖慢了DevOps 流程、拉低持續(xù)交付的效率。此外，越是規(guī)?；渴鸬挠脩?，管理規(guī)范越嚴(yán)格，獲得Node 安裝 Agent 的管理權(quán)限本身也存在較大不便。

歸根結(jié)底，基于主機(jī)代理的微隔離方案可以支持容器環(huán)境，但其也并非完全的“為云而生”，距離云原生環(huán)境微隔離的理想實(shí)現(xiàn)仍有差距。

五、容器云平臺的安全隔離解決方案

綜合來看，理想的容器云平臺安全隔離解決方案應(yīng)滿足以下幾個條件：

1.充分適應(yīng)云原生環(huán)境特性

云原生的初衷是充分釋放云計(jì)算敏捷、靈活的技術(shù)紅利，安全措施的運(yùn)用不應(yīng)以犧牲云原生的固有特性為代價(jià)，應(yīng)以原生的思維構(gòu)建安全，使安全能力能夠內(nèi)嵌融合于云平臺中。

具體而言，云原生安全方案應(yīng)采用內(nèi)嵌的方式而非“穿衣戴帽”式的外掛部署，安全能力能夠與云原生環(huán)境中的應(yīng)用一樣實(shí)現(xiàn)快速部署、按需伸縮。應(yīng)可以充分利用云平臺原生的資源和數(shù)據(jù)，實(shí)現(xiàn)安全策略的自適應(yīng)。

因此隔離方案應(yīng)具備容器化部署運(yùn)行、自適應(yīng)策略計(jì)算等特性，將安全能力以原生化方式向云平臺融合嵌入，充分適應(yīng)云原生環(huán)境敏捷、靈活、彈性擴(kuò)展、動態(tài)伸縮的特點(diǎn)。讓安全與容器的生命周期保持緊密的“步調(diào)一致”，自動加載精細(xì)化訪問控制能力，不但消除了用戶容器平臺的防護(hù)“盲區(qū)”，還對業(yè)務(wù)應(yīng)用實(shí)現(xiàn)了安全防護(hù)左移。

2.提供可靠的策略設(shè)計(jì)輔助

云原生環(huán)境對傳統(tǒng) IT 架構(gòu)和管理模式形成巨大顛覆，在更為緊湊的應(yīng)用生命周期內(nèi)，從開發(fā)、到測試、再到運(yùn)維，安全控制的設(shè)計(jì)和實(shí)施往往并不在業(yè)務(wù)團(tuán)隊(duì)關(guān)注的范圍。而對于安全人員來說，難以將安全措施融入應(yīng)用交付流程的核心原因，是安全人員并不了解業(yè)務(wù)構(gòu)成和運(yùn)行，在未得到必要輸入的情況下，他們同樣無法回答策略該如何設(shè)計(jì)的問題。

結(jié)合云原生環(huán)境實(shí)施微隔離的場景，在無法縱覽全局連接狀態(tài)、無法準(zhǔn)確梳理業(yè)務(wù)互訪的情況下，用戶難以像實(shí)施傳統(tǒng)域間邊界訪問控制那樣預(yù)設(shè)安全策略，而必須經(jīng)歷一定周期的學(xué)習(xí)、分析和建模，才能定義出符合業(yè)務(wù)實(shí)質(zhì)、遵循最小特權(quán)的策略規(guī)則。在此過程中，系統(tǒng)應(yīng)通過可視化、智能化的功能，為安全策略的設(shè)計(jì)提供輔助和便利。

被廠商“神化”了多年的“可視化”技術(shù)，在過去很多年更像是個“花瓶”。而如今，可視化成了微隔離一項(xiàng)關(guān)鍵能力，要想“可控”首先必須“可視”，這也是“策略輔助設(shè)計(jì)”的具體體現(xiàn)。

因此容器云隔離方案應(yīng)提供帶業(yè)務(wù)視角的連接關(guān)系可視化分析功能，在微隔離策略實(shí)施的準(zhǔn)備階段，讓用戶以縱覽全局、洞察微豪的上帝視角深入分析云原生環(huán)境下的東西向流量，并提供資產(chǎn)梳理、策略設(shè)計(jì)等的輔助支撐，進(jìn)一步降低微隔離的實(shí)施難度。

3.具備完善的策略管理能力

云原生環(huán)境下更為有效的安全管控，實(shí)際上是要實(shí)現(xiàn)面向規(guī)模更龐大、復(fù)雜度更高的管控對象，執(zhí)行顆粒度更細(xì)、精細(xì)化程度更高的安全策略，這無疑是對微隔離策略體系的巨大挑戰(zhàn)。事實(shí)上，在容器平臺強(qiáng)大的編排能力下，用于加載執(zhí)行安全策略的作用點(diǎn)并不缺少，而更為重要的是需具備完善、系統(tǒng)的策略定義框架和管理運(yùn)維能力，確保策略設(shè)計(jì)能被準(zhǔn)確定義，管控意圖得以完整貫徹。

云原生環(huán)境的微隔離場景下，安全策略首先應(yīng)完成與 IP 和主機(jī)名的解耦，并支持以新的、更加豐富的方式來圈定策略對象。安全策略應(yīng)能適應(yīng)面向東西向流量的場景，例如跨業(yè)務(wù)的或業(yè)務(wù)內(nèi)的、出站的或入站的、應(yīng)允許的或需阻斷的等。安全策略的執(zhí)行必須考慮到微隔離運(yùn)用的實(shí)際，提供必要的效果仿真手段，來驗(yàn)證策略設(shè)計(jì)的正確性和合理性。安全策略的發(fā)布應(yīng)能夠被謹(jǐn)慎審查，并提供快速的回滾選項(xiàng)等。

提供靈活的策略定義編排和完備的運(yùn)維管理功能，具體可體現(xiàn)為簡化的策略邏輯、靈活的策略定義方式、豐富的策略生效模式及完善的策略審計(jì)和回滾等設(shè)計(jì)，滿足云原生環(huán)境下復(fù)雜的策略管控需求。專業(yè)而體系化的微隔離策略管理和運(yùn)維能力，可讓用戶獲得更為便捷、易用的策略管理體驗(yàn)，從而加速零信任安全能力在數(shù)據(jù)中心的落地。

4.跨平臺、跨集群統(tǒng)一管理

最好能實(shí)現(xiàn)物理機(jī)、虛擬機(jī)、容器等多類工作負(fù)載的同臺納管，實(shí)現(xiàn)規(guī)?；圃h(huán)境中跨 K8S 集群的統(tǒng)一管理，這樣才能適應(yīng)國內(nèi)多數(shù)用戶混合云、多云等復(fù)雜數(shù)據(jù)中心場景下的微隔離統(tǒng)一管理需求，使用戶獲得企業(yè)的全業(yè)務(wù)可視化分析能力和全業(yè)務(wù)訪問控制能力。