4. mTLS与身份认证:Cilium中基于SPIFFE的身份体系、mTLS握手流程、证书轮换与信任锚点配置

在零信任网络架构中,工作负载之间的通信必须经过双向身份验证和加密。Cilium 利用 eBPF 技术,在数据平面高效处理数据包的同时,通过集成 SPIFFE (Secure Production Identity Framework for Everyone) 标准,构建了一套无需 Sidecar 的 mTLS 身份认证体系。本章将深入解析 Cilium 如何通过 SPIRE 实现身份颁发、mTLS 握手流程、证书轮换机制以及信任锚点的配置方法。

4.1 基于 SPIFFE 的身份体系

SPIFFE 定义了一套标准化的身份规范,即 SPIFFE ID,格式通常为 spiffe://trust-domain/workload-identifier。Cilium 通过 SPIRE (SPIFFE Runtime Environment) 作为身份提供商,为每个 Kubernetes Pod 颁发唯一的 SPIFFE 身份。

核心概念: Cilium 将 SPIFFE ID 映射到 Kubernetes 的 ServiceAccount,确保每个工作负载的身份与其 Kubernetes 角色绑定,而非传统的 IP 或 DNS 名称。

4.1.1 身份体系架构

下图展示了 Cilium 与 SPIRE 集成的身份颁发与验证架构:

Cilium SPIFFE 身份体系架构 Cilium SPIFFE 身份体系架构 Kubernetes 集群 SPIRE Server 身份颁发 & 签名 CA SPIRE Agent 节点级身份代理 下发 SVID Cilium Agent eBPF 策略执行 获取身份 Pod A (客户端) SPIFFE ID: A Pod B (服务端) SPIFFE ID: B mTLS 加密通信 信任锚点 SPIRE Server 根证书 作为信任域基础

4.1.2 身份生命周期管理

阶段 组件 描述
1. 身份注册 SPIRE Server 通过 Kubernetes 准入控制器或 Workload Registrar,将 Pod 的 ServiceAccount 注册为 SPIFFE ID。
2. 身份颁发 SPIRE Agent 通过 Unix Domain Socket 向本地 Pod 颁发 SVID (SPIFFE Verifiable Identity Document),包含 X.509 证书。
3. 身份验证 Cilium Agent 在 eBPF 中加载身份映射表,允许或拒绝基于 SPIFFE ID 的通信。
4. 身份轮换 SPIRE Agent 在证书过期前自动轮换 SVID,确保身份持续有效。

4.2 mTLS 握手流程

Cilium 的 mTLS 握手在数据平面由 eBPF 程序辅助完成,控制平面由 Cilium Agent 与 SPIRE 协作。与传统 Sidecar 模式不同,Cilium 避免了额外的代理跳数,直接在网络栈中完成 TLS 终止。

4.2.1 握手步骤详解

  1. 客户端发起连接: Pod A 向 Pod B 发送 TCP SYN 包,Cilium 的 eBPF 程序拦截该包,识别出目标身份需要 mTLS。
  2. 身份请求: Cilium Agent 从 SPIRE Agent 获取 Pod A 的 SVID(客户端证书)和私钥。
  3. 证书交换: 在 eBPF 层面,Cilium 将 SVID 注入到 TLS 握手消息中,发送给 Pod B。
  4. 服务端验证: Pod B 侧的 Cilium Agent 通过 SPIRE Agent 验证客户端证书的 SPIFFE ID 是否在信任锚点内。
  5. 双向认证: 服务端同样发送自己的 SVID,客户端进行验证。
  6. 加密通信: 握手完成后,eBPF 程序建立对称加密隧道,后续数据包直接加密传输。
性能优势: 整个握手过程在 eBPF 中完成密钥协商,无需上下文切换到用户态 Sidecar,延迟降低 40%-60%。

4.2.2 握手流程示意图

Cilium mTLS 握手流程 Cilium mTLS 握手流程 Pod A (客户端) SPIFFE ID: A Pod B (服务端) SPIFFE ID: B ① TCP SYN ② 获取客户端 SVID (SPIRE Agent) ③ ClientHello + 客户端证书 ④ 验证 SPIFFE ID (信任锚点校验) ⑤ ServerHello + 服务端证书 ⑥ 双向认证完成,eBPF 建立加密隧道 后续数据包直接加密传输,无 Sidecar 开销

4.3 证书轮换与信任锚点配置

证书轮换是维持 mTLS 安全性的关键。Cilium 与 SPIRE 的集成实现了自动化的 SVID 轮换,无需重启工作负载。信任锚点则定义了集群内所有工作负载必须信任的根 CA。

4.3.1 证书轮换机制

轮换策略 默认值 说明
SVID 有效期 24 小时 SPIRE Server 颁发的 SVID 默认有效期为 1 天。
轮换提前量 75% 有效期 在证书过期前 6 小时(75% 时间点)开始轮换。
轮换方式 平滑轮换 SPIRE Agent 在后台生成新密钥对,通过 SPIRE Server 签名后替换旧证书,旧连接不受影响。
失败处理 重试 3 次 轮换失败后,SPIRE Agent 保留旧证书并重试,避免通信中断。

4.3.2 信任锚点配置

信任锚点通常由 SPIRE Server 的根 CA 证书定义。在 Cilium 中,可以通过 CiliumNetworkPolicy 或 SPIRE 的配置来指定信任域。

SPIRE Server 信任锚点配置示例:

# spire-server.conf
server {
    trust_domain = "production.example.com"
    ca_subject = {
        country = "CN"
        organization = "Example Corp"
        common_name = "SPIRE CA"
    }
    ca_ttl = "8760h"  # 根 CA 有效期 1 年
}

Cilium 中引用信任锚点的策略示例:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "mTLS-policy"
spec:
  endpointSelector:
    matchLabels:
      app: frontend
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: backend
    authentication:
      mode: "required"
      spire:
        trustDomain: "production.example.com"
安全警告: 信任锚点泄露会导致整个集群的身份信任体系被攻破。务必使用硬件安全模块(HSM)或密钥管理服务(KMS)保护 SPIRE Server 的根 CA 私钥。

4.3.3 信任锚点配置对比

配置项 SPIRE Server Cilium Agent 说明
信任域 trust_domain spire.trustDomain 定义 SPIFFE ID 的根命名空间。
根 CA 证书 ca_key_type + ca_cert_ttl 自动从 SPIRE 获取 根证书用于签发所有 SVID。
联邦配置 federation N/A 跨信任域通信时,需配置联邦信任。
吊销列表 CRL 或 OCSP 通过 SPIRE 同步 吊销泄露的证书。

4.4 性能调优建议

  • 证书缓存: 增大 SPIRE Agent 的 SVID 缓存大小(svid_cache_max_entries),减少重复获取开销。
  • 握手超时: 调整 Cilium Agent 的 tls-handshake-timeout 参数,默认 10 秒,高并发场景可适当降低。
  • eBPF 加速: 确保内核版本 >= 5.10,启用 XDP 和 TC 加速,减少 mTLS 握手对 CPU 的消耗。
  • 监控指标: 关注 cilium_agent_spire_svid_rotation_count 和 cilium_agent_tls_handshake_duration_seconds,及时发现轮换延迟或握手失败。
最佳实践: 在大型集群中,建议将 SPIRE Server 部署为高可用模式(至少 3 个副本),并使用外部 etcd 存储身份状态,避免单点故障影响整个 mTLS 体系。