MENU 导航菜单

虚拟云网络专辑 | Antrea 应用于 VMware 方案功能简介（六）

奇正资讯 > VMware资讯 更新时间：2023/5/12

接续前篇《虚拟云网络专辑 | Antrea 应用于 VMware 方案功能简介（五）》对于现行 Kubernetes Network Policies 的限制讨论，从本篇开始我想要用实际的画面与大家展示 Antrea 搭配 NSX Manager 如何来进行等同于企业等级防火墙的 Kubernetes Pods 间安全阻隔功能。相关的 Antrea 搭配 NSX 的架构与安装机制会于后续推文再讨论，但这里我想先针对 Antrea + NSX 的方案内是如何改善前面讨论到的 Network Policies 相关缺点进行讨论，包括了：


● 采用 YAML 文件的方式撰写与维护安全政策过于困难；


● 没有安全日记 （ log ）；


● Network Policies 无法配置 deny 规则，只能设置预设 deny。也就是说，我们不能明确地阻止网络流连线，只能用白名单规则明确地允许哪些网络流可以通过；


● Network Policies 没有顺序。管理者可以针对 Pod 设定多笔规则，但不能限制哪个规则先进行对比。




当我们建立了一个底层采用 Antrea 的 Kubernetes Cluster，并完成与 NSX Manager 整合安装步骤。此时管理者直接在 NSX 的 UI 界面内就可以看到控管的 Kubernetes Cluster 相关信息了。下图是展示环境的画面，在 Inventory–Containers 内，可以看到这个 NSX Manager 有管理三个 Kubernetes Cluster，分别是来自 Tanzu Kubernetes Grid，vSphere with Tanzu 以及原生 Kubernetes。图中针对 tkgm-122-tkc03 这个由 Tanzu Kubernetes Grid 建立的 K8S 丛集，点开看包含 Antrea 本身使用版本，及丛集相关的 Inventory 包含里面有几个 Nodes/Pods/Services/Namespaces 等，都能够明确列出来：


图片


下面两张图列出当我们点击画面里的 Namespaces 还有 Pods 时列出的信息。在图内特别红框的是后续用来展示的 pod（dvwa-deployment-7767887f6f-gvmpv）以及所在的 Namespace（dvwa-ns）。大家可以看到包含 pod 内每个 Labels 也都有列出：


图片
图片


上图内大家可以看到的是当 Antrea 与 NSX 整合完成，NSX Manager 可以取得 Kubernetes Cluster 内的完整构件信息。这代表我们能够通过 NSX 的 UI 界面，依据实际的应用部署，基于 Namespace/Service/Pod Label 等来定义要配置防火墙规则的群组，就如同我们在虚机采用微分段动态安全群组的方法一样。在 Inventory/Group 内，管理者可以配置一个基于 Antrea 的群组，下面两个图内，我们建立了一个叫做 dvwa-ns 的 Antrea 群组，在此群组内，包含了展示 pod（dvwa-deployment-7767887f6f-gvmpv），而这个群组的定义条件是采用只要任何一个在 dvwa-ns 这个namespace 内的 Pod， 都要加入这个组：


图片
图片


在我们要在 NSX 内定义一个 Antrea 的群组时，下列两点需要注意：


● 在配置群组时，要选择 Group Type 是 Antrea。在目前的版本，我们还不能建立一个群组内同时包含虚机以及容器，我们必须指定这个群组是一个 Antrea Group 的型态；


●Antrea 的组里面可以包含两种模式：通过Namespace/Service/Pod Label 来动态选择 Pod ，或是明确的定义一个 IP 范围。




在下图内大家可以看到，如果我们在群组内建立 Pod 选取的条件，总共有三个方式：

● 可以将某个 Namespace 内的所有 Pod 都加入此群组，这个 Namespace 可以通过名称（Name）或是标签（Namespace Label）来定义；


● 可以将包含于某个 Service 内的所有 Pod 都加入此群组，这个 Service 可以透过名称（ Name ）来定义；


● 可以通过 Pod 标签定义（Pod Label）来选择那些 Pod 要加入此群组。




图片


请大家回忆一下之前进行虚机微分段的流程。首先，NSX 透过与 vCenter/vSphere 接入，可以看到所有虚机的名称、操作系统、IP Address 等信息。管理者也可以手动或通过自动化工具，在每个虚机上面打安全标签（Tag）。然后我们能够建立群组，通过指定虚机，或是通过标签、名称、操作系统等条件，纳入需要控管的虚机。最后就能将这些群组运用在防火墙的来源、目的、Apply-To 等字段进行政策配置了。


而在通过 NSX 接口来管理 Kubernetes Cluster 时，NSX 可以直接取得 K8S 丛集内的 Pod/Service/Namespace/Labels 等信息。安全管理者不需要在 NSX 接口内打标签，K8S 管理者在建立 Pod/Deployment 时直接就可以将相关的 Label 配置进去。然后同样地，我们在 NSX 内就可以基于上面的条件，建立对应的 Antrea 群组，来应用到防火墙政策内。


将群组配置完，接下来我们就可以在 NSX Distributed Firewall 内进行 Kubernetes Cluster 内的防火墙政策设定了，在下篇推文内会继续与大家讨论。


本文转载自VMware中国公众号

下一篇：成功案例｜打造绿色数字化畅行通道，助力欧拓汽车全球化发展 上一篇：实现 VMware Anywhere Workspace 的价值