在多个 Kubernetes 集群共同承载业务时，服务之间的远程调用往往要穿越不可信的网络区域。如果仅仅依赖网络隔离或 IP 白名单，一旦边界被突破，攻击者就能伪造请求获取敏感数据。mTLS（双向传输层安全）通过让通信双方都提供并验证证书，把信任从“网络位置”转移到“密码学身份”上，是解决跨集群零信任调用的关键手段。
跨集群 mTLS 的信任模型与核心组件
实现跨集群 mTLS 的第一步是建立统一的信任根。在单集群里，Istio 或 Linkerd 等服务网格会自带一个自签名的证书授权中心（CA），为网格内每个 Pod 签发身份证书。但当服务分布到两个独立集群时，如果两边使用不同的根证书，彼此无法验证对方证书链，握手就会失败。因此我们必须让多个集群共享同一个根 CA，或者采用中间 CA 交叉签名的方式，使任一集群签出的工作负载证书都能被对端校验通过。
身份标识本身也需要跨集群一致。SPIFFE 规范定义的 SPIFFE ID 通常形如 spiffe://cluster.local/ns/default/sa/order-svc，其中包含了集群域名、命名空间和 ServiceAccount。当两个集群的信任域不同时，要通过映射规则把对端身份前缀识别为合法主体。Istio 中的 PeerAuthentication 资源用来声明服务接收连接时的 mTLS 模式，可设为 PERMISSIVE（兼容明文）或 STRICT（仅允许 mTLS），在跨集群迁移阶段一般先 PERMISSIVE 再逐步调严。
除了控制面证书体系，数据面的代理注入也不可忽视。每个业务 Pod 必须被注入 Sidecar 代理，由代理拦截进出流量并执行 TLS 握手。若某集群未开启自动注入，跨集群调用便会退化成明文或单向 TLS。我们可以通过命名空间标签 istio-injection=enabled 确保新负载自动获得代理，同时用 istioctl analyze 检查两边集群的信任配置是否对称。
基于 Istio 多集群的 mTLS 配置实战
假设我们有 cluster-a 与 cluster-b 两个 Kubernetes 集群，已通过 Istio 多集群方案打通了 API 访问。首要动作是让两边使用同一个根证书。我们可以提前用 make 脚本生成根 CA 与中间 CA，再通过 Secret 形式分别装入两个集群的 istio-system 命名空间，覆盖默认的 cacerts。这样两个控制面签发的证书具备相同信任锚，为后续双向认证铺路。
随后在 cluster-a 中部署 ServiceEntry 把 cluster-b 的服务暴露为本集群可解析主机，并配置 DestinationRule 声明流量走 mTLS。下面示例把对 order-svc.cluster-b.svc.global 的调用强制双向认证：
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
name: order-svc-b
spec:
hosts:
- order-svc.cluster-b.svc.global
location: MESH_INTERNAL
ports:
- number: 8080
name: http
protocol: HTTP
resolution: DNS
endpoints:
- address: 10.20.0.11
labels:
cluster: cluster-b
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: order-svc-b-mtls
spec:
host: order-svc.cluster-b.svc.global
trafficPolicy:
tls:
mode: MUTUAL
clientCertificate: /etc/certs/cert-chain.pem
privateKey: /etc/certs/key.pem
caCertificates: /etc/certs/root-cert.pem
上述配置中，clientCertificate 与 privateKey 由 Sidecar 自动挂载，无需手动管理。当 cluster-a 的调用方发起请求时，本地代理会出示证书，cluster-b 的代理校验通过后才转发给业务容器。如果此时我们把对端 PeerAuthentication 设为 STRICT，任何没有证书的直连都会被拒绝并返回 503，从而确保跨集群链路全程加密且双向鉴权。
为验证效果，可以从 cluster-a 的某个调试 Pod 执行 curl -v http://order-svc.cluster-b.svc.global:8080/health，观察是否建立 TLS 会话且服务端未报证书错误。若看到 SSL certificate verify ok 且响应正常，说明 mTLS 已生效。反之若出现 peer certificate verification failed，通常是因为根证书未对齐或信任域映射缺失，需要回查 CA Secret 内容。
常见故障与性能优化建议
跨集群 mTLS 落地时最容易遇到的是证书轮转不一致。Istio 默认每 24 小时自动轮换工作负载证书，如果某集群的控制面时间不同步或根 CA 过期，旧证书失效后新证书未被对端信任，会出现间歇性的连接重置。建议通过 NTP 统一集群时间，并使用 openssl x509 -in cert-chain.pem -noout -dates 定期检查两边证书有效期，避免雪崩式断连。
另一个问题是性能损耗。mTLS 握手相比明文增加了非对称加密运算，在跨集群高并发场景下 CPU 占用可能上升百分之十到二十。我们可以利用会话复用（Session Resumption）减少完整握手次数，Istio 代理默认开启 TLS 会话票据。此外，对延迟极度敏感的内部批处理流量，可考虑在网格内仍用 mTLS，但在集群间专线已物理加密的前提下，将 DestinationRule 的 mode 降为 ISTIO_MUTUAL 并依赖底层网络加密，以平衡安全与开销。
最后要注意的是身份粒度。不要把整个命名空间映射成一个粗粒度身份，而应基于 ServiceAccount 区分不同服务，这样在 AuthorizationPolicy 中才能精细控制“仅允许 payment-svc 调用 order-svc”。下表对比了不同信任策略的差异：
| 策略类型 | 验证内容 | 跨集群适用性 |
|---|---|---|
| 网络策略 IP 白名单 | 源 IP 地址 | 弱，IP 可伪造且跨云难固定 |
| 单向 TLS | 仅服务端证书 | 中，客户端身份未知 |
| mTLS | 双方证书与 SPIFFE ID | 强，零信任基础 |
通过合理规划信任根、精细化身份以及监控证书生命周期，Kubernetes 跨集群服务调用的 mTLS 可以从实验特性变为生产级标准实践，为混合云和多云架构提供稳固的安全底座。
KubernetesmTLS跨集群服务调用修改时间：2026-08-17 05:18:14