微隔離的三條路

如果一個使用者想要在自己的資料中心部署微隔離，它有幾條路可走呢？根據Gartner的說法，它有四條路。

Gartner提出的四種微隔離技術路線

第一條路最簡單，用戶啥也不用裝，雲端運算基礎平台會提供你微隔離能力。但是這種方式的問題在於，它高度依賴你所使用的雲端的能力，並非所有雲端平台都可以提供。同時，這條路有明顯的環境適應性限制，微隔離能力無法平移到其他雲端平台，對於混合雲、多雲等跨雲架構的場景則無法實現統一管理。

第二條路，大家最熟悉，那就是利用虛擬防火牆，這條路的好處在於，大家對於防火牆的用法都比較熟悉，但是它也有問題。防火牆是在網路安全發展早期就產生的隔離分段技術，其是為跨域流量的存取控製而設計的，經過一定的適配改造，傳統的防火牆得以在雲端環境中部署，但仍難以實現更細粒度的業務級、工作負載級控制。此外，鑑於策略規模對防火牆效能的影響，其安全策略的控制對象往往僅能做到網段級。

第三條路，是前兩條路的組合，透過兩種技術路線方案的互補實現資料中心內部的網路隔離。

第四條路，是迄今為止最成功的，也是被最多人選擇的路，那就是主機Agent路線，這條路讓用戶難以拒絕的原由，在於其與基礎架構無關的特性，利用Agent與操作系統的廣泛相容性，避免了適應各類雲端環境架構的難度，透過Overlay的模式在基礎網路之上建構起完全與基礎架構解耦的控製網路。由此帶來的好處顯而易見，使用者能夠利用這條路實現跨資料中心、跨平台的東西向流量統一管理。不得不說，由於多數K8S網路插件是利用宿主機（Node）內核的固有能力實現容器平台內部的網路轉發，因此這條路對於容器平台幾乎是天然支援的，在過去很長一段時間內，這條路幾乎是實現實體機器、虛擬機器、容器統一管理的唯一路徑。

鑑於上述第三條路從技術的角度講沒啥新東西，與其說是一種“技術路線”，還不如說是一種“解決方案”，因此真正意義上能走通的路就三條。

那麼是否存在著真正意義上的第四種可能呢？或者說是否有必要再提出一條技術路徑來呢，答案是肯定的。

 

雲端原生與微隔離

事實上，如果是在雲端運算條件下，主機Agent基本包打天下了，為了標新立異而提出一條新的技術路線是沒有意義的。但是雲端原生來了，事情就變得不一樣了。

雲端原生的維運管理邏輯與網路建構方式都和傳統雲端運算有著很大的差異。目前在國內外，大家在雲原生環境下做微隔離，基本上都是透過主機Agent的方式來實現，薔薇靈動過去也是這麼幹的，事實上也做得不錯。

但是，正如防火牆不是為雲端運算而生的，所以在雲端運算環境中實現「微分段」對其必然有著諸多的不適應。主機Agent也絕非是為了雲原生而生的，它也勢必存在自己的不適應。要知道，虛擬機器上的Agent和雲端原生裡的Agent本來已經不是一個Agent了。虛擬機器裡的Agent跟虛擬機有著非常緊密的聯繫，可謂月亮走我也走，大家永遠好朋友。但是雲原生裡的Agent，事實上是部署在宿主機上的，它和容器之間以及整個編排系統都是割裂的，這種割裂就帶來了問題，那就是Agent的運維管理獨立於整個PAAS平台的編排管理之外，這對於主張DevSecOps邏輯的雲端原生世界來說其實是不友善、甚至是相悖的。

所以，在雲端原生條件下我們需要一條新的微隔離路線。

 

DaemonSet －微隔離的第四條路線

什麼是雲端原生環境下最恰當的微隔離技術路線呢，答案是DaemonSet。

什麼是Daemonset呢？

DaemonSet是Kubernetes中的一種Pod控制器類型，能夠確保在全部（或一部分）Node 上執行一個Pod 的副本，當有Node加入叢集時，DaemonSet會為其新增一個Pod，當有Node 從叢集移除時，這些Pod也會被回收。基於DaemonSet形態的微隔離方案，是將微隔離的策略執行點以守護容器的形態部署於容器平台中，使其始終運行於每個Node上。

薔薇靈動蜂巢自適應微隔離安全平台部署示意圖

正如「Daemon」一詞中所具有的「守護」意義，在DaemonSet的加持下，微隔離能力可始終與容器平台的彈性伸縮保持「步調一致」。那麼，其究竟能夠解決為雲端原生環境下實施微隔離的使用者帶來哪些實質價值呢？

首先，這種模式徹底改變了原先基於Agent的“外掛嫁接”式安裝，以“嵌入融合”的方式實現了微隔離能力在雲平台的原生化部署，安全能力部署不再是敏捷、彈性的“絆腳石”，雲原生的技術紅利得以充分釋放。

其次，在應用擴容、新業務上線時，管理人員再也無需執行Agent安裝、初始配置等前置操作，僅在日常維護好守護容器鏡像即可，透過自動化的運維方式大幅降低了管理成本。

當然不得不說，對於多數大型用戶而言，安全、網絡、運維部門分工明確、各司其職，在工作負載上安裝一個Agent這件“芝麻大的小事”，往往牽扯多個部門，例如維運部門會說“我不可能給它root權限！”，業務部門會挑戰“Agent會對業務造成多大影響？”，而這些微隔離運用的阻滯因素也隨著新模式的到來而徹底消失。

這就是第四條路，微隔離既不是由PAAS平台自己提供的，也不是由獨立的防火牆或Agent來提供的，而是變成了PAAS平台上的一個獨立業務，以DaemonSet的方式被K8S等編排系統統一管理，統一建立與消亡。

薔薇靈動的持續創新

也許是名字裡有個帶刺的東西，薔薇靈動的微隔離之路一直行走在荊棘之中，微隔離這事遠看紅紅火火，嬌嬌艷艷，伸手沒有不被扎的。尤其是在雲端原生環境下，千差萬別的網路套件為微隔離的實現帶來了極大挑戰，而作為國內唯一一家除了微隔離啥也不做的死心眼企業，薔薇也沒有別的選擇，只能拼盡全力去迎接挑戰，好在雖然說紮了一身的刺，但總算是蹚出來了一條路，今天我們在國內運營著數萬點級別的雲原生微隔離網絡，也算是為國內網絡安全貢獻了自己的力量。

但是，技術進步是永遠沒有止境的，在跟用戶的協同創新過程中，很多用戶都希望我們能夠以更「雲原生化」的方式來幹這個事，這會讓他們的運維更簡單、安裝部署更容易、內部協同更有效率。

使用者的需求就是我們的動力，於是我們就做了基於DaemonSet的新版本出來。從Agent到DaemonSet，事實上還是有很多難度的，Agent在取得宿主機權限後，事實上它幹啥事都比較方便，但是一旦被做成了DaemonSet，它相當於和宿主機隔了一層，這一層就為我們做微隔離的許多必要動作帶來了重大阻礙。

更多的就不說了，反正挺費勁，好在薔薇靈動的工程師一路走來也沒幹過啥不費勁的事，總算還是把一系列的困難克服掉，並成功發布了新的版本，套用一句小學作文收個尾吧——

「辛苦的一天結束了，薔薇靈動的工程師擦了擦額頭的汗水，看著夕陽下熠熠生輝的超大規模雲原生零信任網絡，臉上露出了欣慰的笑容」。