2. Sigstore 架构全景：Fulcio、Rekor、Cosign 的协作与透明日志不可篡改特性
Sigstore 并非单一工具，而是一套由三个核心组件构成的开放签名生态。理解 Fulcio、Rekor、Cosign 之间的协作关系，是掌握透明日志查询与性能调优的前提。本章从组件职责、交互流程、日志不可篡改机制三个维度展开。
2.1 三大核心组件职责
| 组件 | 全称 | 核心职责 | 输出产物 |
|---|---|---|---|
| Fulcio | Fulcio Certificate Authority | 基于 OIDC 身份签发短期证书 | X.509 签名证书（有效期通常 10 分钟） |
| Rekor | Rekor Transparency Log | 存储签名元数据，提供可审计的透明日志 | Signed Entry Timestamp (SET)、Log Index |
| Cosign | Cosign Signing Tool | 客户端签名、验证、与 Fulcio/Rekor 交互 | 签名文件（.sig）、Bundle |
关键理解：Fulcio 解决“谁签的”，Rekor 解决“什么时候签的且不可抵赖”，Cosign 解决“怎么签和怎么验”。三者缺一不可。
2.2 协作流程：一次完整的签名与记录
下图展示了从开发者触发签名到日志持久化的完整链路：
流程步骤详解
- 发起签名：开发者或 CI 系统调用
cosign sign命令，传入待签名的容器镜像或工件。 - 请求证书：Cosign 自动检测当前 OIDC 身份（如 GitHub、Google、Microsoft），向 Fulcio 发送证书签名请求 (CSR)。
- 签发证书：Fulcio 验证 OIDC 后，签发一张短期 X.509 证书，证书中嵌入用户的身份信息。
- 提交条目：Cosign 使用该证书对工件签名，并将签名、证书、工件哈希等元数据提交至 Rekor 透明日志。
- 返回 SET：Rekor 将条目追加到 Merkle 树，返回 Signed Entry Timestamp (SET) 作为不可篡改的收据。
- 持久化：Rekor 将 Merkle 树根哈希定期发布到公共可审计的检查点，形成全局一致性视图。
性能关注点：步骤 4 和 5 是冷启动场景下的主要瓶颈。Rekor 的写入吞吐、Merkle 树计算延迟、SET 生成速度直接影响签名流水线的端到端延迟。
2.3 透明日志的不可篡改特性
Rekor 基于 Merkle 树（哈希树） 实现不可篡改。其核心机制包括：
- 追加写入：日志只允许追加，不允许删除或修改已有条目。
- Merkle 树根哈希：每个新条目都会改变树根哈希，根哈希定期被签名并公开（称为 Signed Tree Head, STH）。
- 一致性证明：任何人可以验证旧根哈希与新根哈希之间的包含关系，确保日志未被分叉或回滚。
- 包含性证明：给定条目索引和 SET，可以证明该条目确实存在于某个特定版本的日志中。
不可篡改的实践意义
| 安全属性 | 实现方式 | 对 SRE 的启示 |
|---|---|---|
| 防篡改 | Merkle 树根哈希链 | 日志条目一旦写入，无法被静默修改；审计时可信任历史数据 |
| 防抵赖 | SET + 证书链 | 签名者无法否认其签名行为；证书短期有效降低泄露风险 |
| 可审计 | 公开日志 + 一致性证明 | 任何人都可独立验证日志完整性，无需信任第三方 |
| 可追溯 | Log Index + 时间戳 | 支持按索引或时间范围查询，便于故障排查和合规审计 |
冷启动调优注意：不可篡改特性依赖于 Merkle 树的实时计算。在冷启动阶段（Rekor 实例刚启动或缓存未预热），Merkle 树证明的生成和验证延迟会显著升高。后续章节将专门讨论如何通过预计算、缓存和查询优化来缓解这一问题。
2.4 组件协作总结
Sigstore 的架构设计遵循“分离关注点”原则：
- Fulcio 负责身份绑定，将 OIDC 身份映射到短期证书，降低密钥管理成本。
- Rekor 负责透明日志，提供不可篡改的审计线索，是信任的锚点。
- Cosign 负责用户交互，封装了签名、验证、与 Fulcio/Rekor 通信的复杂性。
三者通过标准 API 协作：Cosign 调用 Fulcio 的 /api/v1/signingCert 获取证书，调用 Rekor 的 /api/v1/log/entries 提交和查询条目。理解这一协作关系，是后续分析冷启动性能瓶颈的基础。