networkpolicy 是 kubernetes 实现 pod 级网络微隔离的核心机制，依赖支持该功能的 cni 插件（如 calico、cilium）生效，需通过 podselector 显式匹配 pod，遵循“默认允许、最小权限”原则配置 ingress/egress 规则。
默认情况下，Kubernetes 集群中所有 Pod 之间是完全互通的——这看似便利，实则埋下严重安全风险。一旦某个 Pod 被攻陷，攻击者可横向移动访问任意其他 Pod。NetworkPolicy 是 Kubernetes 原生提供的、实现 Pod 级网络微隔离的核心机制，它不依赖应用层改造，直接在数据平面（L3/L4）生效。
NetworkPolicy 生效的前提条件
NetworkPolicy 本身只是声明式配置，真正执行隔离的是底层 CNI 插件。不是所有网络方案都支持它：
- Calico、Cilium、NSX-T、TKE 的 NetworkPolicy 扩展组件等均原生支持；
- Flannel、早期版本的 Weave 默认不支持，即使定义了 NetworkPolicy 也无效；
- 确认是否启用：运行
kubectl get crd networkpolicies.networking.k8s.io，并检查所用 CNI 文档是否明确标注 “NetworkPolicy support”； - 策略仅对被
podSelector显式匹配的 Pod 生效；未被任何策略选中的 Pod 不受限制，仍保持全通。
基础隔离模式：从“全通”到“默认拒绝”
安全加固的第一步是打破默认信任模型。推荐按渐进方式落地：
Kubernetes Security Posture Scorecard
下载
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
-
拒绝所有入站和出站流量（最严格起点）：
podSelector: {}匹配命名空间内全部 Pod，policyTypes: [Ingress, Egress]且不定义任何from或to规则，即默认拒绝所有通信； -
允许同命名空间互访（常见基线）：
Ingress 规则中使用podSelector: {}（空选择器），表示允许来自同一命名空间内任意 Pod 的流量； -
显式放行必要依赖（最小权限原则）：
例如后端 Pod 只允许被前端 Pod 访问，且仅开放 80/TCP 端口，其余全部拒绝。
精准控制通信关系的常用选择器
NetworkPolicy 通过标签组合精确划定通信边界，关键字段需配合使用：
-
Pod 选择器（
podSelector）：指定本策略作用于哪些 Pod，如matchLabels: {app: api}； -
来源控制（
ingress.from）：
–podSelector：同命名空间内带指定标签的 Pod；
–namespaceSelector：跨命名空间，如matchLabels: {tenant: finance}；
–ipBlock：限定 CIDR 段，常用于放行外部监控或日志服务 IP； -
目标控制（
egress.to）：结构与from类似，用于约束 Pod 可访问的外部地址或服务； - 多个规则会叠加生效，不存在覆盖或优先级，而是取并集——只要任一策略允许，流量即通过。
典型生产配置示例
以下 YAML 实现一个常见分层隔离场景：某业务命名空间中，仅允许前端 Pod 访问后端 Pod 的 3000/TCP 端口，后端 Pod 可访问外部 Redis（10.96.10.5:6379），其余一切禁止：
- 前端 → 后端（Ingress）：
podSelector: {app: backend}ingress:
- from:
- podSelector: {app: frontend}
ports:
- protocol: TCP
- port: 3000 - 后端 → 外部 Redis（Egress）：
egress:
- to:
- ipBlock: {cidr: "10.96.10.5/32"}
ports:
- protocol: TCP
- port: 6379
