Kubernetes 网络策略之 Network Policy

在当今的云原生时代，Kubernetes 已成为容器编排的基石。然而，Kubernetes 默认的“全部允许”网络模型在简化部署的同时，也埋下了安全隐患。为解决这一痛点，Kubernetes 网络策略应运而生，它如同集群内部的防火墙，对 Pod 间的通信实施精细化控制。本文将基于一份交互式指南，深入探讨 Kubernetes 网络策略的核心概念、实际应用、最佳实践以及高级主题，并提供一个策略生成器，助您轻松构建和应用安全策略。

一、 引言：网络策略，集群安全基石

默认情况下，Kubernetes 集群中的所有 Pod 可以自由通信。这种开放性虽便于初始部署，却为潜在攻击者提供了横向移动的跳板，一旦某个 Pod 被攻破，整个集群的安全将面临威胁。

Kubernetes 网络策略（Network Policy）是一种声明式规范，它定义了 Pod 之间以及 Pod 与其他网络端点之间的通信规则。通过实施网络策略，您可以将网络模型从“默认允许”转变为更安全的“默认拒绝，显式允许”，从而显著缩小攻击面，增强应用程序和服务的安全性。

• 默认状态：完全开放：所有 Pod 都可以相互通信，存在安全风险。
• 应用策略后：受控访问：只有被明确允许的流量才能通过，显著提升安全性。

二、 核心概念速览：构建网络策略的基石

理解 Kubernetes 网络策略的关键在于掌握其核心构建模块：

• Ingress (入站) & Egress (出站)：Ingress 指的是进入 Pod 的流量，Egress 指的是从 Pod 发出的流量。网络策略可以分别或同时对这两种流量进行控制。
• CNI 插件：Kubernetes 本身不执行网络策略，而是依赖于容器网络接口（CNI）插件，例如 Calico 或 Cilium。您的 CNI 必须支持网络策略才能使其生效。
• 默认拒绝行为：一旦为某个 Pod 应用了任何网络策略，该 Pod 的网络模式就会自动切换为“默认拒绝”。所有未被策略明确允许的流量都将被阻止。
• podSelector：策略的核心。它通过标签来选择该策略应用于哪些 Pod。如果为空 {}, 则应用于命名空间下的所有 Pod。
• namespaceSelector：在 ingress 或 egress 规则中使用，用于根据标签选择允许通信的源或目标命名空间。
• ipBlock：允许根据 CIDR 地址块定义流量规则，常用于控制与集群外部服务的通信。

三、 策略实验室：从案例中学习网络隔离

理论结合实践是掌握网络策略的有效途径。以下几个典型应用场景展示了网络策略的强大功能，您可以直接参考这些 YAML 配置并应用到您的环境中：

• 场景一：默认全部拒绝

、

这是建立安全基线的第一步。此策略应用于命名空间下的所有 Pod，并拒绝所有进入和发出的流量。之后，您可以根据需要逐步开放特定流量。

   apiVersion: networking.k8s.io/v1
   kind: NetworkPolicy
   metadata:
     name: default-deny-all
     namespace: my-namespace
   spec:
     podSelector: {}
     policyTypes:
     - Ingress
     - Egress

应用效果：此命名空间下的所有 Pod 之间、与外部的所有通信均被阻止。
适用场景：新建命名空间时，作为首要安全策略，强制实施最小权限原则。

• 场景二：仅允许同命名空间内流量

一个常见的场景是，默认拒绝所有流量，但允许同一命名空间内的 Pod 之间自由通信。这为命名空间提供了一个基础的隔离边界。

 apiVersion: networking.k8s.io/v1
 kind: NetworkPolicy
 metadata:
   name: allow-same-namespace
   namespace: my-app
 spec:
   podSelector: {}
   policyTypes:
   - Ingress
   ingress:
   - from:
     - podSelector: {}

