【安全实战】微服务一处被黑全网沦陷？基于 K8s NetworkPolicy 的零信任网络解法

在 K8s 集群中，默认的网络策略是“全开放”的（Default Allow All）。这意味着集群内的任意一个 Pod，都可以不受限制地向其他任意 Pod 发起网络请求。核心痛点： 假设你暴露在公网的一个“图片上传微服务”因组件漏洞被黑客拿下，取得了 Shell 权限。由于 K8s 内网互通，黑客可以直接从这个边缘 Pod 发起内网横向移动，轻易嗅探并连接你的核心 RDS 数据库、Redis 缓存或支付微服务。在扁平网络下，一旦防线被撕开一个口子，爆炸半径就是整个集群。

标准的云原生工程解法是：丢弃默认放行的网络拓扑，利用 NetworkPolicy 实施“默认拒绝，白名单放行”的细粒度流量管控。

1. 建立默认隔离网（Default Deny All）

在核心业务所在的 Namespace 中，首先下发一条全局拦截规则。这条规则会瞬间掐断该命名空间下所有 Pod 的入站（Ingress）流量，强迫开发者在后续明确声明每一条合法的调用链路：

# 1. 默认拒绝当前 Namespace 下的所有入站网络请求
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: core-business
spec:
  podSelector: {} # 空选择器代表匹配所有 Pod
  policyTypes:
  - Ingress

2. 声明精准的微服务白名单放行规则

实行全局隔离后，合法的内部调用也会被阻断。此时必须基于 Pod 的 Label 标签，开启点对点的“白名单放行”。 例如：只允许标签为 app: api-gateway 的网关 Pod，访问标签为 app: payment-service 的支付服务（且仅限 8080 端口）：

# 2. 仅放行合法的上下游微服务调用
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-gateway-to-payment
  namespace: core-business
spec:
  podSelector:
    matchLabels:
      app: payment-service # 保护的目标：支付服务
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: api-gateway # 放行的来源：API网关
    ports:
    - protocol: TCP
      port: 8080           # 仅允许访问 8080 业务端口

3. 网络策略在云上的底层支撑

需要注意的是，K8s 自身的 API Server 只负责存储这套 YAML 配置，真正执行网络拦截的是底层的网络插件（CNI）。在华为云 CCE 等托管集群中，通常需要确保使用的是支持网络策略的 CNI 插件（如 Calico 或 Cilium），这些配置会在底层被实时翻译为宿主机的 iptables 或 eBPF 规则。

总结： 云原生安全绝不能只靠最外层的云防火墙（WAF/安全组）。通过引入 NetworkPolicy，我们在不修改任何一行微服务代码的前提下，将防火墙的能力下放到了每一个容器网卡上。这种基于白名单的零信任隔离，是阻断内网黑客横向渗透的最强工程屏障。