📚 课程目录第2章签名链路的核心挑战

NetPolicy 基础概念：Kubernetes NetworkPolicy 介绍、Ingress 与 Egress 规则、Pod 选择器与命名空间隔离

在多租户签名链路中，网络隔离是保障租户数据安全与链路稳定性的第一道防线。Kubernetes NetworkPolicy 作为原生的网络访问控制机制，通过声明式规则定义 Pod 之间的通信策略，是实现微隔离（Micro-Segmentation）的核心工具。本节将系统讲解 NetworkPolicy 的核心概念、规则模型与隔离边界。

1. NetworkPolicy 概述

NetworkPolicy 是 Kubernetes 集群中用于控制 Pod 网络流量的资源对象。它基于 白名单模型：默认情况下，Pod 允许所有入站（Ingress）和出站（Egress）流量；一旦应用了 NetworkPolicy，未显式允许的流量将被拒绝。

  关键原则： NetworkPolicy 是 有状态 的——允许的入站流量会自动允许对应的响应出站流量，反之亦然。但策略本身只控制 第 3/4 层（IP + 端口），不涉及应用层协议。

特性	说明
资源类型	networking.k8s.io/v1
作用范围	命名空间级别，仅对匹配的 Pod 生效
默认行为	未应用策略时，所有流量均被允许
策略模型	白名单：未显式允许即拒绝
依赖组件	需要 CNI 插件支持（Calico、Cilium、Antrea 等）

2. Ingress 与 Egress 规则

NetworkPolicy 的核心由 Ingress（入站）和 Egress（出站）两部分规则组成。每条规则可以指定允许的源/目标、端口和协议。

2.1 Ingress 规则

Ingress 规则控制哪些流量可以进入目标 Pod。规则中通过 from 字段定义允许的源，支持三种匹配方式：

ipBlock：基于 CIDR 地址段匹配（如集群外流量）
namespaceSelector：基于命名空间标签选择
podSelector：基于 Pod 标签选择

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

2.2 Egress 规则

Egress 规则控制目标 Pod 可以访问哪些外部地址。规则中通过 to 字段定义允许的目标，匹配方式与 Ingress 相同。

spec:
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: database
    ports:
    - protocol: TCP
      port: 5432

实践建议： 在多租户签名链路中，建议为每个租户的签名服务同时配置 Ingress 和 Egress 规则，形成 双向白名单，防止数据泄露到非授权端点。

3. Pod 选择器与命名空间隔离

Pod 选择器（podSelector）和命名空间选择器（namespaceSelector）是 NetworkPolicy 实现精细化隔离的两大核心机制。

3.1 Pod 选择器

通过标签选择器匹配目标 Pod。空选择器（podSelector: {}）表示匹配命名空间内的所有 Pod。

选择器类型	示例	匹配范围
精确匹配	`matchLabels: { app: signer }`	仅标签完全匹配的 Pod
表达式匹配	`matchExpressions: [{ key: tier, operator: In, values: [frontend, backend] }]`	满足表达式的 Pod 集合
全选	`podSelector: {}`	命名空间内所有 Pod

3.2 命名空间隔离

通过 namespaceSelector 实现跨命名空间的流量控制。结合 podSelector 可以精确到目标命名空间内的特定 Pod。

spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          tenant: alpha
      podSelector:
        matchLabels:
          app: signer

注意： namespaceSelector 与 podSelector 在同一规则中为 AND 关系，即同时满足两个条件才允许。若需要 OR 关系，需拆分为多条规则。

4. NetworkPolicy 隔离模型图解

下图展示了 NetworkPolicy 在命名空间内的隔离逻辑，以及 Ingress/Egress 规则的匹配流程：

5. 策略类型与隔离层级

NetworkPolicy 支持三种策略类型，组合使用可实现不同粒度的隔离：

策略类型	配置方式	隔离效果	典型场景
仅 Ingress	`policyTypes: [Ingress]`	仅控制入站流量，出站不受限	前端服务暴露给特定客户端
仅 Egress	`policyTypes: [Egress]`	仅控制出站流量，入站不受限	签名服务仅允许访问数据库
双向	`policyTypes: [Ingress, Egress]`	入站和出站均受控	多租户签名链路的严格隔离

  多租户隔离最佳实践： 为每个租户创建独立的命名空间，并通过 NetworkPolicy 实现以下隔离层级：

租户间隔离：禁止跨命名空间的非授权访问

服务间隔离：同一租户内，仅允许签名链路中的必要服务通信

外部访问控制：通过 ipBlock 限制集群外部的访问来源

6. 常见误区与避坑指南

误区一： 认为 NetworkPolicy 可以控制 Service 流量。实际上，策略作用于 Pod IP，Service 的 ClusterIP 仅做负载均衡，策略仍需匹配后端 Pod。
误区二： 忘记设置 policyTypes 字段。默认情况下，如果只配置了 ingress 字段，policyTypes 会自动包含 Ingress；但显式声明更安全。
误区三： 在同一个规则中混用 namespaceSelector 和 podSelector 时误以为 OR 关系。记住：同一规则内是 AND 关系，OR 关系需要拆分为多条规则。
误区四： 忽略 CNI 插件的兼容性。部分 CNI 不支持 ipBlock 或 namespaceSelector 的某些特性，生产环境需提前验证。