2. Sigstore 核心组件：Cosign、Fulcio、Rekor、Gitsign 的架构与职责

Sigstore 并非单一工具，而是一套由多个开源组件构成的 供应链安全基础设施。每个组件承担明确的职责边界，共同实现“无密钥签名、透明日志记录、可验证信任链”的最终目标。理解这四大核心组件的架构与交互关系，是后续进行项目部署与边界适配的前提。

2.1 组件全景与职责矩阵

下表从功能定位、输入输出、信任模型三个维度，对 Cosign、Fulcio、Rekor、Gitsign 进行横向对比：

2.2 组件架构与交互流程

下图展示了 Sigstore 默认工作流中四个组件的调用关系与数据流向：

2.3 组件深度解析

2.3.1 Cosign — 镜像签名与验证引擎

Cosign 是 Sigstore 生态中使用最广泛的客户端工具，负责对容器镜像、Blob、文档等工件进行签名和验证。其架构特点包括：

• 无密钥模式：通过 Fulcio 获取短期证书，签名后私钥立即销毁，无需管理长期密钥。
• 密钥模式：支持传统的本地密钥对（KMS、硬件令牌），适用于离线或自建 CA 场景。
• 签名存储：签名对象以 OCI 附件形式存储在镜像仓库中，与镜像同生命周期。
• 策略引擎：支持 cosign verify 结合自定义策略（如强制要求特定签发者、证书主体）。

2.3.2 Fulcio — 短期证书颁发机构

Fulcio 实现了 OIDC 身份绑定证书颁发 流程，是 Sigstore 无密钥签名的信任基础：

• 证书格式：颁发 X.509 v3 证书，有效期通常为 10 分钟，包含 OIDC 身份信息（Email、Issuer）。
• 根 CA：Fulcio 实例拥有自己的根证书，客户端验证时需信任该根证书。
• OIDC 集成：支持 GitHub、Google、GitLab、Microsoft 等主流身份提供商。
• 审计能力：所有颁发的证书均可通过 Rekor 日志回溯，确保证书发放行为透明。

2.3.3 Rekor — 透明日志与审计溯源

Rekor 是 Sigstore 的 不可篡改审计日志，记录所有签名事件和证书颁发记录：

• 数据结构：基于 Merkle Tree 实现，支持增量一致性证明和审计证明。
• 搜索接口：支持按工件哈希、公钥哈希、Email、UUID 检索签名记录。
• 时间戳服务：Rekor 可为日志条目提供 RFC 3161 时间戳，证明签名在某个时间点之前已存在。
• 存储后端：支持 MySQL、PostgreSQL、Trillian（分布式 Merkle Tree）。

2.3.4 Gitsign — Git 提交签名扩展

Gitsign 将 Sigstore 的 OIDC 签名能力引入 Git 工作流，替代传统的 GPG 签名：

• 工作方式：作为 Git 的 gpg.format 后端，通过 git commit -S 触发签名。
• 证书来源：复用 Fulcio 证书，无需用户自行生成或上传公钥。
• 验证方式：通过 git verify-commit 或 cosign verify-blob 验证提交签名。
• 透明性：每次签名操作自动向 Rekor 提交记录，便于团队审计提交来源。

2.4 组件部署依赖关系

在私有化部署场景中，组件之间存在明确的启动依赖顺序：

1. 先部署 Fulcio 和 Rekor：两者无相互依赖，可并行启动。Fulcio 需要配置 OIDC 提供商对接信息；Rekor 需要初始化数据库和 Merkle Tree 状态。
2. 再部署 Cosign：配置 --fulcio-url 和 --rekor-url 指向内部服务。Cosign 本身无状态，可作为 CLI 工具或 SDK 集成。
3. 最后部署 Gitsign：依赖 Fulcio 和 Rekor 的可用性，安装后需在 Git 全局配置中启用。

2.5 信任边界与安全假设

理解每个组件的信任边界，有助于在架构适配中做出正确的安全决策：