【零信任安全架构】mTLS 大规模部署的工程现实：联邦、故障排查与根 CA 轮换

本站 服务身份 和 mTLS 工程实践 已经覆盖了 mTLS 的基础握手流程、SPIFFE/SPIRE 架构、SVID 格式和证书分发模式。本文不再重复这些基础，而是聚焦 mTLS 在多集群、混合云、全公司规模部署时才暴露的工程问题。

前置阅读：服务身份（IAM 系列）。

一、SPIRE 联邦：跨信任域的证书互信

1.1 为什么需要联邦

一个公司通常有多个信任域（Trust Domain），对应不同的环境或组织边界：

spiffe://production.example.com     ← 生产环境
spiffe://staging.example.com        ← 预发布环境
spiffe://dev.example.com            ← 开发环境
spiffe://acquisition.example.com    ← 被收购公司的环境

当 production 和 staging 是同一个 CA 签发的证书时，staging 环境中的服务可以验证 production 的证书——这是合理的（测试环境需要调用生产环境的部分服务）。但 acquisition.example.com 有自己的 CA 和策略，它不应该信任 production.example.com 的 CA 自动签发的证书——反之亦然。

SPIRE 联邦（Federation）解决了这个”谁信任谁”的问题。

1.2 联邦 Bundle 交换

两个信任域 A 和 B 要互信，它们的 SPIRE Server 交换 Bundle（包含各自的根 CA 证书列表和信任域信息）：

# 在 A 的 SPIRE Server 上: 获取 B 的 bundle
spire-server bundle show -federatesWith "spiffe://b.example.com"

# 在 A 的 SPIRE Server 上: 为 B 创建联邦关系
spire-server federation create \
    -bundleEndpointSPIFFEID "spiffe://b.example.com/spire/server" \
    -bundleEndpointURL "https://spire-server.b.example.com:8443" \
    -trustDomain "b.example.com"

联邦 bundle 交换是单向声明的——A 信任 B 的 bundle 不等于 B 也信任 A 的 bundle。每个信任域独立决定信任谁。这比”全局 CA”模型灵活——两个公司合作开发一个项目时可以临时建立联邦关系，合作结束时删除联邦关系。

1.3 联邦中的证书验证

当 Envoy sidecar 收到来自另一个信任域的 mTLS 连接时：

1. 对方出示 SPIFFE ID 为 spiffe://b.example.com/ns/default/sa/partner-api 的证书
2. Envoy 检查本地配置：spiffe://b.example.com 是否在信任的联邦 bundle 列表中？
3. 如果信任，用 B 的 bundle 中的根 CA 证书验证对方的证书链
4. 验证通过后，对方身份在 Istio AuthorizationPolicy 中可以被 principals 规则匹配

关键设计点：Envoy 只验证证书不含任何被吊销的 CA——联邦 bundle 中的根 CA 证书必须是最新的，而 bundle 的更新是通过 SPIRE Agent 定期拉取的。如果联邦 bundle 更新延迟，一个最近被 B 吊销的 CA 仍然会被 A 验证通过——这是联邦机制的一个安全窗口。

二、根 CA 轮换的零停机方案

根 CA 证书的轮换是 mTLS 运维中风险最高的操作——如果轮换不当，所有服务间的 mTLS 连接同时断裂。

2.1 SPIRE 的双 CA 过渡方案

SPIRE 的根 CA 轮换采用双 CA 过渡策略：

旧 CA (即将过期)  ─┐
                   ├─→ 过渡期 ─→ 旧 CA 被移除
新 CA (刚签发)    ─┘

过渡期间的证书签发逻辑：

1. SPIRE Server 创建新的根 CA（T-72h），同时保留旧 CA
2. 在过渡期内（72h），SPIRE Server 签发的所有 SVID 都携带两套信任链（旧 CA 和新 CA）
3. 72h 内，所有服务的旧证书（只被旧 CA 签名）自然过期（SVID TTL = 1h），被替换成新证书
4. 72h 后，旧 CA 被移除——所有现存证书都已被新 CA 签名或者过期
5. 过渡期内没有服务因”验证方不信任新 CA 而拒绝新证书”的问题——因为双 CA 都在信任链中

gantt
    title 根 CA 轮换时间线
    dateFormat HH:mm
    axisFormat %H:%M
    
    section 旧 CA
    旧 CA 在信任链中 :a1, 00:00, 72h
    
    section 新 CA
    生成新 CA :b1, 00:00, 1m
    新 CA 加入信任链 :b2, 00:01, 71h59m
    
    section 证书
    旧证书逐渐过期 :c1, 00:00, 1h
    新证书开始签发 :c2, 00:01, 72h
    所有证书均为新 CA 签发 :milestone, c3, 01:00, 0m
    
    section 清理
    旧 CA 从信任链移除 :milestone, d1, 72:00, 0m

2.2 Root CA 轮换的风险

