Sigstore 核心组件：Fulcio、Rekor、Cosign 架构解析
Sigstore 并非单一工具，而是一套由三个核心组件构成的开放签名基础设施。理解 Fulcio（证书颁发机构）、Rekor（透明日志）和 Cosign（签名工具）的协作关系，是掌握镜像供应链冷启动削峰的前提。本章从架构视角拆解每个组件的职责、交互流程与性能关键点。
组件职责总览
| 组件 | 角色 | 核心产出 | 冷启动影响 |
|---|---|---|---|
| Fulcio | 证书颁发机构（CA） | 短期 X.509 签名证书 | OIDC 令牌交换 + 证书签发延迟 |
| Rekor | 透明日志（Transparency Log） | 签名元数据的 Merkle Tree 证明 | 日志追加与一致性验证 I/O 开销 |
| Cosign | 签名/验证客户端 | 容器镜像签名 + 策略校验 | 签名生成与验证阶段的网络往返 |
Fulcio：短期证书的即时签发架构
Fulcio 的核心设计是消除长期密钥管理。它通过 OIDC（OpenID Connect）协议与身份提供商（如 GitHub、Google、Microsoft）集成，为开发者签发有效期极短（通常 10 分钟）的 X.509 证书。
架构要点： Fulcio 不存储私钥，仅维护 CA 根证书。每次签名请求都触发一次 OIDC 令牌交换，Fulcio 验证令牌后即时签发证书。这种无状态设计降低了密钥泄露风险，但将冷启动延迟转移到了 OIDC 提供商的响应速度上。
Rekor：不可篡改的签名审计日志
Rekor 是一个基于 Merkle Tree 的透明日志系统，所有签名元数据（包括证书、签名值、镜像摘要）都会被追加到日志中。Rekor 不存储镜像本身，只存储签名证明，确保任何签名行为都可被公开审计。
冷启动削峰视角： Rekor 的日志追加操作是 I/O 密集型任务。在镜像大规模发布场景下，Rekor 实例的写入吞吐量可能成为瓶颈。建议使用高性能存储（如 NVMe SSD）并启用批量写入模式。
Cosign：签名与验证的客户端引擎
Cosign 是 Sigstore 的 CLI 工具，负责执行实际的签名生成和验证操作。它协调 Fulcio 和 Rekor 的调用，并将签名结果附加到容器镜像的 OCI 制品中。
| 操作 | Cosign 命令 | 涉及组件 | 性能敏感点 |
|---|---|---|---|
| 签名 | cosign sign |
Fulcio + Rekor | OIDC 令牌获取 + 证书签发 + 日志追加 |
| 验证 | cosign verify |
Rekor + 公钥/证书 | 日志一致性验证 + 证书链校验 |
| 附加签名 | cosign attach |
镜像仓库 | OCI 制品上传延迟 |
| 策略校验 | cosign verify-attestation |
Rekor + 策略引擎 | 断言解析 + 策略匹配 |
三组件协作流程
一次完整的 Sigstore 签名操作遵循以下步骤，理解这个流程有助于定位冷启动阶段的性能瓶颈。
- 身份认证： Cosign 通过 OIDC 协议向身份提供商请求令牌，开发者无需管理长期密钥。
- 证书签发： Cosign 将 OIDC 令牌和生成的公钥发送给 Fulcio，Fulcio 验证后返回短期 X.509 证书。
- 签名生成： Cosign 使用证书中的私钥对镜像摘要进行签名，生成签名载荷。
- 日志记录： Cosign 将签名载荷、证书和镜像摘要提交给 Rekor，Rekor 追加到 Merkle Tree 并返回日志索引。
- 制品附加： Cosign 将签名和日志证明作为 OCI 制品附加到镜像仓库中。
性能调优关键指标
| 组件 | 关键指标 | 冷启动阈值 | 优化方向 |
|---|---|---|---|
| Fulcio | 证书签发延迟 | > 200ms | OIDC 令牌缓存、CA 预生成证书池 |
| Rekor | 日志追加延迟 | > 500ms | 批量写入、异步日志提交、SSD 存储 |
| Cosign | 签名生成延迟 | > 1s | 连接复用、并行签名、跳过 Rekor（keyless 模式） |
| 整体 | 端到端签名延迟 | > 3s | 预热连接、预加载 OIDC 令牌、本地签名缓存 |
注意： 在冷启动场景下，Rekor 的首次日志追加可能因 Merkle Tree 初始化而额外增加 1-2 秒延迟。建议在生产环境中保持 Rekor 实例的常驻连接池，避免每次签名都重建 gRPC 连接。