WEBKT

Kubernetes 网络策略：从原理到实践，保障集群安全

50 0 0 0

在微服务架构日益普及的今天，Kubernetes (K8s) 已成为容器编排的事实标准。然而，随着应用部署密度的增加，如何确保不同服务间、甚至同一服务内部不同组件间的网络安全隔离，成为了一个核心挑战。Kubernetes 网络策略 (Network Policies) 正是应对这一挑战的关键工具，它允许我们定义 Pod 之间以及 Pod 与外部网络之间的通信规则。

1. Kubernetes 网络策略的核心原理

Kubernetes 网络策略并非由 Kubernetes 自身直接实现，而是由底层的网络插件（Container Network Interface, CNI）负责。当你在 Kubernetes 中定义一个 Network Policy 对象时，kube-apiserver 会将这个定义存储起来，并通知 CNI 插件。支持 Network Policy 的 CNI 插件（如 Calico, Cilium, Weave Net, Canal 等）会监听这些策略，并将其转换为宿主机上的实际网络规则，例如 iptables 规则或 eBPF 程序，以强制执行这些策略。

Network Policy 的基本逻辑是“默认拒绝，显式允许”。这意味着在一个启用了 Network Policy 的命名空间中，如果某个 Pod 没有被任何 Network Policy 选中，那么它默认将允许所有入站和出站流量。但一旦有任何 Network Policy 选中了它，那么只有该策略明确允许的流量才能通过，其余流量都将被拒绝。

一个 Network Policy 主要由以下几个部分组成：

  • podSelector: 选择器，定义哪些 Pod 会应用此策略。
  • policyTypes: 定义策略类型，可以是 Ingress（入站）、Egress（出站）或两者皆有。
  • ingress: 入站规则列表，定义允许哪些 Pod 或外部实体向被选中 Pod 发送流量。
  • egress: 出站规则列表，定义被选中 Pod 允许向哪些 Pod 或外部实体发送流量。

2. 如何使用网络策略实现 Pod 隔离与流量限制

我们将通过几个实用场景来演示如何配置 Network Policy。

2.1 隔离不同命名空间中的 Pod

假设我们有两个命名空间：dev 和 prod。我们希望 dev 命名空间中的 Pod 无法访问 prod 命名空间中的 Pod。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-dev-to-prod
  namespace: prod # 注意：策略定义在被保护的命名空间
spec:
  podSelector: {} # 选中 `prod` 命名空间中的所有 Pod
  policyTypes:
  - Ingress # 定义入站策略
  ingress:
  - from:
    - namespaceSelector: {} # 允许来自所有命名空间的流量（默认行为）
      # 这条规则将覆盖默认拒绝，允许所有 Pod 访问
      # 为了实现隔离，我们需要更具体的规则
    # 实际上，如果想阻止 `dev` 访问 `prod`，而允许其他合规的访问，
    # 做法通常是先默认拒绝所有，再显式允许合规的。
    # 更直接的方法是确保 `prod` 命名空间下的 Pod 只有明确允许的来源才能访问。

# 假设 `prod` 命名空间中的 Pod 标签为 `app: backend`
# 这个策略将拒绝来自 `dev` 命名空间中所有 Pod 对 `prod` 命名空间中 `app: backend` Pod 的访问
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-ingress-from-dev-to-prod-backend
  namespace: prod
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: prod # 允许来自 'prod' 命名空间内部的 Pod 访问
    # 没有明确指定其他命名空间的 `from` 规则，意味着其他命名空间（包括 `dev`）默认被拒绝。
    # 此外，你还可以添加 `ipBlock` 来允许特定 IP 范围。

解释: 上述策略部署在 prod 命名空间，并选中了所有 app: backend 的 Pod。ingress 规则中只允许来自 prod 命名空间内部的流量。这样，dev 命名空间中的任何 Pod 都无法访问 prod 命名空间中 app: backend 的 Pod。

2.2 限制 Pod 之间的特定端口通信

