networkpolicy 是 kubernetes 跨命名空间零信任隔离的核心手段，需依赖支持策略的 cni（如 calico、cilium），通过标签化 namespaceselector 和 podselector 实现“默认拒绝、按需放行”的最小权限控制。
在 Kubernetes 中，NetworkPolicy 是实现跨命名空间零信任隔离的核心手段。它不依赖应用层逻辑，而是通过声明式规则，在数据平面（由支持策略的 CNI 插件执行）强制实施“默认拒绝、按需放行”的最小权限通信模型。
关键前提：CNI 必须支持策略
NetworkPolicy 本身只是配置，不会自动生效。必须使用兼容的 CNI 插件，例如：
- Calico（基于 iptables 或 eBPF）
- Cilium（基于 eBPF，支持 L3/L4/L7 策略）
- Antrea（基于 Open vSwitch）
- Weave Net（较老版本需确认策略支持）
Flannel、Kube-router（默认模式）等不支持 NetworkPolicy —— 即使创建成功，也无实际拦截效果。
核心配置逻辑：用标签精准控制流向
跨命名空间隔离的关键在于正确组合 namespaceSelector 和 podSelector，而非硬编码 IP。所有规则均基于标签匹配，确保可移植、可复用、可 GitOps 管理。
Kubernetes Security Posture Scorecard
下载
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
-
允许同命名空间通信：用
podSelector: {}匹配本命名空间全部 Pod，作为 ingress 的唯一来源 -
禁止跨命名空间访问：不写任何
from条目，或显式排除其他命名空间（如用namespaceSelector配合否定标签） -
有选择地开放跨命名空间流量：例如只允许
app=frontend（在web命名空间）访问app=api（在backend命名空间），需同时指定namespaceSelector和podSelector
典型策略示例：生产环境推荐模式
以下策略部署在 production 命名空间中，实现“默认拒绝 + 显式白名单”：
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: prod-isolation
namespace: production
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress
ingress:
- from:
- namespaceSelector:
matchLabels:
network-policy: allowed # 仅允许带此标签的命名空间
podSelector:
matchLabels:
app: frontend # 且 Pod 必须有此标签
ports:
- protocol: TCP
port: 8080
egress:
- to:
- namespaceSelector:
matchLabels:
network-policy: external-dns
ports:
- protocol: UDP
port: 53
配套操作：
- 给允许调用的命名空间打标：
kubectl label ns web network-policy=allowed - 给目标服务 Pod 打标：
kubectl label pod -n web nginx-xxx app=frontend - 避免策略冲突：同一命名空间下多个 NetworkPolicy 会叠加生效（取并集），不是覆盖
验证与排错要点
策略部署后不能仅看 kubectl get netpol 就认为已生效。必须实测：
- 从其他命名空间的 Pod 发起
curl或nc测试目标服务端口 - 检查目标 Pod 日志是否收到连接请求（无日志 = 策略在 CNI 层已拦截）
- 使用
calicoctl get networkpolicy -n production（Calico）或cilium network-policy list（Cilium）确认策略已同步至数据平面 - 注意 DNS 流量：若未放行
egress到 kube-dns/coredns，Pod 可能无法解析服务名
