微服务内部调用：全量 mTLS 还是"信任内网"——你的安全/性能边界画在哪？

背景

我过去 8 年做分布式系统安全加固，反复遇到同一个分歧：微服务之间（同 Pod / 同 Namespace / 同集群）要不要强制 mTLS？

现状大概是：

• 入口网关 → 后端：TLS 1.3，证书由 CA 统一签发，没什么争议；
• 后端之间：大量团队走 HTTP 明文，理由是"内网本来就隔离"、"性能敏感（延迟 +1~3ms / 吞吐降 5~15%）"、"运维复杂度（证书轮转、Sidecar 资源开销）"。

但另一边，K8s 集群一旦被攻破（供应链投毒、Node 逃逸、RBAC 配置错误），横向移动成本极低——明文 RPC 等于把 token 和 PII 直接摊在集群网络里，eBPF / tcpdump 一抓一个准。CIS K8s Benchmark、SOC2、等保 2.0 都在往"零信任"方向推，而 SPIFFE/SPIRE、Istio PeerAuthentication、Linkerd Identity 这些方案已经把 mTLS 的运维门槛降到了"加个 CRD 配置"的程度。

常见分歧 / 几种做法

1. 全量 mTLS：所有服务间流量强制 TLS，Sidecar 或 SDK 层做证书管理。代表：金融、政务、医疗行业合规要求。
2. 分级信任：对外 / 跨 Namespace 强制 mTLS，同 Namespace 内允许明文（或仅加密敏感字段）。折中方案，但"分级"标准容易随团队膨胀而模糊。
3. 纯内网信任：依赖 NetworkPolicy 隔离 + 内网物理安全，服务间明文。常见于早期创业团队、资源极度受限场景。
4. 只加密敏感链路：只在涉及 PII / 密钥的调用上启用 mTLS，其余明文。

我的倾向

我倾向"全量 mTLS + 例外审批制"：默认所有服务间流量加密，确因性能瓶颈需要豁免的，走安全评审并限时（如 30 天内必须整改）。理由：

• 现代硬件（AES-NI / 硬件卸载）让 TLS 开销已降到可忽略（<1% CPU）；
• "分级"在 50+ 微服务的系统里会退化成"没人记得哪条链路是明文的"；
• 安全审计和合规成本随"例外数量"线性增长，全量反而最简单。

想听大家

• 你的系统规模（微服务数量、QPS 量级）下，mTLS 实际带来的延迟 / 资源开销是多少？有没有量化数据？
• 你怎么处理"性能敏感链路"（如高频内部 RPC）和 mTLS 的冲突？
• SPIFFE/SPIRE 自建 vs Istio/Linkerd 托管，你们怎么选？
• 如果合规要求"零信任"但团队只有 3 个后端 + 1 个 SRE，你会先做哪一步、砍哪一步？

欢迎贴具体配置、压测数据、踩坑经历，比抽象讨论有用得多。