假设我们的 backend Pod（端口 8080）只能被 frontend Pod 访问，并且 backend Pod 只能访问数据库 Pod（端口 5432）。

a) 允许 frontend 访问 backend 的 8080 端口 (Ingress)

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

解释: 此策略选中了 app: backend 的 Pod。它允许来自 app: frontend 的 Pod 通过 TCP 协议访问 backend Pod 的 8080 端口。其他 Pod 或端口的入站流量都将被拒绝。

b) 允许 backend 访问 database 的 5432 端口 (Egress)

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-backend-to-database-5432
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Egress
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: database
    ports:
    - protocol: TCP
      port: 5432
  # 同时允许 DNS 解析 (通常是 53 端口 UDP/TCP)
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0 # 允许所有 IP，但仅限 53 端口
    ports:
    - protocol: UDP
      port: 53
    - protocol: TCP
      port: 53

解释: 此策略选中了 app: backend 的 Pod。它允许 backend Pod 向 app: database 的 Pod 发送 TCP 流量到 5432 端口。同时，为了确保服务发现正常工作，通常需要允许出站 DNS (53 端口 UDP/TCP) 流量。除了这些，backend Pod 无法向其他 Pod 或外部地址发送流量。

3. 提升集群的安全性

网络策略通过限制 Pod 间的“东西向”流量，极大地提升了 Kubernetes 集群的安全性：

  • 最小权限原则：强制 Pod 只能与它需要通信的服务进行通信，减少了攻击面。
  • 横向移动防护：即使攻击者攻陷了一个 Pod，也难以在集群内部进行横向移动，因为它无法随意访问其他 Pod。
  • 环境隔离：轻松隔离开发、测试、生产环境的流量，防止意外或恶意的跨环境访问。
  • 合规性：帮助企业满足 PCI DSS、GDPR 等合规性要求中关于网络隔离的规定。

4. 适用场景和局限性

4.1 适用场景

  • 微服务安全：为每个微服务定义精确的通信规则，确保服务间隔离。
  • 多租户集群：在共享集群中，为不同租户或团队的命名空间提供网络隔离，防止相互影响。
  • 敏感数据隔离：将包含敏感数据的服务（如数据库）与其他服务严格隔离。
  • 审计和监控：配合 CNI 插件的日志功能，可用于审计网络连接，发现异常行为。

4.2 局限性

  • 依赖 CNI 插件：Network Policy 的功能完全依赖于底层 CNI 插件的支持。如果 CNI 插件不支持或配置不当，策略将不会生效。
  • 命名空间范围：Network Policy 是命名空间作用域的资源，无法直接定义跨命名空间、但只针对某个特定 Pod 的策略。尽管可以通过 namespaceSelector 和 podSelector 的组合实现，但逻辑会变得复杂。
  • 仅支持 IP/端口/Pod/Namespace 级别：Network Policy 只能基于 Pod 标签、命名空间标签、IP 地址和端口号进行规则匹配。它无法识别更高层的应用协议（如 HTTP 方法、URL 路径），也无法提供更高级的流量管理功能（如带宽限制、QoS）。对于这些需求，需要服务网格 (Service Mesh) 等更高级的解决方案。
  • 规则复杂性：随着集群规模和策略数量的增加，管理和调试 Network Policy 可能会变得复杂和困难。错误的策略可能导致服务中断。
  • 默认允许行为：如果没有任何 Network Policy 选中某个 Pod，所有流量默认是允许的。这可能导致意外的开放。为了更安全的默认行为，可以在命名空间层面定义一个“默认拒绝所有入站/出站”的策略。

总结

Kubernetes 网络策略是构建安全、健壮的微服务架构不可或缺的一环。通过深入理解其工作原理、灵活运用其配置方法，并意识到其适用场景和局限性，我们可以有效地增强 Kubernetes 集群的安全性，确保应用的稳定运行。在实际部署中，建议从小范围开始测试，并利用监控工具验证策略的实际效果，以避免不必要的生产事故。

K8s老兵 Kubernetes网络安全

评论点评