4. Sigstore 生态全景：Fulcio、Rekor、Cosign 的协作关系

Sigstore 并非单一工具，而是一套由三个核心组件构成的开放签名生态。理解 Fulcio、Rekor 与 Cosign 的协作关系，是掌握镜像安全水位巡检的前提。这三个组件分别承担了身份认证、日志存证与签名执行的职责，共同实现了“无密钥签名”与“可公开验证”的供应链安全目标。

4.1 三大组件的职责与定位

4.2 协作流程：从签名到验证

一次完整的 Sigstore 签名与验证流程，涉及开发者、CI/CD 系统、容器镜像仓库以及 Sigstore 公共实例之间的多次交互。以下流程图展示了标准协作路径：

4.3 协作步骤详解

1. 发起签名（Cosign → Fulcio）：开发者或 CI 系统调用 cosign sign 命令，Cosign 自动向 Fulcio 发起 OIDC 身份认证请求（支持 GitHub、Google、Microsoft 等身份提供商）。
2. 签发证书（Fulcio → Cosign）：Fulcio 验证 OIDC 令牌后，签发一张短期 X.509 证书，证书中嵌入用户的身份信息（如邮箱地址）。Cosign 使用该证书对应的临时密钥对镜像摘要进行签名。
3. 上传日志（Cosign → Rekor）：Cosign 将签名、证书以及镜像引用信息打包，发送至 Rekor 透明日志。Rekor 返回一个 Signed Entry Timestamp（SET），作为写入成功的凭证。
4. 存储签名（Cosign → 镜像仓库）：Cosign 将签名文件（.sig）与证书一并推送到容器镜像仓库，通常以 镜像名:tag.sig 或 OCI 附加物的形式存储。
5. 验证签名（验证者 → Rekor + 镜像仓库）：Kubernetes 集群或策略引擎（如 Kyverno）拉取镜像与签名，同时向 Rekor 查询日志记录，验证证书是否由 Fulcio 签发、签名是否与镜像摘要匹配、日志条目是否存在于 Merkle 树中。

4.4 组件间的信任模型

Sigstore 的信任模型建立在“透明日志 + 短期证书”之上，与传统 PKI 有本质区别：

• 无长期密钥管理：Fulcio 签发的证书有效期极短，签名完成后私钥即可丢弃，无需像 GPG 或传统 PKI 那样保管长期私钥。
• 日志驱动验证：验证者不直接信任签名者的证书，而是通过 Rekor 日志确认该签名在某个时间点确实被记录。Rekor 的 Merkle 树根哈希会定期发布，任何人都可以独立验证。
• 身份与密钥解耦：证书中的身份信息来自 OIDC 提供商，而非自签名的密钥指纹。这使得验证者可以基于“谁签的名”而非“用了哪把密钥”来做策略决策。

4.5 自建 vs 公共 Sigstore 实例

对于企业级集群升级巡检，需要决定使用 Sigstore 公共实例还是自建私有实例：

• 公共实例（sigstore.dev）：适合开源项目或对外发布的镜像。Fulcio、Rekor 由社区维护，无需自行部署，但签名数据对所有人可见。
• 自建实例：适合内部镜像或合规要求严格的场景。需要自行部署 Fulcio、Rekor 以及 TUF 根证书，运维成本较高，但数据完全可控。