导航：首页 > 互联网科技 >

如何通过Kubernetes网络策略进行应用程序微分段

发表于：2025-01-23 作者：千家信息网编辑

千家信息网最后更新 2025年01月23日，如何通过Kubernetes网络策略进行应用程序微分段，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。在大多数生产环境中，需要实施网络

千家信息网最后更新 2025年01月23日如何通过Kubernetes网络策略进行应用程序微分段

如何通过Kubernetes网络策略进行应用程序微分段，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。

在大多数生产环境中，需要实施网络访问控制。Kubernetes提供了一种方法来描述Pod 组应该如何通过使用NetworkPolicy资源进行通信。

与Kubernetes中的大多数事情一样，要使网络策略正常运行，您需要一个支持它们的Kubernetes CNI插件。

使用场景

在几乎所有环境中，为应用程序需要通信的组件建立明确的规则，都是一个好主意。Kubernetes网络策略规范是一种直接的方法，可让您将NetworkPolicy直接与应用程序清单集成在一起。

NetworkPolicy定义资源的方式，使您可以精确地指定哪些网络通信是被允许的，而哪些则不允许，同时使用podSelector定义处理在Kubernetes上运行的应用程序的动态属性。

这意味着您的策略可以针对单个Pod或Pod组，从而将安全范围"缩小"到Pod的大小。

严格定义的网络策略与default-deny配置相结合，可以避免由于恶意应用程序入侵，和/或行为不当，或者配置错误而造成的麻烦。例如，一个应用程序组件可能具有滞留的缓存DNS条目或错误的配置参数，导致它与错误的后端进行通信。或者应用程序可能会被攻陷并被用作跳板，执行侦查，尝试横向渗透，或者只是使用Pod对Kubernetes API的访问权限来启动一些加密货币挖矿Pod，以窃取您的计算资源。

使用网络策略保护示例应用程序的安全

网络策略设计的主题比本指南中允许的空间要大得多。在此示例中，我们将执行以下操作：

为我们的default命名空间创建一个default-deny Ingress策略。这意味着命名空间内的所有传入Pods的连接必须明确被允许；

为每个示例应用程序组件创建一个Ingress NetworkPolicy对象，仅允许那些我们确定的对象。

步骤1：明确哪些组件应当可以相互通信

首先，我们需要提醒自己，应用程序的各个组件应该如何通信。为此，我们将回到在简介中看到的应用程序图：

从该图中可以看到：

1. 外界需要到达yelb-ui的TCP端口80-（1）和（2）

2. yelb-ui需要到达yelb-appserver的TCP端口4567

3. yelb-appserver反过来将需要到达yelb-db的TCP端口5432，以及

4. .. yelb-cache的TCP端口6379。

步骤2：如何识别组件？

请记住，NetworkPolicy资源使用选择器来识别策略适用于哪个Pod，以及该策略将要控制的流量的源和目的地是什么。

在本演示中，我们将使用podSelectror方法，因此需要获取应用到应用程序Pod的标签列表。让我们查看cnawebapp-loadbalancer.yaml示例应用程序的清单，并收集标签：

现在准备编写我们的策略。

部署后，这些策略将以以下方式控制应用程序组件之间的通信：

步骤3："default-deny"策略

确保您位于沙箱控制节点上，以root用户身份登录，并且位于正确的目录中：

# 确认您是root账户

whoami | grep root || sudo -s

# 切换到清单目录

cd /home/centos/yelb/deployments/platformdeployment/Kubernetes/yaml

在此步骤中，我们将创建一个策略，该策略将阻止所有未明确允许的网络通信。在这一演示中，我们将只限制Ingress流量；但实际上，您也可以控制Egress流量（但是这样做时要注意这可能会阻止DNS查询！）：

该策略基本上说："对于任何Pod，都应用一个没有规则的Ingress策略"，这将导致应用这个策略的，所有流向这个命名空间Pods的传入流量被丢弃掉。

步骤4："yelb-ui"的策略

该yelb-ui和其他组件在某种意义上说有一些不同，因为它是唯一一个可以被从外部访问的组件。因此，其ingress:定义将使用ipBlock的0.0.0.0/0，以表示"每个人"：

该策略表示："对于具有应用标签app: yelb-ui和tier: frontend的Pods，允许传入来自任何源IP的流量，只要它去往Pod的TCP端口80"。

步骤5：示例应用中其他Pod的策略

我们示例应用程序中的其他3个Pod仅会看到来自其他Pod的流量，因此其策略将使用带有允许发送流量的Pod标签的podSelector参数：

步骤6：在应用策略之前测试

为了能有一个"前后"对比，让我们部署示例应用程序并获取基线：

# 部署我们的应用

kubectl create -f cnawebapp-loadbalancer.yaml

等待应用启动并在外部可用：

# 获得我们程序yelb-ui Service的外部DNS名字:

kubectl get svc -o wide | grep yelb-ui | awk '{print $4}'

我们应该可以看到类似a0b8dfc14916811e9b411026463a4a33-1258487840.us-west-1.elb.amazonaws.com的输出；在网络浏览器中打开它；样本应用程序应当加载了。

接下来，我们知道所有Pod通信都是不受限制的，因此我们应该能够从yelb-ui ping 到yelb-db--这是在应用程序正常运行且我们不进行故障排除动作的情况下，本来不应该发生的活动：

# 获得"yelb-ui"的完整Pod名字

src_pod=$(kubectl get pods | grep yelb-ui | awk '{print $1}')

# 获得"yelb-db"的IP:

db_pod_ip=$(kubectl get pods -o wide | grep yelb-db | awk '{print $6}')

# 从"yelb-ui" ping"yelb-db":

kubectl exec -it ${src_pod} ping ${db_pod_ip}

我们应该看到该ping命令正在接收响应；因此存在不受限制的网络连接。按^ C停止命令。

步骤7：部署策略并测试结果

在最后一步，我们将部署策略并观察其效果：

# 部署网络策略

kubectl create -f yelb-policy.yaml

运行上面的命令后，请等待几秒钟以稳定下来。Tungsten Fabric将在后台生成适当的安全组，并进行安装。让我们测试一下我们曾经可以正常运行的ping命令是否仍然有效：

# 从"yelb-ui" ping "yelb-db" again:

kubectl exec -it ${src_pod} ping ${db_pod_ip}

这次，我们看到没有响应，因为该通信现在已被该策略阻止。接下来，测试是否仍可以通过网络浏览器访问该应用--应该可以！

步骤8：探索Tungsten Fabric的安全流量组可视化

Tungsten Fabric包含一个功能，可在"项目"中实现流量可视化，在我们的案例中，该项目对应于Kubernetes Namespace。

要访问它，请访问Carbide Evaluation Page链接，用于获取访问沙箱控制节点--在顶部有一个名为Contrail UI的链接，完成login和password的输入。单击链接，然后在左上角单击"Monitor"图标，然后在菜单中单击"Security" -> "Traffic Groups"。然后在顶部的标签链，在其末尾选择"k8s-default"：