Kubernetes 网络策略最佳实践

发布时间：

2024-08-02 19:00

作负载容器化到 Kubernetes Pod 中时，控制和过滤流量同传统网络中的防火墙一样重要。在这种情况下，这些能力由 Kubernetes 的 NetworkPolicy API 提供。

本文将通过创建一个示例网络策略来探索 Kubernetes NetworkPolicy，并检查其核心参数。然后，我们将看一些常见的 NetworkPolicy 用例，并学习如何使用 kubectl 进行监控。最后，我们将发现如何使用第三方 Kubernetes 扩展实现容器网络接口（CNI）。

一：为何配置Kubernetes网络策略

实施网络策略对于运行 Kubernetes 环境至关重要。如果没有配置网络策略，集群内的所有 Pod 默认可以相互通信。因此，当我们的 Pod 包含敏感数据时，例如存储机密信息的后台数据库，我们必须确保只有特定的前端 Pod 可以连接到它。另外，我们可以将开发环境中的 Pod 与生产环境中的 Pod 的网络流量隔离开来。没有网络策略，所有流量在网络中的各个点之间自由流动。幸运的是，配置 Kubernetes NetworkPolicy 是一种简单、有效且全面的方法，确保我们的网络流量只按预期的方式流动。

二：定义Kubernetes网络策略

让我们来看一个示例 NetworkPolicy。考虑一个包含 WordPress 前端和 MySQL 数据库后端的示例工作负载，运行在包含 Web 和数据库服务的 Pod 集合中，并且都部署在 Kubernetes 的默认命名空间内。公司的安全协议要求我们隔离特定工作负载的网络流量，并允许这些工作负载使用最少必要的进出流量。这种策略包括以下条件：

阻止允许所有流量的默认 Kubernetes 行为
确保只有默认命名空间中标记为 wordpress 的 Pod 可以相互通信
允许来自公共互联网的端口 80/443 和 172.16.0.0 IP 范围的传入（ingress）连接
只允许标记为 wordpress 的 Pod 连接到 MySQL 数据库 Pod 的 3306 端口
始终允许连接到 Kubernetes DNS 服务（53 端口）
阻止所有集群外的传出连接。

让我们了解上面使用的几个参数，以了解它们与配置的关系以及它们如何影响网络流量行为。API 和元数据

在下面YAML文件的第一行中，我们指定了网络API（networking.k8s.io）及其版本（v1）。我们还将YAML文件的类型定义为NetworkPolicy，告知Kubernetes API控制器我们正在配置网络策略。元数据部分的名称和命名空间项包含了我们为此规则集指定的名称以及与之关联的命名空间。

YAML文件的下一部分包含规范（specs）部分，我们可以在其中规定网络策略将应用的过滤器。下面的段落包含几个重要的参数：

lpodSelector指定哪些Pod需要遵守规定的流量策略。在我们的示例中，使用matchLabels参数确保网络策略适用于所有带有app: wordpress标签的Pod。作为次要结果，此参数将所有其他Pod排除在此网络策略之外。
lpolicyTypes 包含两类：Ingress和Egress nIngress定义所有传入的Pod/命名空间/Pod集合流量 nEgress 定义所有传出的Pod/命名空间/Pod集合流量

接下来，网络策略的ingress部分定义了允许的传入流量类型。以下部分允许来自以下来源的443和80端口的传入流量：所有带有wordpress标签的Pod 所有公共互联网流量（`cidr: 0.0.0.0/0`）范围为172.16.0.0/16`的所有IP地址，这可能代表公司IP范围（如VPN、VLAN或子网）启用上述流量的YAML片段如下所示：

最后，我们详细说明了egress部分的传出流量规则。我们允许带有webapp标签的Pod在1433端口（SQL）和53端口（DNS）上进行所有传出流量通信。指定webapp标签确保没有其他Pod可以与SQL Server实例通信，从而消除所有相关的安全风险。同样，该配置允许53端口连接到集群中的所有Pod。从此策略定义中还有一个关键点。一旦我们集成网络策略来控制Pod的连接性，就需要在两个方向上配置允许/拒绝设置。仅允许前端的传出流量而不允许后端的传入流量将阻止通信。此部分流量的YAML片段如下所示：

我们现在已经完成了示例YAML网络策略清单，具体如下：

现在，我们需要将这个文件注入到Kubernetes集群中。首先，将这个文件保存为sample-network-policy.yaml。然后，像大多数其他Kubernetes配置一样，使用kubectl命令行接口（CLI）应用定义文件。运行以下命令：

三：验证和监控Kubernetes网络策略

类似于传统的防火墙管理，验证和监控Kubernetes网络策略需要操作上的监督。我们需要定期重新评估现有的网络规则，以确定它们是否仍然适用于相关的工作负载。我们还可能需要验证规则库，以排查流量问题或调查不同网络策略之间的冲突。幸运的是，我们可以使用`kubectl`命令行接口（CLI）来验证网络策略。运行以下命令可以分析和监控当前的网络策略：

四：应用Kubernetes网络策略的最佳实践

与任何网络安全配置一样，我们在使用Kubernetes网络策略时应采用一些最佳实践：

- 使用默认的“拒绝所有”网络策略，确保只有明确允许的通信才能发生。

- 使用PodSelector参数对必须相互通信的Pod进行分组。

- 仅在必要时允许跨命名空间通信。

- 不允许不必要的网络通信——即使在Kubernetes集群内部。

- 允许集群内的Pod接收非集群网络流量时要谨慎。

- 拒绝传出的公共互联网流量可能会干扰某些应用程序的更新或验证过程。

五：Kubernetes CNI插件好处

CNI插件的一个好处是它们抽象了网络策略的实现细节，确保集群管理员可以选择最适合其需求的解决方案，而不必暴露底层技术的复杂性。

六：结论

Kubernetes 网络策略是确保容器化工作负载安全的关键工具。通过理解和正确配置 NetworkPolicy，我们可以实现对网络流量的精细控制，保护我们的应用程序和数据安全。遵循最佳实践并利用合适的 CNI 插件，可以帮助我们更好地管理和优化 Kubernetes 网络策略，确保我们的集群在安全性和性能上都达到最佳状态。