3. Sigstore 工作流：密钥生成、签名、验证、审计全链路解析
Sigstore 的核心价值在于将软件供应链的签名与验证从“高门槛、弱审计”转变为“零密钥管理、全链路可审计”。本章深入拆解 Sigstore 工作流的四个关键阶段：密钥生成、签名、验证与审计，并揭示每个阶段在云原生冷启动场景下的资源消耗特征。
3.1 全链路工作流总览
Sigstore 工作流以 Fulcio（证书颁发机构）、Rekor（透明日志）和 Cosign（客户端工具）三大组件为核心，形成一条从身份绑定到永久审计的闭环链路。
3.2 密钥生成：临时密钥与 OIDC 身份绑定
Sigstore 采用临时密钥对模型，摒弃传统长期密钥管理。每次签名操作都会生成新的密钥对，私钥仅存于内存，签名完成后立即销毁。
3.2.1 密钥生成流程
- OIDC 身份获取：开发者/CI 系统向身份提供商（GitHub、Google、Microsoft 等）请求身份令牌。
- 临时密钥对生成：Cosign 在本地生成 ECDSA P-256 密钥对（私钥 + 公钥）。
- 证书签名请求（CSR）：Cosign 将公钥与 OIDC 令牌封装为 CSR，发送至 Fulcio。
- Fulcio 签发证书：Fulcio 验证 OIDC 令牌有效性，签发短期 X.509 证书（有效期通常为 10 分钟）。
- 私钥销毁：签名完成后，私钥从内存中安全清除。
冷启动削峰要点：OIDC 令牌获取是典型的网络 I/O 密集型操作。在大量 Pod 同时启动的场景下，身份提供商可能触发限流。建议在集群级别实现 OIDC 令牌缓存，或使用预取机制减少并发请求。
3.3 签名：Cosign 签名与证书嵌入
Cosign 将生成的证书与签名一并存储在 OCI 仓库中，形成“签名 + 证书”的捆绑结构，使验证方无需额外获取公钥。
3.3.1 签名命令与资源消耗
# 标准签名命令
cosign sign --key azurekms://myvault/mykey <image>
# 使用密钥less 模式（推荐）
cosign sign <image>| 签名模式 | 密钥管理 | 冷启动延迟 | 网络请求数 | 适用场景 |
|---|---|---|---|---|
| 密钥less（OIDC + Fulcio） | 零密钥管理 | 中（2-5 次网络交互） | 3（OIDC + Fulcio + Rekor） | CI/CD、临时环境 |
| 本地密钥 | 需管理私钥 | 低（1 次网络交互） | 1（仅 Rekor） | 离线签名、合规要求 |
| KMS 密钥 | 云厂商托管 | 高（KMS API 延迟） | 2（KMS + Rekor） | 企业级密钥管控 |
3.4 验证：证书链验证与 Rekor 查询
验证阶段是冷启动场景下资源消耗最集中的环节。验证方需要完成证书链信任验证、签名有效性校验以及 Rekor 日志查询。
3.4.1 验证流程分解
- 提取签名与证书：从 OCI 仓库的镜像标签或附件中获取 .sig 和 .cert 文件。
- 证书链验证：验证证书是否由 Fulcio 根 CA 签发，检查证书有效期与 OIDC 身份声明。
- 签名验证：使用证书中的公钥验证镜像摘要的签名。
- Rekor 查询：查询透明日志，确认签名条目已被记录且未被篡改。
- 策略评估：根据组织策略（如身份白名单、证书颁发者）决定是否放行。
冷启动削峰警告：Rekor 查询是验证阶段的主要瓶颈。默认情况下，每次验证都需要查询 Rekor 公共实例，网络延迟可达 200-500ms。在集群冷启动时，数千个 Pod 同时验证将导致 Rekor 实例过载。建议部署本地 Rekor 镜像或使用缓存层。
3.5 审计：透明日志与不可篡改证据
Rekor 透明日志是 Sigstore 审计能力的基石。每次签名操作都会生成一个 Merkle 树叶子节点，包含签名元数据、证书指纹和时间戳。
3.5.1 审计数据结构
{
"apiVersion": "0.0.1",
"spec": {
"signature": {
"content": "MEUCIQ...",
"publicKey": {
"content": "LS0t...",
"hash": {
"algorithm": "sha256",
"value": "a1b2c3..."
}
}
},
"signedEntryTimestamp": "2024-01-15T10:30:00Z",
"integratedTime": 1705312200,
"logIndex": 12345678
}
}3.5.2 审计查询方式
| 查询方式 | 命令/工具 | 延迟特征 | 冷启动影响 |
|---|---|---|---|
| Rekor 公共 API | rekor-cli get --log-index |
高（200-500ms） | 严重（公共实例限流） |
| Rekor 本地镜像 | 自建 Rekor 实例 | 低（10-30ms） | 可控（集群内网络） |
| Merkle 树验证 | cosign verify 内置 |
中（50-100ms） | 中等（计算密集型） |
3.6 全链路资源消耗对比
下表总结了 Sigstore 工作流各阶段在冷启动场景下的资源消耗特征，帮助 SRE 团队定位削峰优化点。
| 阶段 | CPU 消耗 | 内存消耗 | 网络 I/O | 延迟敏感度 | 削峰策略 |
|---|---|---|---|---|---|
| 密钥生成 | 低（ECDSA 生成） | 低（~1MB） | 高（OIDC + Fulcio） | 高 | OIDC 令牌缓存、Fulcio 连接池 |
| 签名 | 中（哈希计算） | 低（~2MB） | 中（Rekor 写入） | 中 | 异步签名、批量提交 |
| 验证 | 中（证书解析 + 签名验证） | 中（~5MB） | 高（Rekor 查询） | 极高 | 本地 Rekor 镜像、验证缓存 |
| 审计 | 低（日志查询） | 低（~1MB） | 中（Rekor API） | 低 | 离线审计、日志归档 |
3.7 全链路审计最佳实践
SRE 冷启动检查清单：
- 在集群内部署 Rekor 只读镜像，减少对外部公共实例的依赖。
- 为 Fulcio 和 Rekor 配置连接池，避免冷启动时大量 TCP 连接建立。
- 使用
cosign verify的--certificate-identity和--certificate-oidc-issuer参数缩小验证范围，减少策略评估开销。 - 定期审计 Rekor 日志，验证签名条目的一致性与完整性。
理解 Sigstore 工作流的全链路资源消耗模式，是实施冷启动削峰的前提。下一阶段将深入探讨如何通过资源配额调优，在保证安全性的同时最大化集群启动效率。