4. 多集群身份与信任：SPIFFE标准、工作负载身份、信任域、证书轮换机制
在ClusterMesh多集群架构中，身份与信任是安全通信的基石。每个工作负载（Pod）都需要一个不可伪造的身份，以便在跨集群通信时进行认证和授权。本章深入解析SPIFFE标准、工作负载身份、信任域以及证书轮换机制，帮助您构建零信任的多集群网络。
4.1 SPIFFE标准：通用工作负载身份规范
SPIFFE（Secure Production Identity Framework for Everyone）是一个开放标准，定义了如何在动态、异构的环境中为工作负载颁发和验证身份。其核心是SPIFFE ID，格式如下：
spiffe://<trust-domain>/<path>- trust-domain：信任域，标识身份的可信边界，通常对应一个集群或组织。
- path：工作负载的路径，用于唯一标识一个服务或Pod。
在Kubernetes环境中，SPIFFE ID通常映射为：
spiffe://cluster.local/ns/<namespace>/sa/<service-account>这种设计使得身份与基础设施解耦，工作负载迁移或扩缩容时，身份保持不变。
关键点：SPIFFE标准不依赖IP地址或DNS名称，而是基于加密身份（X.509证书或JWT令牌），天然适合动态、多集群的云原生环境。
4.2 工作负载身份：从ServiceAccount到SPIFFE证书
在ClusterMesh中，每个Pod的身份由以下组件共同构成：
| 组件 | 作用 | 说明 |
|---|---|---|
| Kubernetes ServiceAccount | 身份声明 | Pod通过绑定的ServiceAccount声明自己的身份归属 |
| SPIFFE ID | 身份标识 | 将ServiceAccount映射为标准的SPIFFE格式ID |
| X.509证书 | 身份凭证 | 由集群CA签发的短期证书，包含SPIFFE ID |
| Envoy Sidecar | 身份代理 | 负责加载证书、发起mTLS握手、验证对端身份 |
工作负载身份的生命周期如下：
- Pod启动时，Cilium Agent为其生成私钥和证书签名请求（CSR）。
- Agent将CSR提交给集群的CA（Certificate Authority）。
- CA验证Pod的ServiceAccount后，签发包含SPIFFE ID的X.509证书。
- 证书和私钥通过本地Unix Socket注入到Pod的Envoy Sidecar中。
- Sidecar使用该证书与其他集群的Sidecar建立mTLS连接。
最佳实践：确保每个ServiceAccount对应一个独立的SPIFFE路径，避免多个服务共享同一身份，以便实现细粒度的访问控制。
4.3 信任域：多集群信任边界
信任域（Trust Domain）定义了身份的可信边界。在单集群场景下，信任域通常为cluster.local。在多集群场景下，每个集群可以拥有独立的信任域，也可以共享同一个信任域。
ClusterMesh支持两种信任域模型：
| 模型 | 信任域配置 | 适用场景 | 安全级别 |
|---|---|---|---|
| 统一信任域 | 所有集群使用相同的信任域（如cluster.local） |
完全信任的集群联邦 | 中 |
| 独立信任域 | 每个集群使用不同的信任域（如cluster1.local、cluster2.local） |
多租户、安全隔离要求高 | 高 |
当使用独立信任域时，跨集群通信需要建立信任域之间的信任关系。ClusterMesh通过以下方式实现：
- 根CA交换：集群之间交换根CA证书，建立双向信任。
- 信任锚点：每个集群维护一个信任锚点列表，包含其他集群的根CA。
- 身份验证：验证对端证书时，检查其SPIFFE ID的信任域是否在信任锚点列表中。
4.4 证书轮换机制：自动续期与安全
短期证书是零信任安全模型的核心。ClusterMesh默认使用15分钟有效期的证书，并实现自动轮换机制，确保证书泄露的影响范围最小化。
4.4.1 证书轮换流程
- 定时检查：Envoy Sidecar每隔证书有效期的1/3（默认5分钟）检查证书剩余时间。
- 触发轮换：当证书剩余时间小于有效期的一半（约7.5分钟）时，触发轮换。
- 生成新CSR：Sidecar生成新的私钥和CSR，发送给Cilium Agent。
- CA签发：Agent将CSR提交给集群CA，CA验证后签发新证书。
- 热加载：新证书加载到Sidecar中，旧证书在过期后自动废弃。
- 连接保持：已建立的mTLS连接不受影响，新连接使用新证书。
注意：证书轮换期间，如果CA不可用，Sidecar会继续使用旧证书直到其过期。建议为CA配置高可用，避免单点故障导致整个集群的证书无法续期。
4.4.2 证书轮换参数
| 参数 | 默认值 | 说明 |
|---|---|---|
certificate-validity-duration |
15m | 证书有效期，建议不超过1小时 |
certificate-renewal-before-expiry |
7m30s | 证书到期前多久开始轮换 |
ca-validity-duration |
365d | 根CA证书有效期 |
ca-renewal-before-expiry |
30d | 根CA到期前多久开始轮换 |
4.4.3 根CA轮换策略
根CA证书轮换比工作负载证书更复杂，需要确保新旧CA的平滑过渡。ClusterMesh支持以下策略：
- 双CA模式：同时维护新旧两个CA，旧CA继续验证已有连接，新CA用于签发新证书。
- 信任锚点更新：在跨集群场景下，需要同步更新所有集群的信任锚点列表。
- 手动验证：根CA轮换建议在维护窗口执行，并验证所有集群的mTLS连接正常。
4.5 多集群信任验证实战
在ClusterMesh中，验证多集群信任是否正常工作的常用方法：
# 查看集群A的信任锚点
kubectl exec -n kube-system ds/cilium -c cilium-agent -- cilium identity list
# 查看集群B的信任锚点
kubectl exec -n kube-system ds/cilium -c cilium-agent -- cilium identity list
# 验证跨集群mTLS连接
kubectl exec -n kube-system ds/cilium -c cilium-agent -- cilium monitor -t trace | grep "from identity"
# 检查证书状态
kubectl exec -n kube-system ds/cilium -c cilium-agent -- cilium status | grep "Certificate"
排障提示：如果跨集群通信失败，首先检查信任域配置是否一致，然后验证根CA证书是否已正确交换。使用
cilium connectivity test命令可以快速诊断多集群网络连通性和身份认证问题。
4.6 安全加固建议
- 缩短证书有效期：将工作负载证书有效期从15分钟缩短至5分钟，进一步降低泄露风险。
- 启用证书吊销：配置CRL（Certificate Revocation List）或OCSP（Online Certificate Status Protocol），在证书泄露时立即吊销。
- 审计证书轮换：记录所有证书签发和轮换事件，便于事后审计。
- 隔离信任域：生产环境与非生产环境使用不同的信任域，避免跨环境身份混淆。
- 定期轮换根CA：至少每6个月轮换一次根CA证书，并验证所有集群的信任关系。