零信任网络的最后一道防线：K8s NetworkPolicy 深度解析与生产实践
零信任网络的最后一道防线：K8s NetworkPolicy 深度解析与生产实践
一、集群内的裸奔时代：为什么默认全通是定时炸弹
Kubernetes 集群的网络模型默认采用"全通"策略——同一集群内任意 Pod 可以与任意 Pod 通信，没有任何隔离。在开发阶段这种设计降低了上手门槛，但在生产环境中却是一个严重的安全隐患。
一次典型的安全事件链路如下：攻击者通过某个暴露了 NodePort 的测试服务获得 Pod 内部访问权限，由于网络全通，他们可以直接访问同一集群内的数据库 Pod、消息队列管理界面、甚至 Kubernetes API Server 的内部端点。横向移动的路径完全畅通，没有任何网络层面的阻断。
更隐蔽的风险在于"爆炸半径"的扩大。当某个微服务被攻破后，如果该服务可以访问集群内所有其他服务的 API，攻击者就能以该服务为跳板，逐个渗透整个微服务拓扑。NetworkPolicy 的核心价值，就是将爆炸半径限制在最小范围内。
二、NetworkPolicy 的执行机制：从 API 声明到 iptables 规则的完整链路
NetworkPolicy 本身只是 API Server 中的一个声明式对象，真正执行隔离的是 CNI 插件。以 Calico 为例，完整的数据流如下：
flowchart TD A[用户提交 NetworkPolicy YAML] --> B[API Server 校验并持久化] B --> C[Felix DaemonSet Watch 到策略变更] C --> D[Felix 将策略转换为 iptables/ipvs 规则] D --> E[注入到宿主机内核 netfilter] E --> F{数据包到达宿主机} F --> G[PREROUTING 链：标记 Pod 所属网络] G --> H[FORWARD 链：匹配 NetworkPolicy 规则] H --> I{规则匹配结果} I -->|Ingress 规则允许| J[ACCEPT：放行数据包] I -->|无匹配规则| K[DENY：默认拒绝] I -->|Egress 规则允许| J style A fill:#e1f5fe style K fill:#ffebee style J fill:#e8f5e9关键机制解析：
标签选择器的延迟绑定：NetworkPolicy 使用 Label Selector 匹配目标 Pod，这意味着策略是动态绑定的。当新 Pod 被创建并携带匹配的标签时，策略自动生效，无需手动更新。但这种动态性也带来了风险——标签误配可能导致策略意外地作用于错误的 Pod。
规则叠加逻辑：当多个 NetworkPolicy 选中同一个 Pod 时，策略之间是"并集"关系。即只要任一策略允许该流量，流量就会被放行。这意味着每新增一条策略，只会放宽而不会收紧已有的访问控制。在审计时需要关注所有选中同一 Pod 的策略集合。
Ingress 与 Egress 的独立性：Ingress 规则控制进入 Pod 的流量，Egress 规则控制从 Pod 发出的流量。两者完全独立，不会互相推导。一个只配置了 Ingress 策略的 Pod，其出站流量仍然全通（除非也有 Egress 策略限制）。
三、生产级 NetworkPolicy 实践：三层隔离模型
以下代码实现一个从粗到细的三层网络隔离模型，适用于多租户或多环境共享集群场景。
第一层：命名空间级默认拒绝
# default-deny-all.yaml # 每个业务命名空间必须部署此策略，建立零信任基线 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-all namespace: production spec: # 不指定 podSelector 即选中命名空间内所有 Pod podSelector: {} policyTypes: - Ingress - Egress # 不定义任何 ingress/egress 规则 = 拒绝所有流量第二层：服务间通信白名单
# service-mesh-allow.yaml # 仅允许经过验证的服务间通信 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-api-to-db namespace: production spec: podSelector: matchLabels: app: postgres-db tier: data policyTypes: - Ingress ingress: - from: # 来源1：同一命名空间内的 API 服务 - namespaceSelector: matchLabels: env: production podSelector: matchLabels: app: api-server ports: - port: 5432 protocol: TCP - from: # 来源2：监控命名空间的 Prometheus 采集器 - namespaceSelector: matchLabels: name: monitoring ports: - port: 9187 protocol: TCP第三层：Egress 精细化控制——防止数据外泄
# egress-control.yaml # 限制出站流量，防止被攻破的 Pod 横向渗透或外泄数据 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: restrict-egress namespace: production spec: podSelector: matchLabels: app: api-server policyTypes: - Egress egress: # 规则1：允许 DNS 解析（否则服务发现会全部失败） - to: - namespaceSelector: matchLabels: name: kube-system podSelector: matchLabels: k8s-app: kube-dns ports: - port: 53 protocol: UDP - port: 53 protocol: TCP # 规则2：允许访问同命名空间的数据库 - to: - podSelector: matchLabels: tier: data ports: - port: 5432 protocol: TCP # 规则3：允许访问外部 API 网关（通过 IP 段控制） - to: - ipBlock: cidr: 10.0.0.0/8 exceptions: # 排除集群内部不应访问的网段 - 10.96.0.0/12 ports: - port: 443 protocol: TCP策略验证脚本：部署后必须验证策略是否按预期生效
#!/bin/bash # verify-network-policy.sh # 自动化验证 NetworkPolicy 隔离效果 set -euo pipefail NAMESPACE="production" PASS=0 FAIL=0 # 测试1：验证默认拒绝策略生效 echo "=== 测试1：跨命名空间访问应被拒绝 ===" RESULT=$(kubectl exec -n ${NAMESPACE} api-server-xxx -- \ curl -s -o /dev/null -w "%{http_code}" \ --connect-timeout 3 \ http://postgres-db.production.svc.cluster.local:5432 2>/dev/null || echo "000") if [[ "$RESULT" == "000" ]]; then echo "PASS: 跨命名空间访问被拒绝" ((PASS++)) else echo "FAIL: 跨命名空间访问未被拒绝 (HTTP $RESULT)" ((FAIL++)) fi # 测试2：验证白名单通信正常 echo "=== 测试2：同命名空间 API->DB 通信应正常 ===" RESULT=$(kubectl exec -n ${NAMESPACE} api-server-xxx -- \ curl -s -o /dev/null -w "%{http_code}" \ --connect-timeout 5 \ http://postgres-db:5432 2>/dev/null || echo "000") if [[ "$RESULT" != "000" ]]; then echo "PASS: 白名单通信正常 (HTTP $RESULT)" ((PASS++)) else echo "FAIL: 白名单通信异常" ((FAIL++)) fi # 测试3：验证 Egress 限制生效 echo "=== 测试3：访问外部非白名单地址应被拒绝 ===" RESULT=$(kubectl exec -n ${NAMESPACE} api-server-xxx -- \ curl -s -o /dev/null -w "%{http_code}" \ --connect-timeout 3 \ http://169.254.169.254 2>/dev/null || echo "000") if [[ "$RESULT" == "000" ]]; then echo "PASS: 非白名单 Egress 被拒绝" ((PASS++)) else echo "FAIL: Egress 限制未生效 (HTTP $RESULT)" ((FAIL++)) fi echo "" echo "=== 验证结果：${PASS} PASS / ${FAIL} FAIL ===" exit ${FAIL}四、NetworkPolicy 的能力边界与架构妥协
CNI 插件兼容性：NetworkPolicy 的实际执行效果完全依赖 CNI 插件的实现质量。Flannel 的社区版不支持 NetworkPolicy；Calico 和 Cilium 支持最完整；AWS VPC CNI 对 Egress ipBlock 的支持存在已知缺陷。在选型阶段必须确认 CNI 对 NetworkPolicy 的支持矩阵。
L3/L4 层限制：NetworkPolicy 只能基于 IP、端口和协议进行过滤，无法识别应用层协议。例如，无法编写"只允许 GET 请求访问 /api/v1/health"这样的策略。如果需要 L7 层的访问控制，必须引入 Service Mesh（如 Istio AuthorizationPolicy）或 API Gateway。
策略爆炸问题：在微服务数量超过 50 个的集群中，NetworkPolicy 的数量可能膨胀到数百条。策略之间的交互关系变得难以追踪，审计成本急剧上升。建议采用"命名空间级默认拒绝 + 服务级白名单"的两层模型，避免为每个 Pod 对单独编写策略。
性能开销：每条 NetworkPolicy 最终会转化为 iptables 规则。当规则数量超过 1000 条时，iptables 的线性匹配机制会导致数据包处理延迟上升。Cilium 基于 eBPF 的实现可以绕过 iptables，在大规模集群中性能优势明显。
五、总结
K8s NetworkPolicy 是实现集群内零信任网络的基础设施，其核心价值在于将爆炸半径从"整个集群"缩小到"被策略允许的通信路径"。三层隔离模型——命名空间级默认拒绝、服务间白名单、Egress 精细化控制——为生产环境提供了从粗到细的防御纵深。
落地路线建议：第一步，在所有业务命名空间部署 default-deny-all 策略，建立零信任基线；第二步，逐步添加服务间通信白名单，确保业务流量正常；第三步，引入 Egress 控制，封堵数据外泄通道；第四步，编写自动化验证脚本，将策略测试纳入 CI 流水线，防止策略回归。对于 L7 层访问控制需求，在 NetworkPolicy 之上叠加 Service Mesh 的 AuthorizationPolicy，形成 L3-L7 的完整防御体系。