3. 签名链路核心组件：签名服务、密钥管理服务、证书颁发机构、签名验证代理

多租户签名链路并非单一服务，而是由四个核心组件协同构成的端到端信任链条。每个组件承担独立的职责边界，并通过网络策略（NetPolicy）进行隔离与通信控制。理解这些组件的内部架构与交互关系，是实现自动化回滚与安全治理的前提。

3.1 组件职责与交互关系

下表从功能定位、关键接口、安全依赖三个维度，对四个核心组件进行对比：

3.2 组件间通信流程

一个完整的签名请求在四个组件间的流转路径如下：

1. 客户端向签名验证代理发起签名请求，附带租户身份令牌与待签名数据。
2. 签名验证代理验证令牌有效性，提取租户上下文，将请求转发至签名服务。
3. 签名服务根据租户策略组装签名载荷，向密钥管理服务请求签名操作。
4. 密钥管理服务确认签名服务身份后，使用租户专属密钥完成签名，返回签名值。
5. 签名服务将签名结果返回给签名验证代理，代理将结果返回客户端，并记录审计日志。

3.3 签名链路架构图

下图展示了四个核心组件在 Kubernetes 集群内的部署拓扑与通信关系：

3.4 各组件关键设计要点

3.4.1 签名服务

• 无状态设计：签名服务不存储任何持久化数据，所有状态（租户策略、密钥引用）均从配置中心或 KMS 获取。
• 租户隔离：每个签名请求必须携带租户 ID，服务根据租户 ID 选择对应的签名策略和密钥引用。
• 幂等性：对于相同的签名请求（基于请求 ID 去重），返回相同的签名结果，确保重试安全。

3.4.2 密钥管理服务 (KMS)

• 密钥分层：采用主密钥（Master Key）+ 数据密钥（Data Key）的分层结构，主密钥存储在 HSM 中，数据密钥由主密钥加密后存储。
• 密钥轮换：支持自动轮换策略，轮换期间旧密钥仍可用于验证，新密钥用于签名，确保签名链路不中断。
• 访问审计：每次密钥操作均记录操作者、时间、操作类型，审计日志不可篡改。

3.4.3 证书颁发机构 (CA)

• 证书生命周期管理：支持证书的签发、续期、吊销、更新，吊销列表（CRL）实时同步至签名验证代理。
• 租户证书隔离：每个租户拥有独立的证书链，租户 A 的证书无法用于租户 B 的签名验证。
• 自动续期：证书到期前自动触发续期流程，续期期间新旧证书同时有效，避免服务中断。

3.4.4 签名验证代理

• 策略引擎：基于租户、请求来源、签名算法、时间窗口等多维度执行访问控制策略。
• 审计日志：记录完整的请求链路轨迹，包括请求时间、租户 ID、签名结果、验证结果，用于事后追溯。
• 流量整形：支持限流、熔断、重试，防止恶意请求压垮下游签名服务。

3.5 组件间的网络策略隔离

在 Kubernetes 环境中，通过 NetworkPolicy 实现组件间的强制隔离。下表展示了默认的 NetPolicy 规则：

3.6 组件健康检查与故障隔离

每个组件必须实现独立的健康检查端点，用于 Kubernetes 的存活探针（liveness probe）和就绪探针（readiness probe）：

# 签名服务健康检查端点
GET /healthz
响应: {"status": "ok", "components": {"kms": "connected", "ca": "connected"}}

# KMS 健康检查端点
GET /healthz
响应: {"status": "ok", "hsm": "active", "key_count": 128}

# CA 健康检查端点
GET /healthz
响应: {"status": "ok", "cert_count": 1024, "crl_version": 5}

# 签名验证代理健康检查端点
GET /healthz
响应: {"status": "ok", "upstreams": {"signer": "healthy", "ca": "healthy"}}

当某个组件健康检查失败时，Kubernetes 会自动重启该组件，同时签名验证代理会将该组件标记为不可用，触发流量切换到备用实例或返回降级响应。