微隔离的三条路

如果一个用户想要在自己的数据中心里部署微隔离，它有几条路可走呢？根据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，它相当于和宿主机隔了一层，这一层就给我们做微隔离的很多必要动作带来了重大阻碍。

更多的就不说了，反正挺费劲，好在蔷薇灵动的工程师一路走来也没干过啥不费劲的事，总算还是把一系列的困难克服掉，并成功发布了新的版本，套用一句小学作文收个尾吧——

“辛勤劳动的一天结束了，蔷薇灵动的工程师擦了擦额头的汗水，看着夕阳下熠熠生辉的超大规模云原生零信任网络，脸上露出了欣慰的笑容”。