实现微服务极细粒度安全访问控制需分层协同：Docker自定义网络提供单机容器隔离，Kubernetes NetworkPolicy基于标签实现集群级动态授权，CiliumNetworkPolicy补足FQDN、HTTP路径、TLS SNI等应用层精细策略。
要实现微服务之间极细粒度的安全访问控制，核心是分层协同：Docker 负责单机容器间的基础隔离与命名空间划分，Kubernetes 网络策略（NetworkPolicy）负责集群维度的标签级流量编排，而 Cilium 等增强型策略引擎则补足应用层（如 HTTP 路径、FQDN、TLS SNI）的深度控制能力。三者不是替代关系，而是递进叠加。
用 Docker 自定义网络划定通信边界
Docker 默认 bridge 网络不支持 DNS 解析、无连接控制、容器可任意互访——这在多服务共存时构成严重风险。必须禁用默认互通，改用显式创建的自定义桥接网络：
- 创建带子网和网关的隔离网络：
docker network create --subnet=10.200.1.0/24 --gateway=10.200.1.1 myapp-net - 启动容器时强制加入该网络，并可绑定固定 IP：
docker run -d --network=myapp-net --ip=10.200.1.10 --name auth-service nginx - 仅同一网络内的容器可通过服务名（如
auth-service）直接解析通信；跨网络容器默认无法 ping 通或建立 TCP 连接
用 Kubernetes NetworkPolicy 实现标签驱动的动态授权
Kubernetes 的原生 NetworkPolicy 是声明式、基于标签的最小权限控制机制。它不依赖 IP 地址（IP 会漂移），而是靠 Pod 和 Namespace 的 label 组合来定义“谁可以访问谁”：
- 默认拒绝所有入向流量：
podSelector: {}+policyTypes: [Ingress]，这是安全基线 - 允许特定组合访问数据库：例如只放行
app=payment, env=prod和app=reporting, team=analytics两类 Pod 访问 Redis，需在ingress.from下并列两个podSelector（OR 关系），每个 selector 内部 label 是 AND - 跨命名空间调用控制：用
namespaceSelector匹配environment: prod命名空间，再配合podSelector限定其中的role: api-gateway，实现“仅生产环境网关可调用此服务”
用 CiliumNetworkPolicy 补足应用层精细策略
原生 NetworkPolicy 仅支持 L3/L4（IP+端口+协议），对微服务真实场景常显不足。Cilium 提供 CiliumNetworkPolicy CRD，支持：
- FQDN 级别出站控制：限制
payment-service只能访问api.stripe.com和metrics.internal，防止恶意域名外连 - HTTP 方法与路径匹配：例如只允许
GET /health和POST /orders，拒绝其他所有 HTTP 请求 - TLS SNI 字段识别：在加密流量中识别目标服务域名，实现 mTLS 场景下的路由级策略
- 结合身份标识（如 SPIFFE ID）做服务身份认证，而非仅靠标签，提升零信任强度
关键协同要点与避坑提醒
单独配置某一层容易失效。实际落地需注意：
- 确保 CNI 插件已启用 NetworkPolicy 支持（如 Calico、Cilium 或 Weave 必须开启策略模式；Flannel 默认不支持）
- NetworkPolicy 中的
podSelector必须匹配目标 Pod 的实际 labels，且该策略需部署在目标 Pod 所在命名空间（除非使用namespaceSelector显式跨空间） - Docker 自定义网络适用于单机开发/测试或边缘轻量集群；K8s 策略适用于生产集群——两者共存时，Docker 层隔离是第一道防线，K8s 层策略是第二道、也是更灵活的防线
- 避免在策略中硬编码 IP 或主机名；全部基于 label 和 identity，才能适配自动扩缩容与滚动更新
