容器雲平臺如何做好安全隔離？

雲原生技術在創造效益的同時，也面臨著切實存在日益嚴峻的安全風險。基於防火牆進行域間控制已顯得與雲原生環境格格不入，無法真正滿足容器平臺的隔離需求。本文對現有容器雲平臺隔離方案：基於 Network Policy 的容器隔離、主機代理形態的工作負載微隔離進行了分析，並提出理想的容器雲平臺安全隔離解決方案應滿足的幾個條件。希望能為準備和正在進行容器雲平臺安全設計的同行提供參考。

一、雲原生的技術背景

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

相較傳統 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)規模化管理難度大

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、跨平臺、跨叢集統一管理

最好能實現物理機、虛擬機器、容器等多類工作負載的同臺納管，實現規模化雲原生環境中跨 K8S 叢集的統一管理，這樣才能適應國內多數使用者混合雲、多雲等複雜資料中心場景下的微隔離統一管理需求，使使用者獲得企業的全業務視覺化分析能力和全業務訪問控制能力。