【网络工程】mTLS 工程实践：服务间双向认证
原文中文，约20000字，阅读约需48分钟。
📝
内容提要
mTLS（双向TLS）使通信双方互相验证身份，解决微服务中“调用方是谁”的问题。其工程难点在于证书分发与轮换，而非协议本身。最佳实践是短期证书加自动轮换，并借助Service Mesh（如Istio、Linkerd）实现透明化。SPIFFE/SPIRE提供标准化服务身份。部署时应从PERMISSIVE模式渐进迁移至STRICT，并区分认证与授权。
🔎
延伸解读
证书轮换的时序陷阱
mTLS 的证书轮换比单向 TLS 复杂，因为需要同时轮换客户端和服务器证书。若先轮换服务器 CA，旧客户端证书可能不被信任；反之亦然。文章建议采用双 CA 信任期：服务器同时信任新旧 CA，逐步签发新证书，待所有客户端迁移后再移除旧 CA。这避免了轮换过程中的服务中断。
SPIFFE 身份的优势
SPIFFE 提供了标准化的服务身份格式（如 spiffe://cluster.local/ns/default/sa/payment-service），相比传统 CN 命名，它支持多租户隔离、跨集群联邦，并默认使用短期证书（如 1 小时）配合自动轮换，降低证书泄露风险。即使不采用 SPIRE，理解 SPIFFE 模型也有助于设计服务认证方案。
渐进迁移与授权配合
部署 mTLS 时，建议从 PERMISSIVE 模式开始，让新旧流量共存，监控 mTLS 覆盖率，再逐步切换至 STRICT。同时，mTLS 仅解决认证，还需配合授权策略（如 Istio AuthorizationPolicy）控制服务权限。两者结合才能实现完整的零信任访问控制。
🏷️
