原创 twt社区
【導讀】雲端原生技術在創造效益的同時，也面臨切實存在日益嚴峻的安全風險。 基於防火牆進行域間控制已顯得與雲端原生環境格格不入，無法真正滿足容器平台的隔離需求。 本文對現有容器雲平台隔離方案：基於 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 叢集的統一管理，這樣才能適應國內多數用戶混合雲、多雲等複雜資料中心 場景下的微隔離統一管理需求，使用戶獲得企業的全業務視覺化分析能力和全業務存取控制能力。
