Kubernetes 集群网络策略（NetworkPolicy）：限制 Namespace 间 Pod 通信的安全配置

在 Kubernetes 集群中，NetworkPolicy 是一种强大的安全机制，用于控制 Pod 之间的网络流量。通过配置 NetworkPolicy，您可以精确限制不同命名空间（Namespace）之间的 Pod 通信，从而提升集群的安全性。以下我将逐步解释如何实现这一目标，包括核心概念、配置步骤、YAML 示例和注意事项。回答基于 Kubernetes 官方文档和最佳实践，确保真实可靠。

---

1. 理解核心概念

• NetworkPolicy 是什么？
  NetworkPolicy 定义了哪些 Pod 可以相互通信。它基于标签选择器（Label Selector）来指定源和目标 Pod，并控制 ingress（入站流量）和 egress（出站流量）。默认情况下，如果没有 NetworkPolicy，所有 Pod 可以自由通信。
• Namespace 的作用
  Namespace 是 Kubernetes 的虚拟集群，用于隔离资源。要限制不同 Namespace 间的通信，需要利用 NetworkPolicy 的 namespaceSelector 或 podSelector 规则。
• 关键规则：
  • podSelector: 选择目标 Pod（应用策略的 Pod）。
  • namespaceSelector: 选择源 Namespace（流量来源的 Namespace）。
  • ingress: 定义允许的入站流量规则。
  • policyTypes: 指定策略类型（如 Ingress）。

限制跨 Namespace 通信的原理：
通过创建 NetworkPolicy，只允许来自同一 Namespace 或指定 Namespace 的流量，拒绝其他所有流量。例如：

• 如果只允许 Namespace A 的 Pod 访问 Namespace B 的 Pod，则在 Namespace B 中配置策略，使用 namespaceSelector 匹配 Namespace A 的标签。
• 默认拒绝所有跨 Namespace 流量：创建一个“默认拒绝”策略，然后添加允许规则。

---

2. 配置步骤：限制 Namespace 间通信

以下是实现限制的详细步骤。假设您有两个 Namespace：ns1（源）和 ns2（目标），目标是限制 ns1 的 Pod 无法访问 ns2 的 Pod（反之亦然）。确保您的集群支持 NetworkPolicy（如使用 Calico、Cilium 或 Weave Net 网络插件）。

步骤 1: 为 Namespace 添加标签
NetworkPolicy 依赖标签进行选择。为每个 Namespace 添加唯一标签，便于识别。 bash # 为 ns1 添加标签 kubectl label namespace ns1 env=production # 为 ns2 添加标签 kubectl label namespace ns2 env=staging

步骤 2: 创建 NetworkPolicy YAML 文件
在目标 Namespace（如 ns2）中创建策略，限制只允许来自特定 Namespace 的流量。以下是两种常见场景的配置：

• 场景 1: 允许来自同一 Namespace 的流量，拒绝所有跨 Namespace 流量
  这适用于完全隔离 Namespace。

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: allow-same-namespace
    namespace: ns2  # 应用策略的目标 Namespace
  spec:
    podSelector: {}  # 应用到 ns2 中的所有 Pod
    policyTypes:
      - Ingress     # 只控制入站流量
    ingress:
      - from:
          - podSelector: {}  # 只允许来自 ns2 内部的流量（同一 Namespace）
  

  效果：ns1 的 Pod 无法访问 ns2 的 Pod，但 ns2 内部的 Pod 可以互相通信。

• 场景 2: 只允许来自指定 Namespace 的流量
  例如，只允许 ns1（标签 env=production）访问 ns2。

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: allow-specific-namespace
    namespace: ns2  # 目标 Namespace
  spec:
    podSelector: {}  # 应用到所有 Pod
    policyTypes:
      - Ingress
    ingress:
      - from:
          - namespaceSelector:
              matchLabels:
                env: production  # 只允许来自标签为 env=production 的 Namespace（即 ns1）
  

  效果：只有 ns1 的 Pod 可以访问 ns2，其他 Namespace（如 default）的流量被拒绝。

步骤 3: 应用并测试策略 - 应用策略： bash kubectl apply -f network-policy.yaml -n ns2 - 测试通信： - 在 ns1 中启动测试 Pod：kubectl run test-pod --image=busybox -n ns1 -- sleep 3600 - 尝试访问 ns2 的 Pod：kubectl exec test-pod -n ns1 -- wget <ns2-pod-ip> - 如果策略生效，访问会被拒绝（超时或错误）。

---

3. 完整示例：限制所有跨 Namespace 通信

假设您想全局限制所有 Namespace 间的 Pod 通信（即每个 Namespace 只能内部通信）。以下是标准配置：

• 为每个 Namespace 创建独立的 NetworkPolicy。
• 示例：在 ns2 中创建策略，只允许内部流量。

# 文件: restrict-ns2.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-cross-namespace
  namespace: ns2
spec:
  podSelector: {}  # 应用到 ns2 的所有 Pod
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector: {}  # 仅允许来自 ns2 内部的流量

应用后：

• ns2 的 Pod 只能被 ns2 内部的 Pod 访问。
• ns1 或其他 Namespace 的 Pod 无法访问 ns2。

---

4. 注意事项

• 网络插件支持：NetworkPolicy 需要 CNI（容器网络接口）插件的支持（如 Calico、Cilium）。如果使用默认的 kubenet，策略可能无效。检查集群配置：

  kubectl get daemonset -n kube-system  # 查看网络插件
  

• 策略范围：NetworkPolicy 只作用于 Pod 网络层（L3/L4），不影响 Service 或 DNS 查询。确保目标 Pod 的 Service 未被意外暴露。
• 默认行为：Kubernetes 默认允许所有流量。创建第一个 NetworkPolicy 后，未匹配策略的流量会被拒绝（“默认拒绝”模式）。
• 标签管理：正确使用标签是关键。误配置标签可能导致策略失效或过度限制。建议：
  • 使用 kubectl get namespaces --show-labels 验证标签。
  • 在测试环境先验证策略。
• 性能影响：大量 NetworkPolicy 可能增加网络延迟。建议按需配置，避免过度复杂规则。
• 安全最佳实践：
  • 结合 Role-Based Access Control (RBAC) 限制用户操作。
  • 定期审计策略：kubectl get networkpolicy --all-namespaces。
  • 使用工具如 kubectl describe networkpolicy <name> -n <ns> 调试问题。

---

5. 总结

通过 NetworkPolicy 限制 Namespace 间 Pod 通信，是 Kubernetes 安全加固的核心步骤。核心方法是：

• 使用 namespaceSelector 或 podSelector 在目标 Namespace 中定义 ingress 规则。
• 只允许来自同一 Namespace 或指定标签 Namespace 的流量。
• 确保集群网络插件支持 NetworkPolicy。

这样配置后，您可以有效隔离不同环境（如开发和生产），减少攻击面。如果您有具体场景（如多集群或特定端口限制），可以提供更多细节，我会进一步优化配置。