网络策略与零信任

危险的默认: 集群是一个"不设防的内网"

先认清这个让很多人后背发凉的事实:

默认情况下, K8s 集群里:
  前端 Pod   ←→  订单 Pod   ←→  数据库 Pod   ←→  支付 Pod
     └────────────全部可以互相直连, 任意端口────────────┘

现在, 前端 Pod 因为一个漏洞被攻破了:
  攻击者拿下前端 Pod → 直接连数据库 Pod 的 5432 端口(扁平网络, 通!)
                    → 直接连支付 Pod 的内部接口(通!)
                    → 横向移动(Lateral Movement), 逐个沦陷

问题: 前端 Pod 本来只需要访问订单服务, 凭什么能直连数据库?
      默认全通让一个小漏洞, 变成了整个集群的失守.

这就是东西向(East-West)流量失控的危险. 传统安全把重心放在南北向(外部进入集群的边界, 如防火墙, Ingress), 却往往忽略了集群内部服务之间的流量. 而现代攻击的核心手法正是横向移动--突破一个点后在内网里横着扩散.

先分清两个方向: 南北向 vs 东西向

名字来源: 画集群架构图时, 外部流量通常从上往下进来(南北纵向), 服务间流量在同一层横向流动(东西横向). NetworkPolicy 专治东西向--给集群内部服务之间的流量上锁.

NetworkPolicy: 用标签声明"谁能访问谁"

NetworkPolicy 是 K8s 的标准资源, 用声明式方式描述"哪些 Pod 可以接收/发出哪些流量". 它的核心机制和 Service 一样--靠标签选择器(label selector)选中目标 Pod, 而非靠易变的 IP(呼应第 04 篇"身份比地址可靠").

看一个例子: 只允许带 app=order 标签的 Pod 访问数据库的 5432 端口, 其他一概拒绝:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-allow-order-only
spec:
  podSelector:                  # ← 这条策略保护谁: 带 app=db 的 Pod
    matchLabels:
      app: db
  policyTypes:
    - Ingress                   # ← 管入站流量
  ingress:
    - from:
        - podSelector:          # ← 只允许谁进来: 带 app=order 的 Pod
            matchLabels:
              app: order
      ports:
        - protocol: TCP
          port: 5432            # ← 只允许访问 5432 端口
# 效果: 除了 order Pod 访问 db 的 5432, 其他到 db 的入站流量全部被拒

最佳实践: 先建一道"默认拒绝"的墙

零信任的标准姿势是先全部拒绝, 再按需放行. 先给命名空间下一条"默认拒绝所有入站"的兜底策略:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
spec:
  podSelector: {}               # 空选择器 = 选中本命名空间所有 Pod
  policyTypes:
    - Ingress
  # 没有写任何 ingress 放行规则 = 拒绝所有入站
# 效果: 本命名空间所有 Pod 的入站流量默认全拒, 再用别的策略逐个开口子

有了这道墙, 再为每个服务补上"谁确实需要访问我"的放行策略. 这就把集群从"默认全通的内网"改造成了"默认隔离, 显式授权"的零信任网络.

L3/4 策略的天花板, 与 L7 的进阶

标准 NetworkPolicy 工作在 L3/L4: 它能管到"哪个 Pod, 哪个 IP 段, 哪个端口", 但管不到应用层的内容. 比如它能放行"访问订单服务的 8080 端口", 却无法表达"只允许调 GET /api/orders, 禁止 DELETE /api/orders".

要做到应用层(L7)的精细管控, 就需要第 04 篇的 Cilium(eBPF 能理解包内容)或服务网格(如 Istio)提供的增强策略: