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

Sigstore 并非单一工具，而是一套由多个开源组件构成的 无中心化软件签名与验证基础设施。其设计目标是消除传统 PKI 和密钥管理的复杂性，让开发者能够以极低门槛对构建产物（容器镜像、二进制文件、SBOM 等）进行签名，并让消费者能够验证产物的来源与完整性。

本章将深入剖析 Sigstore 生态中的四个核心组件：Cosign（签名/验证客户端）、Fulcio（短期证书颁发机构）、Rekor（透明性日志）和 Gitsign（Git 提交签名工具）。理解它们的架构与职责，是后续进行接口调用和实战集成的基础。

2.1 组件全景与协作关系

在典型的 Sigstore 签名流程中，四个组件协同工作，形成一个完整的信任链。下图展示了它们之间的核心交互关系：

2.2 Cosign：签名与验证的客户端主力

Cosign 是 Sigstore 项目中最广为人知的命令行工具和库，也是整个生态的 用户入口。它负责执行实际的签名生成、签名验证以及签名与 OCI 制品的关联操作。

2.2.1 核心职责

• 容器镜像签名：对 Docker/OCI 镜像进行签名，并将签名作为镜像标签或 OCI 制品附件存储。
• 任意文件签名：支持对二进制文件、文本文件、SBOM、软件包等任意 blob 进行签名。
• 密钥管理：支持本地密钥对、云 KMS（AWS KMS、Azure Key Vault、GCP KMS）、硬件安全模块（HSM）以及 Sigstore 的 密钥无感模式（通过 Fulcio 获取短期证书）。
• 验证策略：提供丰富的验证选项，包括验证签名者身份、证书链、透明性日志包含证明等。
• OCI 操作：直接与 OCI 兼容的镜像仓库交互，实现签名和附件的推送与拉取。

2.2.2 架构特点

Cosign 采用 插件化架构，其核心签名逻辑与具体的存储后端（OCI 仓库、文件系统）解耦。它通过标准输入输出和 OCI 分发规范与外部系统交互。在密钥无感模式下，Cosign 内部会生成一个临时密钥对，私钥仅存在于内存中，签名完成后立即销毁。

2.3 Fulcio：基于 OIDC 的短期证书颁发机构

Fulcio 是 Sigstore 的 证书颁发机构（CA），它解决了传统签名中“如何安全分发公钥”的难题。Fulcio 不验证用户的长期密钥，而是验证用户的 OIDC 身份（如 Google、GitHub、Microsoft 账号）。

2.3.1 核心职责

• 身份绑定：接收来自 Cosign 的证书签名请求（CSR），验证其中携带的 OIDC 令牌。
• 短期证书签发：签发有效期极短（通常为 10 分钟）的 X.509 证书，证书主体信息（Subject）直接映射自 OIDC 身份（如 email 地址）。
• 证书链构建：Fulcio 自身拥有根 CA 证书，签发的证书会形成完整的证书链，便于验证方追溯信任根。
• 审计日志：所有证书签发操作均可被记录和审计。

2.3.2 架构特点

Fulcio 是一个 无状态服务，它不存储任何用户密钥或长期状态。其核心安全假设是：信任 OIDC 提供商的身份验证结果。Fulcio 的根证书是公开的，任何人都可以获取并用于验证。

2.4 Rekor：不可篡改的透明性日志

Rekor 是 Sigstore 的 透明性日志（Transparency Log），它充当了一个公开、可追加、不可篡改的账本，用于记录所有签名元数据。Rekor 是 Sigstore 信任模型的核心支柱，它使得任何人都可以独立验证签名是否在特定时间点存在。

2.4.1 核心职责

• 签名记录存储：接收来自 Cosign 的签名条目（包含签名本身、证书、制品哈希等），并将其永久存储在 Merkle 树中。
• Merkle 树证明：为每个条目生成 Merkle 树包含证明（Inclusion Proof），证明该条目确实存在于日志中。
• 一致性证明：提供日志一致性证明（Consistency Proof），确保日志未被篡改或分叉。
• 搜索与查询：支持通过制品哈希、证书指纹、OIDC 身份等字段搜索历史签名记录。

2.4.2 架构特点

Rekor 使用 Trillian 作为其 Merkle 树实现后端，Trillian 提供了可扩展的、基于 Google Certificate Transparency 技术的日志存储。Rekor 本身是一个 gRPC/REST 服务，对外提供 API 接口供 Cosign 和其他客户端调用。

# 使用 rekor-cli 查询特定镜像摘要的签名记录
rekor-cli search --sha 256:abcdef1234567890abcdef1234567890abcdef1234567890abcdef1234567890

# 输出示例（简化）
Found matching entries:
- UUID: 1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef
- Subject: [sha256:abcdef...] (container image)
- IntegratedTime: 2024-01-15T10:30:00Z
- LogIndex: 12345

2.5 Gitsign：Git 提交的密钥无感签名

Gitsign 是 Sigstore 生态中专为 Git 提交签名 设计的工具。它将 Sigstore 的密钥无感签名模式引入 Git 工作流，让开发者无需配置 GPG 密钥即可对 Git 提交进行签名和验证。

2.5.1 核心职责

• Git 提交签名：作为 Git 的 gpg.format 后端，拦截 git commit 操作，自动使用 Sigstore 流程对提交内容进行签名。
• OIDC 身份绑定：在签名过程中，Gitsign 会触发 OIDC 登录流程，将提交者的身份（如 GitHub 账号）绑定到提交签名上。
• 透明性日志集成：签名后的提交证书和签名数据会自动上传至 Rekor 日志，形成公开可查的审计记录。
• 验证支持：配合 git verify-commit 或 cosign verify 命令，验证 Git 提交的签名有效性。

2.5.2 架构特点

Gitsign 本质上是一个 Git 签名后端适配器。它通过 Git 的 gpg.program 配置项，将 Git 的签名请求转发给 Sigstore 的 Cosign 和 Fulcio 组件。Gitsign 本身不实现 CA 或日志功能，而是完全复用 Sigstore 的现有基础设施。

2.6 组件职责对比总结