networkpolicy 仅能基于标签封禁流量，无法执行应用层清洗；真正的动态清洗需依赖ingress waf、服务网格、cni增强或云原生waf等组件，结合外部系统实现标签联动与策略闭环。
NetworkPolicy 本身不能做流量清洗，它只负责允许或拒绝连接，属于网络层的白名单访问控制。所谓“基于业务标签的动态流量清洗”，真正落地时需要拆解为两个层次：用标签识别目标（NetworkPolicy 擅长） + 用其他组件执行清洗（NetworkPolicy 不支持）。
NetworkPolicy 能做的：基于业务标签精准封禁
它的核心价值是快速响应异常行为——比如检测到某 Pod 打上 env=prod,app=payment,abnormal=true 标签，就立即切断其所有入站或出站通信。
-
podSelector必须明确匹配业务标签，例如：podSelector: matchLabels: env: prod app: payment - 封禁全部入口流量：
ingress: []（空列表 = 拒绝所有） - 封禁全部出口流量：
egress: [] - 若想只封特定端口，需显式列出
ports并配合from/to
注意：空选择器 podSelector: {} 会匹配整个命名空间下所有 Pod，容易误伤；未被任何 NetworkPolicy 选中的 Pod 默认仍完全开放。
真正实现“清洗”的组件要另配
清洗意味着识别恶意请求（如 SQL 注入、高频扫描、异常 User-Agent）、限速、重定向、返回拦截页等，这些能力 NetworkPolicy 全无。生产中常用方案有：
- Ingress 层 WAF：Nginx Ingress + ModSecurity 或 Kong Gateway 内置规则引擎，可基于 Host、Path、Header、Query 参数做深度检测
- 服务网格层：Istio + EnvoyFilter 配合外部 WAF 插件，对 mTLS 流量做应用层解析与干预
- CNI 增强层：Cilium 利用 eBPF 实现 L3/L4/L7 流量重定向与速率限制，支持基于 Pod 标签的细粒度策略
- 独立云原生 WAF：Solo Gloo Edge、Traefik Enterprise，提供策略编排界面和可观测性集成
这些组件才能读取 HTTP 头、解析 JSON Body、调用威胁情报库，并根据业务标签（如 team=finance）动态加载对应清洗规则。
“动态”靠的是标签生命周期联动，不是 NetworkPolicy 自身
NetworkPolicy 是静态配置资源，不感知运行时行为。所谓动态，实际依赖外部系统闭环：
- Falco 检测到高频 DNS 查询 → 触发 Kubeless 函数
- 函数给对应 Pod 打上
risk-level=high标签 - Operator 监听标签变更，自动生成/更新 NetworkPolicy 封禁该 Pod
- 同时调用 Istio API 注入 EnvoyFilter，启用定制化清洗规则
整个流程中，NetworkPolicy 只承担最后一步“断连”，前面所有感知、决策、响应动作都由其他系统完成。
不复杂但容易忽略。
