当前位置：首页 > news >正文

Kubernetes网络策略实战：精准控制frontend与backend跨-tail通信

news 2025/10/2 6:40:23

Kubernetes NetworkPolicy 实战：精准配置 frontend 与 backend 跨命名空间通信

在 Kubernetes 集群中，默认的网络策略是 “全通” 模式 —— 所有 Pod 可以不受限制地与其他 Pod 通信。这种宽松的网络环境虽然简化了初期部署，但在生产环境中存在巨大安全风险：一旦某个 Pod 被入侵，攻击者可能横向渗透整个集群。而 NetworkPolicy 作为 Kubernetes 原生的网络安全工具，能通过 “白名单” 机制精准控制 Pod 间的通信，实现 “最小权限” 的安全原则。

本文将以 “允许 frontend 与 backend 跨命名空间通信” 为核心场景，详细讲解如何分析业务需求、筛选合适的 NetworkPolicy 示例，并安全应用策略，同时避免破坏现有默认策略。

一、需求前置分析：明确通信边界的核心要素

在配置 NetworkPolicy 前，必须先掌握 frontend 和 backend Deployment 的关键信息—— 这些信息是策略的 “灵魂”，直接决定策略是否精准。我们需要通过 kubectl 命令获取以下核心数据：

1.1 确定命名空间（Namespace）

首先确认两个 Deployment 所在的命名空间（题目已明确为 frontend 和 backend，但实际场景中需验证）：

# 查看 frontend 命名空间下的 Deploymentkubectl get deploy -n frontend# 查看 backend 命名空间下的 Deploymentkubectl get deploy -n backend

输出示例（确认命名空间正确性）：

NAME READY UP-TO-DATE AVAILABLE AGEfrontend 2/2 2 2 1hNAME READY UP-TO-DATE AVAILABLE AGEbackend 2/2 2 2 1h

1.2 提取 Pod 标签（Labels）

NetworkPolicy 通过 Pod 标签 筛选目标 Pod，因此需要获取 frontend 和 backend Pod 的标签（标签通常在 Deployment 的 spec.template.metadata.labels 中定义）：

# 查看 frontend Deployment 的标签配置kubectl get deploy frontend -n frontend -o jsonpath='{.spec.template.metadata.labels}'# 查看 backend Deployment 的标签配置kubectl get deploy backend -n backend -o jsonpath='{.spec.template.metadata.labels}'

输出示例（关键标签）：

{"app":"frontend","env":"prod"} # frontend Pod 标签{"app":"backend","env":"prod"} # backend Pod 标签

这里的 app: frontend 和 app: backend 是最核心的标签，将作为 NetworkPolicy 中 podSelector 的匹配条件。

1.3 确认通信端口（Port）

frontend 与 backend 的通信必然依赖特定端口（如 backend 暴露 8080 端口提供 API 服务），需确认 backend 容器的暴露端口：

# 查看 backend Deployment 的端口配置kubectl get deploy backend -n backend -o jsonpath='{.spec.template.spec.containers[0].ports}'

输出示例（明确通信端口）：

[{"containerPort":8080,"name":"api","protocol":"TCP"}]

即 frontend 需要访问 backend 的 8080 端口，这将作为 NetworkPolicy 中 ports 的限制条件。

1.4 梳理通信流向

根据业务逻辑，通常是 frontend 主动发起请求，backend 被动接收请求，因此通信流向为：

frontend（命名空间：frontend，标签：app=frontend） → backend（命名空间：backend，标签：app=backend，端口：8080）

基于此流向，我们只需给 backend 配置 “入站允许策略”（允许来自 frontend 的入站流量），或给 frontend 配置 “出站允许策略”—— 推荐前者，因为在 “被访问方” 配置入站策略更符合 “最小权限”，可避免 frontend 向其他无关服务发起请求。

二、理解默认策略：不可触碰的安全基础

