Kubernetes集群中网络策略对微服务间流量的防护

Kubernetes集群默认的“全通”网络模型是微服务安全中最容易被忽视的致命伤。在一个刚搭建好的集群里，任何Pod都能直接访问其他Pod，无论它们属于哪个命名空间、承载着什么敏感数据。这意味着一旦某个前端服务被攻破，攻击者可以毫无阻碍地横向移动到后端的支付系统、用户数据库或密钥管理服务。解决这个问题的核心手段不是防火墙，不是服务网格，而是Kubernetes原生的NetworkPolicy资源。它直接作用于Pod的网络层，通过定义准入规则，将微服务间的流量从“默认允许”扭转为“默认拒绝”，再按需放行合法的通信路径。

NetworkPolicy本身只是一个逻辑声明，它不负责实际的数据包过滤。真正执行策略的是集群中部署的CNI网络插件，例如Calico、Cilium或Weave Net。当你在集群中创建一个NetworkPolicy对象时，API Server将其持久化存储，随后CNI插件通过Watch机制感知到变更，并将策略翻译成底层的数据平面规则。以Calico为例，它使用iptables或eBPF技术在Linux内核层面挂载过滤链；Cilium则直接利用eBPF程序在数据路径上做高速包检查。这意味着策略的生效是毫秒级的，且过滤性能极高，几乎不产生额外的网络延迟。但这也引出一个关键前提：你的CNI插件必须支持NetworkPolicy，否则你创建的策略只是一纸空文。Flannel默认就不具备此能力，这是很多集群在安全加固时踩的第一个坑。

有效的网络策略不是零散规则的堆砌，而应该遵循分层防御的思路。第一层是全局默认拒绝。在每个需要隔离的命名空间中，先创建一条拒绝所有入站流量的策略，再创建一条拒绝所有出站流量的策略。这步操作一旦执行，命名空间内的所有Pod瞬间变成孤岛，任何跨Pod通信都会被阻断。第二层是基础设施放行。你需要立刻允许Pod访问DNS服务，通常是在kube-system命名空间中的CoreDNS Pod，否则服务发现会完全瘫痪。同时还要考虑是否允许Pod访问外部互联网、是否允许kubelet对Pod的健康检查探活。第三层才是应用级策略，根据微服务间的实际调用关系，逐条定义允许规则。这种由严到松、逐级开放的方式，能最大程度避免遗漏。

NetworkPolicy通过标签选择器来锁定目标Pod和流量来源，因此标签体系的设计直接决定了策略的精准度和可维护性。避免使用过于宽泛的标签如app=backend来同时覆盖几十种服务，这样你不得不在策略中放行大量无关流量。推荐的做法是采用复合标签，例如app=payment和tier=critical的组合，让策略能够精确锚定高价值目标。对于来源端，除了使用Pod标签，还可以结合namespaceSelector来限定特定命名空间，甚至同时使用podSelector和namespaceSelector实现跨命名空间的精确授权。一个常见的错误是忘记给Pod打上恰当的标签，导致策略无法匹配，而排查时又因为网络静默丢弃而难以定位。

很多人只关注入站规则，认为只要限制谁能访问自己就足够了。这在防御外部攻击时确实有效，但完全忽略了失陷主机向外发起连接的风险。假设一个Pod被植入了反弹Shell，如果出站规则未做限制，攻击者可以轻松连接到外部命令控制服务器，或者扫描内网探测其他服务。正确的做法是同时收紧出站流量，只允许Pod向它职责范围内需要调用的下游服务发起连接。比如前端Pod的出站规则中，只应包含后端API服务的标签选择器和端口，其他所有出站请求全部丢弃。这种双向锁定虽然配置工作量翻倍，但能有效阻断数据外泄和横向移动两条关键攻击路径。

NetworkPolicy中对端口的定义可以精确到具体端口号或端口范围，也可以指定TCP或UDP协议。对于HTTP/2或gRPC这类基于长连接和头部复用的协议，仅靠四层端口控制是不够的，因为攻击者可以在已放行的端口上传输恶意载荷。此时需要CNI插件提供更上层的能力，例如Cilium支持基于HTTP路径、方法和Header的七层策略，可以直接在NetworkPolicy中通过扩展CRD来定义。但如果你的CNI只支持标准四层策略，那就必须在应用层额外部署认证和授权机制，比如服务间mTLS或API网关校验，不能把安全责任全部压在网络层。

