Cilium 证书体系：TLS 证书在 Cilium 中的作用（mTLS、Hubble、ClusterMesh）

Cilium 作为一个基于 eBPF 的云原生网络、安全与可观测性平台，其内部通信的安全性高度依赖 TLS 证书体系。理解证书在 Cilium 不同组件间的角色，是进行证书轮换作业与故障排查的基础。本章将深入剖析 mTLS、Hubble 以及 ClusterMesh 场景下的证书作用机制。

3.1 证书体系总览：三大核心场景

Cilium 的证书体系并非单一用途，而是根据通信双方的身份和网络层级，分为三个主要应用场景。下表总结了各场景的证书用途、通信对象及关键特征：

3.2 mTLS：节点间通信的信任基石

在 Cilium 的加密节点间通信（如使用 WireGuard 或 IPsec 时），mTLS 证书用于建立节点之间的信任关系。其工作流程如下：

1. 身份声明： 每个 Cilium Agent 启动时，会从 Kubernetes Secret 或文件系统中加载其节点证书和私钥。
2. 连接发起： 当 Agent A 需要与 Agent B 建立加密隧道时，Agent A 首先发起 TLS 握手。
3. 双向验证：
   • Agent A 向 Agent B 出示其证书，证明自己是合法的节点。
   • Agent B 验证 Agent A 的证书是否由受信任的 CA 签发，且 SPIFFE ID 匹配。
   • Agent B 同样向 Agent A 出示其证书，完成双向验证。
4. 密钥协商： 验证通过后，双方通过 TLS 握手协商出对称加密密钥，用于后续的数据面加密。

3.3 Hubble：可观测性 API 的安全防护

Hubble 组件（Relay、UI、CLI）之间的通信同样依赖 TLS 证书。Hubble Relay 作为 gRPC 服务端，Hubble UI 和 CLI 作为客户端，它们之间通过 mTLS 进行身份验证和通信加密。

• Hubble Relay 证书： 作为服务端证书，用于向客户端证明自己的身份。客户端（UI/CLI）验证该证书是否由 Hubble CA 签发。
• Hubble UI/CLI 证书： 作为客户端证书，用于向 Relay 证明自己的身份。Relay 验证客户端证书是否由 Hubble CA 签发，从而控制访问权限。
• CA 证书： 用于签发和验证所有 Hubble 组件证书。CA 证书的轮换是所有 Hubble 组件证书轮换的前提。

3.4 ClusterMesh：跨集群联邦的信任模型

ClusterMesh 允许跨 Kubernetes 集群的 Pod 直接通信。其证书体系比单集群更复杂，涉及跨集群的信任域联邦。

下图展示了 ClusterMesh 场景下，两个集群之间建立信任关系的证书交互流程：

ClusterMesh 的证书轮换需要特别注意：

• CA 证书一致性： 所有集群的 CA 证书必须保持一致，或者通过联邦机制相互信任。轮换 CA 证书时，需要确保所有集群的 CA 证书更新同步。
• SPIFFE 信任域： 每个集群有自己的信任域（Trust Domain），ClusterMesh 通过配置信任域联邦来允许跨域验证。证书轮换不能改变 SPIFFE ID 的信任域部分。
• 轮换顺序： 建议先轮换 CA 证书，再轮换各集群的节点证书。如果先轮换节点证书而 CA 证书未更新，新证书将无法被验证。

3.5 证书生命周期与轮换策略

Cilium 默认使用自签名的 CA 和证书，证书有效期通常为 1 年。在生产环境中，建议制定明确的证书轮换策略：