题目明确要求 “请勿删除或修改现有的默认拒绝所有入站 / 出站流量的 NetworkPolicy”，这是整个配置的前提。为什么默认拒绝策略如此重要？

2.1 默认拒绝策略的作用

默认拒绝策略（通常命名为 default-deny-ingress 或 default-deny-egress）的核心作用是：

入站默认拒绝：所有 Pod 默认不接收任何外部流量，仅通过显式 NetworkPolicy 允许必要通信；

出站默认拒绝：所有 Pod 默认不发起任何外部请求，避免 Pod 向集群外或无关服务发送数据。

这类策略是集群网络安全的 “底线”，修改或删除会导致：

未授权的 Pod 可访问敏感服务（如数据库）；

被入侵的 Pod 可向外部泄露数据；

整个集群网络回到 “全通” 的不安全状态，可能直接导致测试零分。

2.2 验证默认策略状态

在操作前，建议先确认默认策略的存在性，避免误操作：

# 查看所有命名空间的 NetworkPolicykubectl get netpol --all-namespaces

若输出包含类似以下内容，说明默认拒绝策略已存在，需严格保留：

NAMESPACE NAME POD-SELECTOR AGEdefault default-deny-ingress {} 7ddefault default-deny-egress {} 7d

三、筛选合适的 NetworkPolicy 示例：拒绝宽松，精准匹配

接下来需要分析 ~/netpol 文件夹下的 NetworkPolicy 示例，核心筛选原则是：不过于宽松，仅允许 frontend 与 backend 通信。

3.1 常见示例的对比与筛选

假设 ~/netpol 下有 3 个示例文件，我们逐一分析其合理性：

示例 1：过于宽松的策略（排除）

netpol-allow-all.yaml：

apiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata:name: allow-all-to-backendnamespace: backendspec:podSelector:matchLabels:app: backend # 目标是 backend PodpolicyTypes:- Ingressingress:- from:- namespaceSelector: {} # 允许所有命名空间访问ports:- protocol: TCPport: 8080

问题：namespaceSelector: {} 表示允许 “所有命名空间” 的 Pod 访问 backend，完全不符合 “不过于宽松” 的要求，直接排除。

示例 2：精准匹配的策略（选择）

netpol-allow-frontend-to-backend.yaml：

apiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata:name: allow-frontend-to-backendnamespace: backend # 在 backend 命名空间配置入站策略spec:podSelector:matchLabels:app: backend # 目标 Pod：backend 命名空间下标签为 app=backend 的 PodpolicyTypes:- Ingress # 仅控制入站流量ingress:- from:# 源条件1：来自 frontend 命名空间- namespaceSelector:matchLabels:kubernetes.io/metadata.name: frontend # 匹配 frontend 命名空间（注：部分集群用 name=frontend）# 源条件2：该命名空间下标签为 app=frontend 的 PodpodSelector:matchLabels:app: frontend# 允许的端口：仅 8080（backend 暴露的业务端口）ports:- protocol: TCPport: 8080

优势：

精准限制 “源”：仅允许 frontend 命名空间下 标签为 app=frontend 的 Pod 访问；

精准限制 “目标”：仅作用于 backend 命名空间下 标签为 app=backend 的 Pod；

精准限制 “端口”：仅允许访问 8080 端口，不开放其他端口；

仅控制入站流量：不影响 backend 向其他必要服务的出站通信（如连接数据库）。

完全符合 “不过于宽松” 且 “满足通信需求” 的要求，是正确选择。

示例 3：方向错误的策略（排除）

netpol-allow-backend-to-frontend.yaml：

apiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata:name: allow-backend-to-frontendnamespace: frontendspec:podSelector:matchLabels:app: frontendpolicyTypes:- Ingressingress:- from:- namespaceSelector:matchLabels:name: backendpodSelector:matchLabels:app: backendports:- protocol: TCPport: 80

问题：策略控制的是 “backend 访问 frontend”，与实际业务流向（frontend 访问 backend）完全相反，无法满足需求，排除。

