Kubernetes NetworkPolicy网络策略配置与多租户隔离实践

Kubernetes NetworkPolicy工作机制与流量控制原理

Kubernetes NetworkPolicy网络策略是集群内微服务流量隔离的基础设施级防护手段。默认情况下Pod之间网络完全互通，任何Pod均可访问其他Pod的全部端口，这种扁平网络在多租户场景下构成严重风险。NetworkPolicy通过标签选择器定义允许的入站和出站规则，将默认允许模型改为显式白名单模型，是实现Kubernetes多租户隔离和零信任网络架构的关键机制。

NetworkPolicy的资源模型包含四个核心字段：podSelector指定策略作用的目标Pod、policyTypes声明入站/出站方向、ingress规则定义允许的入站来源和端口、egress规则定义允许的出站目标和端口。未匹配任何NetworkPolicy的Pod保持默认全通行为，而一旦被某条Policy的podSelector选中，该Pod在该方向上的流量将变为默认拒绝、仅允许规则中明确声明的通信。

NetworkPolicy核心语法与规则详解

以下是一个典型的NetworkPolicy定义，实现”仅允许同一Namespace内带有特定标签的Pod访问目标Pod的8080端口”：

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

ingress.from字段中的podSelector仅匹配同Namespace的Pod。若需跨Namespace访问，需叠加namespaceSelector。from字段中多个元素之间是逻辑OR关系，单个元素内部的多个选择器是逻辑AND关系。这个设计常被误解——当需要”来自tenant-a命名空间且标签为api-consumer的Pod”时，应将两个选择器写在同一个from元素内，而非写成两个独立元素。

多租户隔离设计模式：默认拒绝与白名单策略

多租户集群的网络隔离应遵循”默认拒绝、显式放行”原则。第一步是为每个租户Namespace创建默认拒绝策略：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: tenant-alpha
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

空podSelector匹配Namespace下所有Pod，空ingress/egress表示不允许任何流量。这是零信任网络的起点——所有流量必须在策略中显式声明。第二步是逐条添加白名单规则，放行必要的业务通信。常见需要放行的出站流量包括：DNS解析（UDP 53到kube-system下的CoreDNS）、外部数据库/缓存访问、镜像仓库拉取。

跨Namespace通信控制：对于需要跨租户协作的场景，通过namespaceSelector和podSelector的组合实现精确放行：

ingress:
  - from:
      - namespaceSelector:
          matchLabels:
            tenant: shared-services
        podSelector:
          matchLabels:
            role: metrics-collector
    ports:
      - protocol: TCP
        port: 9090

这种写法要求源Namespace已设置tenant=shared-services标签，目标Pod只接受来自满足两个条件的Pod访问。

CNI兼容性：Calico与Cilium的NetworkPolicy实现差异

NetworkPolicy的实际执行依赖CNI插件，不同CNI的实现存在关键差异。Calico使用iptables/eBPF实现NetworkPolicy，支持标准NetworkPolicy且扩展了GlobalNetworkPolicy（集群级策略）和Profile（节点级策略）。Calico的策略引擎对规则冲突采用”拒绝优先”策略——当多条规则同时匹配且存在冲突时，拒绝规则优先于允许规则。

Cilium基于eBPF实现，除了标准NetworkPolicy外，还支持CiliumNetworkPolicy（CNPC）和CiliumClusterwideNetworkPolicy。Cilium的扩展策略支持L7层规则（如HTTP路径过滤、gRPC方法限制），可在NetworkPolicy层面实现API级别的精细访问控制：

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: l7-rule
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: api-server
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      toPorts:
        - ports:
            - port: "8080"
          rules:
            http:
              - method: GET
                path: "/api/v1/health"

选择CNI时需注意：Flannel原生不支持NetworkPolicy，需搭配Calico策略引擎；某些CNI的NetworkPolicy不支持egress规则或ports字段为空时的语义不同——Calico中空ports表示允许所有端口，而某些实现在空ports时拒绝所有流量。

DNS陷阱与NetworkPolicy排错

应用NetworkPolicy后最常见的故障是DNS解析失败。默认拒绝egress策略会阻断Pod到CoreDNS的UDP 53端口，导致所有域名请求超时。必须在egress白名单中放行DNS：

egress:
  - to:
      - namespaceSelector:
          matchLabels:
            kubernetes.io/metadata.name: kube-system
        podSelector:
          matchLabels:
            k8s-app: kube-dns
    ports:
      - protocol: UDP
        port: 53
      - protocol: TCP
        port: 53

策略冲突排查：当Pod的流量被意外阻断时，按以下步骤排查：1）kubectl get networkpolicy -n <ns> 列出所有关联策略；2）检查Pod是否被多条Policy选中，策略叠加效果是OR逻辑（任一策略允许即放行）；3）使用Calico的calicoctl node status检查策略同步状态；4）Cilium环境下用cilium policy trace <src> <dst> 模拟规则匹配结果；5）查看节点iptables规则或eBPF map确认策略是否下发到数据面。

NetworkPolicy监控与零信任集成

生产环境中NetworkPolicy的合规性需要持续监控。Hubble（Cilium的可观测组件）可实时展示服务间流量拓扑，标记被策略拒绝的连接。Calico Enterprise提供策略审计日志，记录每条拒绝的连接详情。建议将策略审计日志接入Prometheus，按Namespace统计拒绝连接数和允许连接数，配置告警规则检测异常拒绝峰值。

零信任架构下，NetworkPolicy应与Service Mesh策略协同工作。NetworkPolicy负责L3/L4层的粗粒度隔离（Namespace边界控制），Service Mesh的AuthorizationPolicy负责L7层的细粒度访问控制（API路径、JWT声明校验）。两层策略不应重叠——避免在NetworkPolicy中做端口级微调的同时又在Mesh层重复限制，否则排错时难以定位拦截点。

自动化策略生成与合规审计

手动编写NetworkPolicy容易遗漏关键放行规则，生产集群的策略数量快速增长后维护成本极高。推荐采用”观察-生成-部署”工作流：先部署默认拒绝策略，在审计模式下运行（Cilium的audit模式或Calico的policy-recommendation），收集7-14天的实际流量数据，基于观测结果自动生成最小权限白名单策略。

# Cilium策略推荐模式：观察流量但不阻断
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: observe-mode
spec:
  endpointSelector:
    matchLabels:
      app: api-server
  ingress:
    - fromEndpoints:
        - matchLabels: {}
      # 未指定toPorts，审计模式记录但不确定是否允许

合规审计方面，可使用kube-bench或Poluto扫描集群NetworkPolicy覆盖率，检查是否存在没有默认拒绝策略的Namespace、是否有Pod未纳入任何NetworkPolicy管控。审计报告应包含：策略覆盖率（被策略选中的Pod比例）、暴露风险评分（无策略Pod可被任何来源访问的端口数）、策略冗余度（被多条策略重复覆盖的规则数）。定期审计结果纳入集群安全评分卡，驱动持续改进。