奇正科技_ADOBE福建的唯一授权金牌经销商_微软公司的核心经销商_autodesk的福建区核心经销商_COREL福建省独家经销商_Unity福建授权技术服务商_金山公司(WPS)福建金牌经销商_PTC核心经销商_Altium福建核心经销商

虚拟云网络专辑 | 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中国公众号

Copyright©2018-2024 www.qizsoft.com All Rights Reserved 奇正科技(厦门)股份有限公司 版权所有
备案号:闽ICP备05021918号-1
服务热线 0592-2208610
点击QQ咨询
微信客服扫一扫 微信客服