应用效果：my-app 命名空间内的 Pod 可以相互通信，但无法与外部及其他命名空间的 Pod 通信。
适用场景：将强关联服务部署在同一命名空间，并限制其与外部的非必要通信，实现命名空间级别的微隔离。

• 场景三：隔离前端和后端通信

这是微隔离的经典案例。此策略应用于后端 Pod，只允许带有 app: frontend 标签的 Pod 访问其 8080 端口。

 apiVersion: networking.k8s.io/v1
 kind: NetworkPolicy
 metadata:
   name: allow-frontend-to-backend
   namespace: default
 spec:
   podSelector:
     matchLabels:
       app: backend
   policyTypes:
   - Ingress
   ingress:
   - from:
     - podSelector:
         matchLabels:
           app: frontend
     ports:
     - protocol: TCP
       port: 8080

应用效果：只有标签为 app: frontend 的 Pod 能够连接到标签为 app: backend 的 Pod 的 8080 端口；其他 Pod 均无法访问。
适用场景：典型的三层架构应用，确保只有前端服务能访问后端 API。

• 场景四：限制出站到外部数据库

此策略控制出站流量，只允许带有 app: myapp 标签的 Pod 连接到指定的外部数据库 IP 地址的 5432 端口。这可以防止应用连接到未经授权的外部服务。

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: app-to-db-egress
    namespace: default
  spec:
    podSelector:
      matchLabels:
        app: myapp
    policyTypes:
    - Egress
    egress:
    - to:
      - ipBlock:
          cidr: 203.0.113.10/32
      ports:
      - protocol: TCP
        port: 5432

应用效果：标签为 app: myapp 的 Pod 只能向 203.0.113.10 的 5432 端口发起连接，其他所有出站流量均被阻止。
适用场景：限制应用程序只能访问经过批准的特定外部服务（如数据库、消息队列、第三方 API）。

四、 最佳实践：确保网络策略的有效性和可维护性

在实施 Kubernetes 网络策略时，遵循以下最佳实践至关重要：

默认拒绝，显式允许：这是最核心的安全原则。首先为命名空间设置“全部拒绝”的策略，然后根据需要逐一添加“允许”规则，实现最小权限原则。
应用参考：在新创建的命名空间中，优先部署一个 default-deny-all 策略，然后再逐步添加允许的通信规则。
精心设计标签：标签是网络策略的基石。使用清晰、一致且具有描述性的标签体系，可以让您的策略更易于理解、管理和扩展。
应用参考：为您的所有 Pod、Namespace 规划统一的标签命名规范，例如 app: <service-name>, tier: <frontend/backend/db>, env: <dev/prod>。
定期审查与测试：应用程序和环境总在变化。定期回顾和测试您的网络策略，确保它们仍然有效且符合预期，防止出现安全漏洞。
应用参考：将网络策略纳入 CI/CD 流程，利用工具（如 kube-mgmt, network-policy-analytics）进行自动化验证和测试。
理解您的 CNI：不同的 CNI 插件可能提供超出原生规范的额外功能（如 Calico 的显式 Deny 规则）。了解您所用 CNI 的特性，以充分发挥其安全潜力。
应用参考：查阅您所使用 CNI（如 Calico, Cilium, Flannel 等）的官方文档，了解其对 NetworkPolicy 的具体实现细节和扩展功能，例如 Calico 的 GlobalNetworkPolicy 或 Cilium 的 CiliumNetworkPolicy。

五、 高级主题与工具：迈向更强大的网络安全

虽然原生网络策略功能强大，但像 Calico 这样的 CNI 插件提供了更丰富的功能，可以满足更复杂的安全需求。

在大型集群中，手动管理网络策略会变得非常复杂。生态系统中涌现了许多工具来简化这一过程，例如 Calico Enterprise, Cilium Hubble 等。它们提供集中式管理、策略推荐、流量可视化等高级功能，帮助您更好地理解和保护集群网络。