本文來(lái)自twt企業(yè)IT社區(qū)，作者/高鶴。
云原生技術(shù)在創(chuàng)造效益的同時(shí)，也面臨著切實(shí)存在日益嚴(yán)峻的安全風(fēng)險(xiǎn)。基于防火墻進(jìn)行域間控制已顯得與云原生環(huán)境格格不入，無(wú)法真正滿足容器平臺(tái)的隔離需求。本文對(duì)現(xiàn)有容器云平臺(tái)隔離方案：基于Network Policy的容器隔離、主機(jī)代理形態(tài)的工作負(fù)載微隔離進(jìn)行了分析，并提出理想的容器云平臺(tái)安全隔離解決方案應(yīng)滿足的幾個(gè)條件。希望能為準(zhǔn)備和正在進(jìn)行容器云平臺(tái)安全設(shè)計(jì)的同行提供參考。
一、云原生的技術(shù)背景
當(dāng)前，數(shù)字化變革已逐漸滲透到每一個(gè)具體產(chǎn)業(yè)，彈性算力已成為各行各業(yè)的“水電煤”，云計(jì)算則成為數(shù)字化世界的基石，從底層驅(qū)動(dòng)產(chǎn)業(yè)變革。隨著云計(jì)算發(fā)展進(jìn)入成熟階段，以“生在云上、長(zhǎng)在云上”為核心理念的云原生技術(shù)被視為云計(jì)算未來(lái)十年的重要發(fā)展方向。在數(shù)字化大潮中，上云并非是一種時(shí)尚，而是一種剛需，從“上云”到“全面上云”，從“云化”到“云原生化”，是企業(yè)數(shù)字化轉(zhuǎn)型的必由之路。
相較傳統(tǒng)IT架構(gòu)，云原生具有無(wú)法比擬的優(yōu)勢(shì)，將為企業(yè)帶來(lái)降低成本、提升效率、快速試錯(cuò)、促進(jìn)創(chuàng)新等業(yè)務(wù)增益價(jià)值。
云原生的技術(shù)理念始于Netflix等廠商從2009年起在公有云上的開(kāi)發(fā)和部署實(shí)踐。2015年云原生計(jì)算基金會(huì)（CNCF）成立，標(biāo)志著云原生從技術(shù)理念轉(zhuǎn)化為開(kāi)源實(shí)現(xiàn)。云原生的代表技術(shù)包括容器、服務(wù)網(wǎng)格、微服務(wù)、不可變基礎(chǔ)設(shè)施和聲明式API。這些技術(shù)能夠構(gòu)建容錯(cuò)性好、易于管理和便于觀察的松耦合系統(tǒng)。結(jié)合可靠的自動(dòng)化手段，云原生技術(shù)使工程師能夠輕松地對(duì)系統(tǒng)作出頻繁和可預(yù)測(cè)的重大變更。
云原生的運(yùn)用使本身復(fù)雜多變的企業(yè)業(yè)務(wù)可敏捷靈活、及時(shí)響應(yīng)、快速迭代，從而讓數(shù)字化轉(zhuǎn)型和運(yùn)營(yíng)過(guò)程中的持續(xù)創(chuàng)新成為可能。目前業(yè)界較為認(rèn)可的構(gòu)成云原生的四大核心技術(shù)要素是微服務(wù)、DevOps、持續(xù)交付和容器化。
二、云原生環(huán)境的網(wǎng)絡(luò)隔離訴求
原生技術(shù)能夠有效解決傳統(tǒng)云實(shí)踐中應(yīng)用升級(jí)緩慢、架構(gòu)臃腫、無(wú)法快速迭代等“痛點(diǎn)”問(wèn)題，并為業(yè)務(wù)創(chuàng)新提供動(dòng)力。然而，云原生技術(shù)在創(chuàng)造效益的同時(shí)，也面臨著切實(shí)存在日益嚴(yán)峻的安全風(fēng)險(xiǎn)。
例如，2018年特斯拉AWS上部署的K8S Dashboard暴露在公網(wǎng)，沒(méi)有做認(rèn)證和授權(quán)控制，也沒(méi)有對(duì)網(wǎng)絡(luò)訪問(wèn)做控制，黑客直接從dashboard中獲取S3憑證，從而獲取遙測(cè)數(shù)據(jù)，惡意拉取POD，進(jìn)行挖礦行為。
而“隔離”技術(shù)是最早、最基礎(chǔ)、也始終是最為核心的安全技術(shù)手段之一。Gartner提出的容器安全控制分層理論，將容器安全能力按照優(yōu)先級(jí)由高至低分為基礎(chǔ)控制（Foundational Controls）、基本控制（Basic Controls）和基于風(fēng)險(xiǎn)的控制（Risk-Based Controls），其中網(wǎng)絡(luò)隔離（L3 Network Segmentation）被劃分為必備的基礎(chǔ)控制能力。
CNCF于2021年發(fā)布的《云原生安全白皮書(shū)》指出，作為微服務(wù)部署的容器化應(yīng)用程序的邊界就是微服務(wù)本身。因此，有必要設(shè)定策略，只允許在得到許可的微服務(wù)間進(jìn)行通信。
在微服務(wù)架構(gòu)中引入零信任，可以在一個(gè)微服務(wù)被攻陷時(shí)阻止其橫向移動(dòng)，從而縮小影響范圍。運(yùn)維人員應(yīng)確保他們正在使用網(wǎng)絡(luò)策略等功能，確保一個(gè)容器部署內(nèi)的東西向網(wǎng)絡(luò)通信只限于授權(quán)網(wǎng)絡(luò)。
三、傳統(tǒng)防火墻在云原生中的捉襟見(jiàn)肘
基于所承載業(yè)務(wù)的屬性和安全級(jí)別，傳統(tǒng)數(shù)據(jù)中心往往將其內(nèi)部劃分為多個(gè)安全域并進(jìn)行定制化的安全管理，在安全域間通常會(huì)部署防火墻系統(tǒng)實(shí)現(xiàn)訪問(wèn)控制。在云平臺(tái)建設(shè)初期，此類架構(gòu)被相當(dāng)一部分用戶繼續(xù)采用，并利用防火墻實(shí)施域間的訪問(wèn)控制策略，一些管理水平較高的用戶則基于訪問(wèn)源和目的IP進(jìn)行了細(xì)粒度的策略規(guī)則設(shè)定。
然而，隨著云平臺(tái)向云原生架構(gòu)演進(jìn)遷移，基于防火墻進(jìn)行域間控制已顯得與云原生環(huán)境格格不入，無(wú)法真正滿足容器平臺(tái)的隔離需求。
防火墻的部署位置和控制對(duì)象決定了其僅能針對(duì)跨域流量進(jìn)行控制，而無(wú)法實(shí)現(xiàn)更細(xì)粒度的業(yè)務(wù)級(jí)、工作負(fù)載級(jí)控制。此外，鑒于策略規(guī)模對(duì)防火墻性能的影響，其安全策略的控制對(duì)象往往僅能做到網(wǎng)段級(jí)。因此，確切來(lái)說(shuō)，此類方案至多能夠提供用于維護(hù)數(shù)據(jù)中心基礎(chǔ)架構(gòu)完整性的“宏分段（Macro-Segmentation）”，而無(wú)法實(shí)現(xiàn)云原生環(huán)境中真正所需的“微隔離（Micro-Segmentation）”。
此外，穩(wěn)定不變的IP地址是防火墻訪問(wèn)控制持續(xù)生效的“錨點(diǎn)”，而在云原生環(huán)境中，容器IP的頻繁無(wú)規(guī)律變化則徹底動(dòng)搖了傳統(tǒng)架構(gòu)中這一確定因素，一旦容器開(kāi)始新的生命周期，新的IP將直接逃逸原有靜態(tài)策略的有效管控。與此同時(shí)，由于容器的消亡與新建在云原生環(huán)境中是高頻發(fā)生的，即便能夠?qū)崟r(shí)感知其變化，依靠人工刪除原有策略并建立新的策略也毫無(wú)可能，而已失效的策略長(zhǎng)時(shí)間堆積，又勢(shì)必帶來(lái)防火墻系統(tǒng)策略冗余、性能下降的副作用。
云原生環(huán)境中，微服務(wù)的架構(gòu)勢(shì)必指數(shù)級(jí)的增加服務(wù)間的互訪調(diào)用情況和橫向連接關(guān)系，給原本就復(fù)雜度較高的東西向流量控制又帶來(lái)了新的難度。在DevOps的加持下，應(yīng)用敏捷、快速、持續(xù)交付部署，而安全控制措施則必須找到合適的切入點(diǎn)，并跟上瞬息萬(wàn)變的節(jié)奏。
容器成為新的最小控制單元，其生命周期規(guī)律則更加難尋，每次新業(yè)務(wù)上線、應(yīng)用更新、擴(kuò)縮容等，均會(huì)帶來(lái)容器的消亡和新建，而在此過(guò)程中傳統(tǒng)用于標(biāo)識(shí)基礎(chǔ)設(shè)施的IP、主機(jī)名等均將發(fā)生變化，傳統(tǒng)的安全策略框架則將被輕易繞過(guò)逃逸。
由此看來(lái)，即便放棄用防火墻實(shí)現(xiàn)集群內(nèi)流量微隔離的預(yù)期，其在云原生環(huán)境中也難以起到集群間流量的有效隔離控制作用，在云原生架構(gòu)下甚至已經(jīng)失去了原先的部署位置。事實(shí)上，開(kāi)始規(guī)?；渴鹑萜鞯挠脩簦诘谝粫r(shí)間即發(fā)現(xiàn)了防火墻系統(tǒng)幾乎徹底失效的問(wèn)題，從而釋放出更為迫切的隔離控制需求。
四、現(xiàn)有容器云平臺(tái)隔離方案分析
1、基于Network Policy的容器隔離
防火墻因“水土不服”而在云原生環(huán)境下徹底失效，再次鮮活證明了“安全原生化”對(duì)于云原生環(huán)境的重要性。事實(shí)上，已成為容器編排平臺(tái)事實(shí)標(biāo)準(zhǔn)的Kubernetes（以下簡(jiǎn)稱“K8S”），通過(guò)集成Network Policy功能提供了容器間的網(wǎng)絡(luò)隔離能力。
在K8S中，Network Policy定義了一組Pod之間的訪問(wèn)控制規(guī)范，其通過(guò)Label指定Namespace和Pod，并利用節(jié)點(diǎn)（Node）主機(jī)操作系統(tǒng)的IPTABLES實(shí)現(xiàn)Namespace和Pod級(jí)的網(wǎng)絡(luò)訪問(wèn)控制。
與外掛式的防火墻相比，Network Policy實(shí)現(xiàn)了原生化的安全能力內(nèi)嵌，但大量實(shí)踐表明，對(duì)于多數(shù)用戶而言其運(yùn)用落地依然受到較大制約，存在以下突出問(wèn)題：
1)環(huán)境適應(yīng)性的局限
Network Policy只定義了策略規(guī)則的規(guī)范，而訪問(wèn)控制能力的具體實(shí)現(xiàn)則需依賴K8S平臺(tái)的網(wǎng)絡(luò)插件。事實(shí)上，當(dāng)前流行的K8S網(wǎng)絡(luò)插件中，并非所有均支持Network Policy功能。例如相當(dāng)一部分用戶使用的Flannel插件即無(wú)法支持該項(xiàng)功能，而對(duì)于多數(shù)用戶而言，為了實(shí)現(xiàn)Network Policy能力而替換遷移原網(wǎng)絡(luò)插件的成本無(wú)疑是高昂的。
此外，一套Network Policy策略僅能適用于一個(gè)獨(dú)立的K8S集群，對(duì)于普遍具有多套K8S集群的用戶而言，期望利用Network Policy實(shí)現(xiàn)全局管理，則必須進(jìn)行更為復(fù)雜的定制開(kāi)發(fā)，其實(shí)現(xiàn)難度和管理成本令多數(shù)用戶望塵莫及。
2)規(guī)?；芾黼y度大
Network Policy僅在商用版才提供了流量可視化能力，對(duì)于開(kāi)源版用戶而言，不得不在未了解流量關(guān)系的情況下“盲配”安全策略，準(zhǔn)確性和效率將大大降低，且隨著管理規(guī)模的增大，定制貼合業(yè)務(wù)、符合最小特權(quán)原則的安全策略則越來(lái)越不可能。
同時(shí)，在規(guī)模較大的容器環(huán)境中，東西向連接關(guān)系極其復(fù)雜，大量實(shí)操經(jīng)驗(yàn)證明，管理者制定策略規(guī)則時(shí)“首發(fā)命中”的可能性微乎其微，安全策略從設(shè)計(jì)到執(zhí)行通常需要仿真測(cè)試、細(xì)化調(diào)優(yōu)等階段，否則大概率發(fā)生的誤阻斷將直接造成服務(wù)間的調(diào)用失敗。而在Network Policy即時(shí)生效的機(jī)制下，管理者的配置難度和試錯(cuò)成本極高，對(duì)策略下發(fā)執(zhí)行造成阻滯。
3)管理操作易用性差
對(duì)于多數(shù)用戶而言，Network Policy的管理交互并不友好，例如其僅能基于Namespace和Pod標(biāo)簽定義策略，對(duì)于容器平臺(tái)管理不規(guī)范的用戶，策略的靈活性將受到極大限制。又如，策略定義需通過(guò)手工編輯YAML文件實(shí)現(xiàn)，配置效率低、誤配置風(fēng)險(xiǎn)高。這些問(wèn)題均不利于在復(fù)雜的容器環(huán)境下配置生效微隔離策略。
混合架構(gòu)無(wú)法統(tǒng)管云原生環(huán)境中容器是工作負(fù)載的主流類型，但即便是在徹底完成云原生化改造后，容器也并不會(huì)完全替代虛擬機(jī)實(shí)例。換言之，在多數(shù)用戶的數(shù)據(jù)中心內(nèi)，物理機(jī)實(shí)例、虛擬機(jī)實(shí)例、容器將長(zhǎng)期并存，作為承載不同應(yīng)用的工作負(fù)載，它們之間依然會(huì)產(chǎn)生密切的橫向連接，需被統(tǒng)一納入微隔離的管控范圍，而Network Policy顯然僅適用于容器平臺(tái)內(nèi)部的隔離控制。
綜合以上，K8S內(nèi)置的Network Policy能在容器平臺(tái)中提供基于策略的內(nèi)部流量控制能力，但其更傾向于一個(gè)單純的“策略執(zhí)行點(diǎn)”。事實(shí)上，在云原生環(huán)境下實(shí)施微隔離本身是非常復(fù)雜的，對(duì)于策略從設(shè)計(jì)、到定義、再到運(yùn)維等全生命周期的管理，現(xiàn)階段的Network Policy并不能完全勝任。
2、主機(jī)代理形態(tài)的工作負(fù)載微隔離
Network Policy原生于云卻“舉步維艱”，同樣印證了云原生環(huán)境對(duì)于專業(yè)安全功能深度、廣度和易用度的訴求。事實(shí)上，云工作負(fù)載的微隔離防護(hù)并非是在云原生時(shí)代才有的產(chǎn)物，該技術(shù)早在2015年便被Gartner提出，并在近幾年間快速進(jìn)入主流技術(shù)航道，只是在微隔離誕生之初，其面向的隔離對(duì)象以云平臺(tái)內(nèi)的虛擬機(jī)實(shí)例為主，容器還并未得到大范圍運(yùn)用。
作為面向新型基礎(chǔ)設(shè)施的創(chuàng)新技術(shù)，早期的微隔離存在多種技術(shù)路線，各有優(yōu)劣及對(duì)應(yīng)的適用場(chǎng)景。云廠商面向其用戶推出了適用于自身平臺(tái)的安全組件，可與云管理平臺(tái)緊密結(jié)合，但對(duì)第三方云平臺(tái)的適應(yīng)性具有明顯局限。防火墻廠商通過(guò)與虛擬化平臺(tái)的適配，將東西向流量牽引至其防火墻系統(tǒng)實(shí)現(xiàn)訪問(wèn)控制，可利用較成熟的安全能力對(duì)流量進(jìn)行檢測(cè)和控制，但性能上存在較大難點(diǎn)，且實(shí)際效果往往受制于虛擬化平臺(tái)的兼容適配水平。獨(dú)立的微隔離廠商則采用主機(jī)代理（Agent）的方式，通過(guò)控制工作負(fù)載操作系統(tǒng)的主機(jī)防火墻程序（IPTABLES）實(shí)現(xiàn)面向工作負(fù)載的隔離控制，能夠充分適應(yīng)混合云、多云及各類云平臺(tái)，最大程度實(shí)現(xiàn)基礎(chǔ)架構(gòu)無(wú)關(guān)。
多數(shù)K8S網(wǎng)絡(luò)插件是利用節(jié)點(diǎn)（Node）主機(jī)內(nèi)核的固有能力實(shí)現(xiàn)容器平臺(tái)內(nèi)部的網(wǎng)絡(luò)轉(zhuǎn)發(fā)，這給基于主機(jī)代理（Agent）的微隔離系統(tǒng)適應(yīng)容器環(huán)境提供了天然的技術(shù)條件，可將Agent部署于容器Node的操作系統(tǒng)，并通過(guò)控制其內(nèi)核的網(wǎng)絡(luò)轉(zhuǎn)發(fā)進(jìn)而實(shí)現(xiàn)容器間通信的訪問(wèn)控制。因此，基于已較為完善的微隔離功能，并憑借對(duì)容器環(huán)境的天然兼容性，基于主機(jī)代理形態(tài)的微隔離系統(tǒng)在相當(dāng)長(zhǎng)一段時(shí)期內(nèi)，幾乎是面向容器平臺(tái)及虛擬機(jī)、容器并存的混合環(huán)境下，唯一可行的微隔離方案。
然而，此類方案在數(shù)據(jù)中心由“應(yīng)用容器化”演進(jìn)至“全面云原生化”后，依然顯現(xiàn)出了諸多與云原生思想相悖的弊端，而核心在于其必須通過(guò)在Node安裝Agent的方式實(shí)現(xiàn)部署。
在K8S集群中，Pod是最小的計(jì)算單元，而Node則是Pod的承載體，在Node按需部署的過(guò)程中，Agent無(wú)法隨其建立而自動(dòng)化部署，反而必須執(zhí)行額外的安裝，勢(shì)必拖慢了DevOps流程、拉低持續(xù)交付的效率。此外，越是規(guī)?；渴鸬挠脩簦芾硪?guī)范越嚴(yán)格，獲得Node安裝Agent的管理權(quán)限本身也存在較大不便。
歸根結(jié)底，基于主機(jī)代理的微隔離方案可以支持容器環(huán)境，但其也并非完全的“為云而生”，距離云原生環(huán)境微隔離的理想實(shí)現(xiàn)仍有差距。
五、容器云平臺(tái)的安全隔離解決方案
綜合來(lái)看，理想的容器云平臺(tái)安全隔離解決方案應(yīng)滿足以下幾個(gè)條件：
1、充分適應(yīng)云原生環(huán)境特性
云原生的初衷是充分釋放云計(jì)算敏捷、靈活的技術(shù)紅利，安全措施的運(yùn)用不應(yīng)以犧牲云原生的固有特性為代價(jià)，應(yīng)以原生的思維構(gòu)建安全，使安全能力能夠內(nèi)嵌融合于云平臺(tái)中。
具體而言，云原生安全方案應(yīng)采用內(nèi)嵌的方式而非“穿衣戴帽”式的外掛部署，安全能力能夠與云原生環(huán)境中的應(yīng)用一樣實(shí)現(xiàn)快速部署、按需伸縮。應(yīng)可以充分利用云平臺(tái)原生的資源和數(shù)據(jù)，實(shí)現(xiàn)安全策略的自適應(yīng)。
因此隔離方案應(yīng)具備容器化部署運(yùn)行、自適應(yīng)策略計(jì)算等特性，將安全能力以原生化方式向云平臺(tái)融合嵌入，充分適應(yīng)云原生環(huán)境敏捷、靈活、彈性擴(kuò)展、動(dòng)態(tài)伸縮的特點(diǎn)。讓安全與容器的生命周期保持緊密的“步調(diào)一致”，自動(dòng)加載精細(xì)化訪問(wèn)控制能力，不但消除了用戶容器平臺(tái)的防護(hù)“盲區(qū)”，還對(duì)業(yè)務(wù)應(yīng)用實(shí)現(xiàn)了安全防護(hù)左移。
2、提供可靠的策略設(shè)計(jì)輔助
云原生環(huán)境對(duì)傳統(tǒng)IT架構(gòu)和管理模式形成巨大顛覆，在更為緊湊的應(yīng)用生命周期內(nèi)，從開(kāi)發(fā)、到測(cè)試、再到運(yùn)維，安全控制的設(shè)計(jì)和實(shí)施往往并不在業(yè)務(wù)團(tuán)隊(duì)關(guān)注的范圍。而對(duì)于安全人員來(lái)說(shuō)，難以將安全措施融入應(yīng)用交付流程的核心原因，是安全人員并不了解業(yè)務(wù)構(gòu)成和運(yùn)行，在未得到必要輸入的情況下，他們同樣無(wú)法回答策略該如何設(shè)計(jì)的問(wèn)題。
結(jié)合云原生環(huán)境實(shí)施微隔離的場(chǎng)景，在無(wú)法縱覽全局連接狀態(tài)、無(wú)法準(zhǔn)確梳理業(yè)務(wù)互訪的情況下，用戶難以像實(shí)施傳統(tǒng)域間邊界訪問(wèn)控制那樣預(yù)設(shè)安全策略，而必須經(jīng)歷一定周期的學(xué)習(xí)、分析和建模，才能定義出符合業(yè)務(wù)實(shí)質(zhì)、遵循最小特權(quán)的策略規(guī)則。在此過(guò)程中，系統(tǒng)應(yīng)通過(guò)可視化、智能化的功能，為安全策略的設(shè)計(jì)提供輔助和便利。
被廠商“神化”了多年的“可視化”技術(shù)，在過(guò)去很多年更像是個(gè)“花瓶”。而如今，可視化成了微隔離一項(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ù)雜度更高的管控對(duì)象，執(zhí)行顆粒度更細(xì)、精細(xì)化程度更高的安全策略，這無(wú)疑是對(duì)微隔離策略體系的巨大挑戰(zhàn)。事實(shí)上，在容器平臺(tái)強(qiáng)大的編排能力下，用于加載執(zhí)行安全策略的作用點(diǎn)并不缺少，而更為重要的是需具備完善、系統(tǒng)的策略定義框架和管理運(yùn)維能力，確保策略設(shè)計(jì)能被準(zhǔn)確定義，管控意圖得以完整貫徹。
云原生環(huán)境的微隔離場(chǎng)景下，安全策略首先應(yīng)完成與IP和主機(jī)名的解耦，并支持以新的、更加豐富的方式來(lái)圈定策略對(duì)象。安全策略應(yīng)能適應(yīng)面向東西向流量的場(chǎng)景，例如跨業(yè)務(wù)的或業(yè)務(wù)內(nèi)的、出站的或入站的、應(yīng)允許的或需阻斷的等。安全策略的執(zhí)行必須考慮到微隔離運(yùn)用的實(shí)際，提供必要的效果仿真手段，來(lái)驗(yàn)證策略設(shè)計(jì)的正確性和合理性。安全策略的發(fā)布應(yīng)能夠被謹(jǐn)慎審查，并提供快速的回滾選項(xiàng)等。
提供靈活的策略定義編排和完備的運(yùn)維管理功能，具體可體現(xiàn)為簡(jiǎn)化的策略邏輯、靈活的策略定義方式、豐富的策略生效模式及完善的策略審計(jì)和回滾等設(shè)計(jì)，滿足云原生環(huán)境下復(fù)雜的策略管控需求。專業(yè)而體系化的微隔離策略管理和運(yùn)維能力，可讓用戶獲得更為便捷、易用的策略管理體驗(yàn)，從而加速零信任安全能力在數(shù)據(jù)中心的落地。
4、跨平臺(tái)、跨集群統(tǒng)一管理
最好能實(shí)現(xiàn)物理機(jī)、虛擬機(jī)、容器等多類工作負(fù)載的同臺(tái)納管，實(shí)現(xiàn)規(guī)?；圃h(huán)境中跨K8S集群的統(tǒng)一管理，這樣才能適應(yīng)國(guó)內(nèi)多數(shù)用戶混合云、多云等復(fù)雜數(shù)據(jù)中心場(chǎng)景下的微隔離統(tǒng)一管理需求，使用戶獲得企業(yè)的全業(yè)務(wù)可視化分析能力和全業(yè)務(wù)訪問(wèn)控制能力。
