创载（TOPJOYS)

(资料图片)

是一个连接网络·企业·服务 的一站式IT解决方案服务商，专业介绍如何利用思科先进技术解决客户难题。每期聚焦一个技术热点或应用场景，深入浅出地介绍，为you需求者提供实用性强的建议。

网络的可视化改善了云原生应用的体验，在经典应用环境中的安全其实也有相当一部分是落在网工肩头的，有没有可能在云原生的安全领域网工们也能一显身手呢？然而事实是，尽管有超过 91% 的企业架构师在担心自己云原生环境的运营和安全，但云原生安全的热点仍集中在应用开发和应用运行自身，远没有像在经典应用环境中那样频繁出现网工们忙碌的身影。这是不是因为在云原生环境中不再需要传统意义的网络安全呢？

显然不是。任何应用级安全都一样需要依赖基础架构提供安全的基础，包括应用所在节点的系统级安全，应用所在的网络环境安全等等，它们就像组成木桶的木板，任何一处短板都会影响整体系统的安全级别，特别是云原生强大的可移植性使得它们所在的基础架构环境比以往更加复杂，零信任往往会成为大多数云原生运行环境的金标准，那就更不能轻易放弃基础架构这块木板。

网工们驰骋安全届的几个法宝：网络分段，访问控制列表（ACL），防火墙，流量监测等等，都对 IP 子网、地址、VLAN、网关等网络逻辑结构有强烈依赖，使得经典环境里网络部门往往是安全的核心部门，由网工负责防火墙、IDS/IPS 等经典安全设备是很多企业的标配。

而在云原生环境里，网络逻辑结构配置不仅大权旁落，甚至防火墙、IDS 这些设备本身似乎也变的可有可无——容器地址不停的流转变换，微服务副本不再局限于一个看得见的网络分段边界，流量本身也被封装在各式 Overlay 隧道内，网工手里的 ACL、防火墙、IDS 等有劲使不上，而基于URL等应用层元素的过滤、基于服务注册的访问控制等好像分分钟都能取而代之。但是各种安全威胁可不会规矩的待在开发者视角的应用层内，它们可以在网络的第3、4 层上发起攻击，在节点操作系统上也可绕过上层应用而制造麻烦，甚至管理员的一些无意之失也需要有个边界实现差错隔离，或有可追溯的地址便于跟踪定位。网络逻辑边界定义、流量过滤、攻击面保护、地址管理跟踪、流量异常分析和威胁感知…这些正是网工们的 “传统艺能” ，只是需要在云原生环境里全面升级。

我们知道云原生应用处于应用、系统和网络三重环境，网工所在的基础架构部门的职责更多在系统和网络，那么我们就从网络环境安全的升级谈起。

首先升级的是网络环境中对南北向也就是跨云或容器集群之间的流量的安全保护。虽然正常的应用只需要对外发布服务地址，但容器/Pod 对外的三四层通信是完全敞开的，需要网络部门保证所有 Pod 对外通信畅通的同时，能够有效缩减和保护三四层攻击面。但大部分 Pod 的容器网络接口（CNI）的 IP 地址管理（IPAM）都遵循从本地节点动态分配地址的原则，因而一个跨多节点的微服务是由来自众多分散的子网 IP 构成，而且还随着副本的伸缩而动态变化，这对边缘防火墙根据地址做安全审计和 ACL 策略提出了巨大挑战。不知各位是否还记得上期提到的思科多云中间件系统（MMS），它可以一键把 Kubernetes 容器集群与基础网络按最佳实践整合起来。上次重点强调的是 MMS 自动部署后流量的无隧道化，增强了性能、可视化和可控性，但还有一个重要功能就是提供了图形化的统一地址管理。这个 “统一” 一方面是指我们可以跨 VMware、OpenStack、Kubernetes 等多种不同云系统用统一的地址管理规范从统一的地址池中 “挖出” 某个云的某个服务所需要的地址块和子网，另一个 “统一” 也包括在一个云内部，可以把一个或多个 IP 子网赋予指定服务的成员，无论它们是容器还是虚机，无论是否分散在众多节点上，它们都将只从指定的子网取地址，这样在这个云出口的防火墙上我们可以轻松针对这个服务设置策略，做具备服务感知的流量审计和跟踪。下图就是我们把选好的 IP 子网绑定到指定微服务 Payments-V1 上，以后就可以用这个子网代表这个微服务内所有容器 Pod 。

而在下图中同样通过 MMS 的图形界面在云的出口利用刚才绑定的 IP 子网名称配置 ACL 策略，实现流量审计和管控。MMS 支持多家防火墙、交换机和路由器的 ACL 策略编排。

云原生集群内是一个 Pod 之间 IP 全连通的环境，这无疑是安全攻击和误操作传播的沃土，在零信任的大趋势下，集群内的东西向微分段就成为了必须的配置。其实 Kubernetes 早在 1.7 版本开始就内置了三/四层访问控制功能—— Network Policy ，但在实际中用得不多，一方面云和应用团队很不习惯用网络策略思维进行访控，另一方面网络团队普遍也不熟悉 Kubernetes ，就更不要说精通 YAML 这种配置代码来做管控策略了。正如我们前面屡次遇到的，当某类任务云团队和网络团队都需要但都不愿意自己来完成时，作为云网 “粘合剂” 的多云中间件就又可以施展身手了。MMS 可以将网络团队熟悉的 VLAN 或逻辑组之间的访问控制策略转换为 Kubernetes 的 Network Policy YAML 配置，发送给云/应用团队审核或者一键下发到云原生环境中实现。网络策略可以形象的用网工们熟悉的拓扑表示，MMS 预置了许多这样的拓扑模板，包括 Web / App / DB 三层模型、n 个策略组全连通模型等等，网工们只要在这个模板基础上稍微加工一些参数，比如允许的协议和端口号、IP 地址范围等等，无须精通 Kubernetes Network Policy 原理和语法也能玩转云原生集群内的微分段。更值得一提的是，这套用拓扑表示的网络策略模板完全与云类型解耦，不仅可以用于 Kubernetes ，还可以用于 VMware vSphere 、OpenStack 、甚至 AWS 等公有云，也就是说这个模板我们只需创建一次，就可以一键复用到多种不同的云上，网工们不用费劲学习和更新不同云上网络设置的知识，只需要把精力放到自己应用逻辑组的拓扑关系和具体策略上，绘制出统一的策略模板后，MMS 将自动负责实现在多种不同的云上。过去在云之间迁移某个应用的复杂网络策略，或者保持多个云的网络策略合规一致是一个颇为棘手的工作，现在通过 MMS 都可轻而易举的完成。下图就是我们在 MMS 上挑选合适的模板（当然也可以自己编辑更多的新模板供以后调用）。

下图我们正准备把已选定的策略模板一键同时下发到多个不同的公有云和私有云上：

在这个模板上加工一些定制化策略：

下图是提交前呈现给管理员以及云/应用部门的策略预览，同时提供 JSON 和 YAML 两种版本，并可以选择是否同时在 Cloud 上将该套配置生效（考虑到有时需要审批或者网络部门不一定有权限操控云端的配置，MMS 可以只在这一步把配置代码呈现出来以供参考，并不去改动实体配置）。