从全通到最小化：NetworkPolicy 改造上线记

安全扫描报告里有一条：集群内网全通，任何 Pod 可以访问任何 Pod。虽然都在内网，横向移动的风险还是被审计部门点了名。于是花了两周做 NetworkPolicy 改造。

现状是 40 多个 namespace、300 多个服务，直接写策略必然把业务打断。方案是灰度推进：先观察后执行。

第一步，用 Calico 的策略审计模式（staged policy）跑了两周，把真实发生的连接关系全部记录下来。第二步按调用关系生成基线策略，人工确认明显不对劲的条目。第三步分批 apply，每批观察 24 小时。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: team-order
spec:
  podSelector: {}          # 作用于命名空间内所有 Pod
  policyTypes: [Ingress]

每个 namespace 先放这条默认拒绝，再叠加白名单。白名单按标签选择而不是 IP：

  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              team: gateway
      ports:
        - protocol: TCP
          port: 8080

上线过程只出过一次事故：一个服务依赖的 Redis 在共享 namespace，标签没匹配上，断了半小时才被发现。这暴露了依赖登记不全的问题，顺手把服务间调用关系接进了 CMDB。

改造完成后做了一次模拟攻击演练，从一台被攻陷的 Pod 横向扫描，命中策略全部被拒。审计报告顺利关闭，更实际的收益是排障时调用关系有据可查，算意外之喜。

灰度期的观察指标也要提前定好：策略命中次数、被拒绝的连接数、误伤候选列表，每天自动生成报告发到群里。有一次报告显示某策略命中为零，调查发现是标签拼写错误，策略形同虚设，这类静默失效比误伤更危险。

改造后有个意外的组织收益：调用关系白名单成了架构治理的输入，谁的依赖最乱一目了然，服务下线评估也有了依据，季度架构会上用这张图砍掉了七个僵尸依赖。另外提醒想动手的团队：NetworkPolicy 的语义依赖 CNI 实现，我们早期用的一款网络插件对策略支持不完整，换 Calico 后规则行为才和文档一致。动手前先在预发验证策略的实际生效行为，别默认它一定起作用，这是这个项目里最值得提前知道的一条。