• 时钟不同步：如果某些节点的时间快了 1 小时，“1 小时有效期”的证书在这些节点上看起来已经过期了——它们会在旧 CA 被移除前就拒绝旧证书。
• Agent 离线：在 T+70h 和 T+72h 之间被关机的节点，在 T+72h 后启动时——它的旧证书已过期（1h TTL），但它的信任链中还只信任旧 CA。这个节点上的新证书请求会失败，因为新 CA 还没被这个 Agent 的信任链接受。
• 联邦 bundle 延迟：信任域 A 的联邦 bundle 中包含了信任域 B 的旧 CA，但 B 的 CA 轮换了——A 的联邦 bundle 必须在 B 的 CA 轮换过渡期结束之前更新，否则 A 将无法验证 B 签发的新证书。

三、mTLS 握手性能

3.1 单节点并发连接的瓶颈

mTLS 握手比单向 TLS 多一步——服务端在 ServerHello 之后向客户端发送 CertificateRequest，客户端需要出示自己的证书。这一步引入了额外的计算和 I/O。

在一个高连接速率的服务节点（每秒新建 10K 个连接）上：

结论：在大规模 mTLS 环境中，证书密钥类型的选择对性能有显著影响。 SPIRE 默认使用 ECDSA P-256 密钥——不是因为它”更安全”，而是因为它比 RSA 4096 握手快 3-5 倍，在数千个服务之间建立 mTLS 连接时可节省大量 CPU。

3.2 TLS 会话恢复

TLS 会话恢复（Session Resumption）是缓解握手开销的关键机制。客户端和服务器在首次握手中生成一个 session ticket 或 session ID，后续连接可以跳过完整的握手（包括 mTLS 的客户端证书验证）：

• Session ID（TLS 1.2）：服务端缓存 session 参数。需要服务端维护状态——在负载均衡环境中，后续请求可能被路由到没有该 session 缓存的服务端实例。
• Session Ticket（TLS 1.2/1.3）：服务端加密 session 参数，作为 ticket 发给客户端，客户端在重连时提交 ticket。无状态，但对 mTLS 的客户端证书场景有限制——某些 mTLS 实现不支持 session ticket。

TLS 1.3 的会话恢复比 TLS 1.2 更高效，因为 TLS 1.3 的握手本身就短（1-RTT vs TLS 1.2 的 2-RTT），但不能完全避免证书验证——session ticket 中仍然需要确认客户端证书的有效性。

3.3 mTLS 在 Envoy 中的 SDS（Secret Discovery Service）

Envoy 使用 SDS（Secret Discovery Service）协议从 SPIRE Agent 拉取证书。关键性能参数：

• SDS 拉取频率：Envoy 在证书剩余生命周期的 80% 时触发轮换（不是固定间隔）
• 证书缓存：Envoy 维护一个证书缓存，同一个证书在多个 listener 间共享——不需要为每个 listener 单独拉取
• 热重启：Envoy 热重启时证书缓存会被清空，重启后所有连接重建都会触发新的握手

在 10K Pod 的大集群中，所有证书同时到期会导致 SPIRE Agent 在短时间内承受大量 SDS 请求。解决方案是证书到期的随机抖动——每个证书的实际 TTL 在基准 TTL 的 80%-100% 之间随机——这样证书到期时间会均匀分布在 12 分钟的窗口内（假设 1h TTL）。

四、mTLS 故障排查

mTLS 在生产中出问题时的症状和排查路径：

核心的故障排查工具链：

# 检查当前服务的 SVID
kubectl exec -it payment-service-abc123 -- spire-agent api fetch x509

# 检查信任域 bundle
kubectl exec -it spire-server-0 -- spire-server bundle show

# 验证 mTLS 连接
openssl s_client -connect payment-service:8443 \
    -cert /var/run/spiffe/svid.pem \
    -key /var/run/spiffe/svid.key \
    -CAfile /var/run/spiffe/bundle.pem

五、总结

mTLS 从”单集群内启用”到”全公司规模部署”的额外问题集中在三个领域：

1. 联邦：跨信任域的证书互信——谁信任谁、联邦 bundle 的更新延迟
2. 运维：根 CA 轮换的零停机方案——双 CA 过渡的时间窗口、Agent 离线、时钟同步
3. 性能：高连接速率下 mTLS 握手的 CPU 开销——ECDSA P-256 vs RSA 4096、TLS 会话恢复

下一篇：软件定义边界与 ZTNA。

参考资料

1. SPIFFE. SPIRE Federation. https://spiffe.io/docs/latest/spire/using/federation/
2. SPIFFE. SPIRE Server Configuration. https://spiffe.io/docs/latest/deploying/spire_server/
3. Envoy. Secret Discovery Service (SDS). https://www.envoyproxy.io/docs/envoy/latest/configuration/security/secret
4. IETF. The Transport Layer Security (TLS) Protocol Version 1.3. RFC 8446.