3.2 筛选结论

最终选择 netpol-allow-frontend-to-backend.yaml—— 该策略严格遵循 “最小权限” 原则，仅开放 frontend 到 backend 的必要通信，无多余权限。

四、应用策略与验证：确保通信正常且安全

4.1 应用 NetworkPolicy

进入 ~/netpol 文件夹，执行应用命令（仅应用筛选出的正确策略）：

# 进入 netpol 目录cd ~/netpol# 应用正确的 NetworkPolicykubectl apply -f netpol-allow-frontend-to-backend.yaml

输出 networkpolicy.networking.k8s.io/allow-frontend-to-backend created 表示应用成功。

4.2 验证策略有效性

策略应用后，需从 “正向” 和 “反向” 两个维度验证，确保：

frontend 能正常访问 backend；

其他无关 Pod 无法访问 backend（避免过于宽松）。

正向验证：frontend 访问 backend

进入 frontend 命名空间的一个 Pod：

# 获取 frontend Pod 名称FRONTEND_POD=$(kubectl get pod -n frontend -l app=frontend -o jsonpath='{.items[0].metadata.name}')# 进入 Pod 内部kubectl exec -it $FRONTEND_POD -n frontend -- /bin/sh

在 Pod 内部访问 backend 的服务（backend 服务名通常为 backend，域名格式为服务名.命名空间.svc.cluster.local）：

# 测试访问 backend 的 8080 端口curl -I backend.backend.svc.cluster.local:8080

若返回 HTTP/1.1 200 OK，说明通信正常，策略生效。

反向验证：无关 Pod 无法访问 backend

创建一个测试 Pod（位于 default 命名空间，无 app=frontend 标签）：

kubectl run test-pod --image=busybox:1.35 --command -- sleep 3600

进入测试 Pod，尝试访问 backend：

kubectl exec -it test-pod -- /bin/sh# 测试访问 backendcurl -I backend.backend.svc.cluster.local:8080

若返回超时（如 curl: (7) Failed to connect to backend.backend.svc.cluster.local port 8080 after 10000 ms: Connection timed out），说明策略成功阻止了无关 Pod 的访问，未过于宽松。

4.3 再次确认默认策略未被修改

验证完成后，再次检查默认拒绝策略是否存在：

kubectl get netpol --all-namespaces | grep default-deny

若仍能看到 default-deny-ingress 和 default-deny-egress，说明默认策略未被破坏，符合题目要求。

五、关键注意事项与最佳实践

始终基于标签筛选：避免使用 podSelector: {}（匹配所有 Pod）或 namespaceSelector: {}（匹配所有命名空间），这类配置会导致策略过于宽松；

明确端口限制：除非必要，否则不要开放所有端口（ports: []），仅允许业务所需的特定端口；

优先在被访问方配置入站策略：如本文中在 backend 命名空间配置入站策略，比在 frontend 配置出站策略更精准，可减少 “误授权” 风险；

不修改默认拒绝策略：默认拒绝是集群网络安全的基础，任何情况下都不应删除或修改，如需调整，需通过新增策略实现；

应用前先备份示例：若对示例有疑问，可先复制一份再分析，避免误改原始示例导致分数降低。

总结

Kubernetes NetworkPolicy 的核心价值在于 “精准控制”—— 通过明确 “源（谁能访问）、目标（访问谁）、端口（通过哪个端口访问）”，实现 “最小权限” 的安全通信。在本次实战中，我们通过 “分析需求→筛选策略→应用验证” 的流程，既满足了 frontend 与 backend 的跨命名空间通信需求，又保证了策略不过于宽松，同时保留了现有默认策略的安全性。

掌握这套方法论后，无论面对何种业务场景，都能快速定位 NetworkPolicy 的配置核心，构建安全、可控的 Kubernetes 网络环境。

查看全文

http://www.dtcms.com/a/430909.html