鑽石舞台

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

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

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

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

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

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

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

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

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

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

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

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

什麼是雲原生環境下最恰當的微隔離技術路線呢，答案是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，它相當於和宿主機隔了一層，這一層就給我們做微隔離的很多必要動作帶來了重大阻礙。

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

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