2. Sigstore 核心组件：CTL、Rekor、Fulcio、Cosign 功能与架构
Sigstore 并非单一工具，而是一套由多个开源组件构成的软件供应链安全基础设施。其核心目标是通过自动化签名、透明日志记录和公钥基础设施（PKI），消除传统密钥管理中的痛点。本章将深入剖析四个核心组件：Certificate Transparency Log (CTL)、Rekor、Fulcio 和 Cosign，并阐明它们如何协同工作以构建可信的镜像供应链。
2.1 组件全景与协作流程
Sigstore 的架构遵循“签名-记录-验证”的闭环模型。开发者使用 Cosign 生成密钥对或通过 Fulcio 获取短期证书，对镜像进行签名；签名元数据被提交至 Rekor 透明日志；验证者通过查询 Rekor 和 CTL 来确认签名的有效性与来源。下图展示了四个组件之间的核心交互关系：
关键理解：Sigstore 的四个组件并非孤立运行。Fulcio 提供身份绑定，Cosign 执行签名操作，Rekor 保证签名不可篡改，CTL 确保证书颁发可审计。缺少任何一个环节，供应链的可信度都会下降。
2.2 Certificate Transparency Log (CTL) — 证书审计日志
CTL 是 Sigstore 中负责记录所有由 Fulcio 颁发的 X.509 证书的只追加日志。其设计灵感来源于 Google 的 Certificate Transparency (CT) 项目，旨在解决证书颁发机构（CA）的恶意或错误颁发问题。
2.2.1 核心功能
- 证书透明度：强制公开所有已颁发的证书，任何人都可以审计证书的颁发记录。
- 防篡改：基于 Merkle 树结构，一旦证书条目被追加，便无法被删除或修改。
- 快速验证：支持通过 Merkle 树证明（Inclusion Proof）和一致性证明（Consistency Proof）来验证证书是否存在于日志中。
2.2.2 架构要点
| 特性 | 说明 |
|---|---|
| 数据结构 | Merkle 树（哈希树），叶子节点存储证书的 SHA-256 哈希值。 |
| 操作模式 | 仅支持 Add（追加）和 Query（查询），不支持删除或更新。 |
| 监控机制 | 通过 CT Log Monitor 定期检查日志的一致性，防止日志分叉。 |
| 与 Fulcio 的关系 | Fulcio 在颁发证书后，必须将证书提交到 CTL 并获得 Signed Certificate Timestamp (SCT)，否则证书被视为不可信。 |
安全价值：CTL 使得任何未公开的“影子证书”或“后门证书”都无法通过验证。在 Sigstore 体系中，CTL 是 Fulcio 信任链的基石。
2.3 Rekor — 签名透明日志
Rekor 是 Sigstore 的元数据透明日志，用于存储所有与软件制品相关的签名记录、哈希值以及可选的附加元数据。它是整个 Sigstore 生态系统的“唯一事实来源”。
2.3.1 核心功能
- 签名记录存储：接收并存储来自 Cosign 或其他工具的签名条目（Entry）。
- 不可篡改：与 CTL 类似，Rekor 也使用 Merkle 树结构，确保历史记录无法被篡改。
- 可搜索：支持通过制品哈希、公钥哈希、UUID 等方式检索签名记录。
- 时间戳服务：为每个条目提供经过加密验证的时间戳，证明签名在某个时间点之前已经存在。
2.3.2 架构要点
| 特性 | 说明 |
|---|---|
| 数据结构 | Merkle 树，叶子节点存储 Rekord 对象（包含签名、公钥、制品哈希等）。 |
| API 接口 | RESTful API：/api/v1/log/entries（提交）、/api/v1/log/entries/{uuid}（查询）。 |
| 存储后端 | 支持内存、文件系统、Trillian（分布式 Merkle 树）等多种后端。 |
| 验证方式 | 验证者通过 Rekor 的 Public Key 和 Signed Entry Timestamp (SET) 来验证条目真实性。 |
运维注意：Rekor 日志的完整性依赖于 Merkle 树的根哈希。如果 Rekor 服务被攻破或数据损坏，所有依赖该日志的验证都将失效。建议在生产环境中启用 Trillian 后端以实现高可用和一致性。
2.4 Fulcio — 无密钥签名证书颁发机构
Fulcio 是一个专为 Sigstore 设计的轻量级证书颁发机构（CA）。它解决了传统签名中“密钥管理难”的核心问题，通过颁发短期证书实现“无密钥签名”体验。
2.4.1 核心功能
- 身份绑定：将用户的 OIDC（OpenID Connect）身份（如电子邮件、GitHub 账号）绑定到一次性签名密钥上。
- 短期证书：颁发的证书有效期通常为 10 分钟，过期后自动失效，降低了密钥泄露的风险。
- 自动集成：与 Cosign 深度集成，开发者无需手动管理私钥或证书请求。
2.4.2 架构要点
| 特性 | 说明 |
|---|---|
| 证书类型 | X.509 v3 证书，包含 OIDC 身份扩展字段。 |
| 颁发流程 | 用户通过 OIDC 提供者（如 Google、GitHub、Microsoft）认证 → Fulcio 验证身份 → 生成密钥对 → 颁发证书并提交至 CTL。 |
| 信任根 | Fulcio 自身的根证书（Root CA），该根证书被 Sigstore 公共信任列表所包含。 |
| 安全约束 | 证书中嵌入的 OIDC 令牌必须包含 email_verified 声明，防止身份伪造。 |
用户体验：使用 Fulcio 时，开发者只需执行
cosign sign 命令，系统会自动完成 OIDC 登录、证书获取和签名操作。整个过程无需手动导出或备份任何私钥。
2.5 Cosign — 容器镜像签名与验证工具
Cosign 是 Sigstore 生态中的客户端工具，也是开发者最常直接交互的组件。它负责执行实际的签名、验证和存储操作。
2.5.1 核心功能
- 镜像签名：支持对容器镜像、Blob 文件、文本文件等多种制品进行签名。
- 密钥管理：支持多种签名方式：密钥对（本地生成）、无密钥模式（通过 Fulcio 获取短期证书）、密钥引用（KMS、硬件密钥）。
- 签名存储：签名默认存储在镜像仓库的 OCI 镜像索引 或 Tag 中，也可单独上传至 Rekor。
- 策略验证：支持基于 Keyless、Key 或 Policy Controller 的验证策略。
2.5.2 架构要点
| 特性 | 说明 |
|---|---|
| 签名格式 | 使用 DSSE (Dead Simple Signing Envelope) 格式封装签名负载。 |
| 存储位置 | 默认存储在 cosign.sig 或 cosign.att 等 OCI 制品中。 |
| 验证流程 | 从镜像仓库获取签名 → 从 Rekor 获取签名记录 → 从 Fulcio/CTL 验证证书 → 比对公钥或身份。 |
| 扩展性 | 支持通过 Cosign Webhook 或 Policy Controller 集成到 Kubernetes 准入控制中。 |
2.5.3 常用命令示例
# 使用无密钥模式签名镜像（自动通过 Fulcio 获取证书）
cosign sign <registry>/<image>:<tag>
# 使用本地密钥对签名
cosign sign --key cosign.key <registry>/<image>:<tag>
# 验证镜像签名（自动查询 Rekor 和 CTL）
cosign verify <registry>/<image>:<tag>
# 验证并指定身份
cosign verify --cert-identity <email> <registry>/<image>:<tag>
最佳实践：在 CI/CD 流水线中，优先使用 Keyless 模式。它消除了密钥轮换和备份的运维负担，同时通过 Fulcio 和 CTL 提供了更强的身份审计能力。
2.6 组件对比总结
下表从功能定位、数据存储、信任模型和运维复杂度四个维度，对四个核心组件进行横向对比：
| 组件 | 功能定位 | 数据存储 | 信任模型 | 运维复杂度 |
|---|---|---|---|---|
| CTL | 证书审计日志 | 证书哈希 | Merkle 树 + 根证书 | 中（需监控日志一致性） |
| Rekor | 签名元数据日志 | 签名条目 | Merkle 树 + 公钥 | 高（需保证高可用与数据持久化） |
| Fulcio | 证书颁发机构 | 无（仅颁发） | OIDC + 根证书 | 低（可托管） |
| Cosign | 客户端签名/验证 | 无（仅操作） | 密钥 / 证书 | 低（CLI 工具） |