一、云原生的技術背景

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

相較傳統 IT 架構，云原生具有無法比擬的優勢，將為企業帶來降低成本、提升效率、快速試錯、促進創新等業務增益價值。

云原生的技術理念始于 Netflix 等廠商從 2009 年起在公有云上的開發和部署實踐。2015年云原生計算基金會（CNCF）成立，標志著云原生從技術理念轉化為開源實現。云原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式 API。這些技術能夠構建容錯性好、易于管理和便于觀察的松耦合系統。結合可靠的自動化手段，云原生技術使工程師能夠輕松地對系統作出頻繁和可預測的重大變更。

云原生的運用使本身復雜多變的企業業務可敏捷靈活、及時響應、快速迭代，從而讓數字化轉型和運營過程中的持續創新成為可能。目前業界較為認可的構成云原生的四大核心技術要素是微服務、DevOps、持續交付和容器化。

二、云原生環境的網絡隔離訴求

原生技術能夠有效解決傳統云實踐中應用升級緩慢、架構臃腫、無法快速迭代等“痛點”問題，并為業務創新提供動力。然而，云原生技術在創造效益的同時，也面臨著切實存在日益嚴峻的安全風險。

例如，2018年特斯拉AWS上部署的K8S Dashboard暴露在公網，沒有做認證和授權控制，也沒有對網絡訪問做控制，黑客直接從dashboard中獲取S3憑證，從而獲取遙測數據，惡意拉取POD，進行挖礦行為。

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

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

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

三、傳統防火墻在云原生中的捉襟見肘

基于所承載業務的屬性和安全級別，傳統數據中心往往將其內部劃分為多個安全域并進行定制化的安全管理，在安全域間通常會部署防火墻系統實現訪問控制。在云平臺建設初期，此類架構被相當一部分用戶繼續采用，并利用防火墻實施域間的訪問控制策略，一些管理水平較高的用戶則基于訪問源和目的 IP 進行了細粒度的策略規則設定。

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

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

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

云原生環境中，微服務的架構勢必指數級的增加服務間的互訪調用情況和橫向連接關系，給原本就復雜度較高的東西向流量控制又帶來了新的難度。在 DevOps 的加持下，應用敏捷、快速、持續交付部署，而安全控制措施則必須找到合適的切入點，并跟上瞬息萬變的節奏。

容器成為新的最小控制單元，其生命周期規律則更加難尋，每次新業務上線、應用更新、擴縮容等，均會帶來容器的消亡和新建，而在此過程中傳統用于標識基礎設施的 IP、主機名等均將發生變化，傳統的安全策略框架則將被輕易繞過逃逸。

由此看來，即便放棄用防火墻實現集群內流量微隔離的預期，其在云原生環境中也難以起到集群間流量的有效隔離控制作用，在云原生架構下甚至已經失去了原先的部署位置。事實上，開始規?；渴鹑萜鞯挠脩?，往往在第一時間即發現了防火墻系統幾乎徹底失效的問題，從而釋放出更為迫切的隔離控制需求。

四、現有容器云平臺隔離方案分析

1.基于 Network Policy 的容器隔離

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

在 K8S 中，Network Policy 定義了一組 Pod 之間的訪問控制規范，其通過 Label 指定Namespace 和 Pod，并利用節點（Node）主機操作系統的 IPTABLES 實現 Namespace 和Pod 級的網絡訪問控制。

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

1)環境適應性的局限

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

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

2)規?；芾黼y度大

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

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

3)管理操作易用性差

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

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

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

2、主機代理形態的工作負載微隔離

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

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

多數 K8S 網絡插件是利用節點（Node）主機內核的固有能力實現容器平臺內部的網絡轉發，這給基于主機代理（Agent）的微隔離系統適應容器環境提供了天然的技術條件，可將 Agent 部署于容器 Node 的操作系統，并通過控制其內核的網絡轉發進而實現容器間通信的訪問控制。因此，基于已較為完善的微隔離功能，并憑借對容器環境的天然兼容性，基于主機代理形態的微隔離系統在相當長一段時期內，幾乎是面向容器平臺及虛擬機、容器并存的混合環境下，唯一可行的微隔離方案。

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

在 K8S 集群中，Pod 是最小的計算單元，而 Node 則是 Pod 的承載體，在 Node 按需部署的過程中，Agent 無法隨其建立而自動化部署，反而必須執行額外的安裝，勢必拖慢了DevOps 流程、拉低持續交付的效率。此外，越是規模化部署的用戶，管理規范越嚴格，獲得Node 安裝 Agent 的管理權限本身也存在較大不便。

歸根結底，基于主機代理的微隔離方案可以支持容器環境，但其也并非完全的“為云而生”，距離云原生環境微隔離的理想實現仍有差距。

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

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

1.充分適應云原生環境特性

云原生的初衷是充分釋放云計算敏捷、靈活的技術紅利，安全措施的運用不應以犧牲云原生的固有特性為代價，應以原生的思維構建安全，使安全能力能夠內嵌融合于云平臺中。

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

因此隔離方案應具備容器化部署運行、自適應策略計算等特性，將安全能力以原生化方式向云平臺融合嵌入，充分適應云原生環境敏捷、靈活、彈性擴展、動態伸縮的特點。讓安全與容器的生命周期保持緊密的“步調一致”，自動加載精細化訪問控制能力，不但消除了用戶容器平臺的防護“盲區”，還對業務應用實現了安全防護左移。

2.提供可靠的策略設計輔助

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

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

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

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

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

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

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

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

4.跨平臺、跨集群統一管理

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