在多租户环境中，命名空间是天然的隔离边界。你可以创建一条策略，拒绝所有来自其他命名空间的流量，只允许同命名空间内的服务互相通信。更进一步，可以为每个命名空间定义专属的入站白名单，明确列出哪些外部命名空间的身份被允许访问。这种做法的好处是，当新服务上线时，它默认无法与任何现有服务通信，必须经过显式的策略审批，安全团队可以借此实现网络层面的变更管控。需要注意的是，namespaceSelector匹配的是命名空间的标签，因此你需要提前为命名空间规划好标签体系，例如environment=production或team=payment。

网络策略的故障排查是运维中最头疼的环节，因为数据包被静默丢弃，不会产生任何日志或ICMP错误。首先需要确认CNI插件是否正常运行，节点上的代理组件是否处于健康状态。其次，使用kubectl describe networkpolicy命令检查策略是否正确匹配到了目标Pod，关注PodSelector和NamespaceSelector的实际匹配结果。如果策略逻辑无误但流量依然不通，可以在Pod内使用nc或curl工具向目标发起连接测试，同时在CNI插件侧开启调试日志。Calico提供了calicoctl命令行工具，可以实时查看数据平面的iptables规则或eBPF程序状态；Cilium则有cilium monitor命令，能够捕获到每条被丢弃的数据包及其原因。养成在变更策略前先做模拟测试的习惯，能大幅减少生产事故。

当集群规模增长到上百个微服务时，手工编写NetworkPolicy变得不切实际。此时需要引入策略治理工具，例如通过OPA Gatekeeper或Kyverno在准入控制层强制要求每个命名空间必须存在基线网络策略，否则拒绝部署。同时可以结合服务网格或可观测性工具，自动发现微服务间的实际调用关系，反向生成最小权限的网络策略。Cilium的Hubble组件就能可视化流量拓扑，并一键导出为NetworkPolicy YAML。将这些能力集成到CI/CD流水线中，让网络策略随着服务代码一同交付和版本管理，才能真正实现安全左移。

下面是一套生产环境中常用的策略组合。首先创建默认拒绝所有入站流量的策略：

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

接着创建默认拒绝所有出站流量的策略：

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

然后放行DNS查询，允许Pod向kube-system命名空间中带有k8s-app=kube-dns标签的Pod发起UDP 53端口请求：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
      podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - protocol: UDP
      port: 53

最后定义应用级策略，允许前端Pod访问后端API服务的8080端口：

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

这套组合拳部署后，production命名空间内的Pod只能接收来自frontend标签Pod对backend API的TCP 8080请求，只能主动发起DNS查询，其余所有流量双向阻断。安全基线瞬间从零提升到可控状态。

第一个误区是认为NetworkPolicy可以替代应用层安全。它工作在OSI模型的第三层和第四层，对应用协议内容完全无感知。如果你的服务存在SQL注入或反序列化漏洞，网络策略无法提供任何保护。第二个误区是策略堆积后不清理，导致规则膨胀，影响数据平面性能。定期审计并合并冗余规则是必要的运维动作。第三个误区是忽略了hostNetwork模式Pod和NodePort服务，这些流量可能绕过Pod网络命名空间的策略控制，需要额外的节点级防火墙规则来覆盖。第四个误区是在策略中过度使用ipBlock来放行外部IP段，一旦IP地址变更，策略立即失效，维护成本极高，应优先考虑通过DNS或服务名来抽象外部依赖。

网络策略是Kubernetes安全体系中最基础也最容易被低估的一环。它不需要额外的服务网格层，不引入新的延迟，不改变应用代码，却能从根本上改变集群内东西向流量的安全态势。在零信任架构成为行业共识的今天，默认拒绝、显式授权的网络策略，是每个生产集群都应当具备的基线配置。把它做对、做细、做自动化，微服务间的流量防护才算真正落了地。