2. Sigstore 核心组件：Cosign、Fulcio、Rekor、Certificate Transparency Logs 的功能与交互流程
Sigstore 是一个用于软件签名和验证的标准化服务，旨在消除传统密钥管理的复杂性。其架构由四个核心组件构成：Cosign、Fulcio、Rekor 和 Certificate Transparency Logs (CT Logs)。这四个组件协同工作，形成一个完整的、可审计的签名与验证链路。
2.1 组件功能定义
| 组件 | 核心功能 | 在 Sigstore 中的角色 |
|---|---|---|
| Cosign | 容器镜像签名、验证和存储 | 客户端工具，负责发起签名请求、验证签名，并将签名数据推送到 OCI 仓库或 Rekor |
| Fulcio | 短期证书颁发机构 (CA) | 根据 OIDC 身份签发短期代码签名证书，绑定用户身份与公钥 |
| Rekor | 透明性账本 (Transparency Log) | 不可篡改的签名元数据存储，提供全局可审计的签名时间戳和证据 |
| CT Logs | 证书透明性日志 | 记录 Fulcio 签发的所有证书，防止 CA 滥用或签发恶意证书 |
关键区别： Rekor 存储的是签名事件（签名、公钥、负载摘要），而 CT Logs 存储的是证书本身。两者共同构建了“签名 + 证书”的双重透明性。
2.2 组件交互流程（签名与验证）
Sigstore 的交互流程分为两个主要阶段：签名阶段 和 验证阶段。下图展示了完整的端到端交互。
2.3 签名阶段详细步骤
- 发起签名： 开发者使用
cosign sign命令对容器镜像或工件进行签名。 - 身份认证： Cosign 自动获取 OIDC （如 GitHub、Google、Microsoft 身份），并向 Fulcio 请求一个短期代码签名证书。
- 证书签发与记录： Fulcio 验证 OIDC 后，签发一个有效期通常为 10 分钟的 X.509 证书。同时，Fulcio 将该证书提交到 CT Logs 进行永久记录。
- 签名与存储： Cosign 使用 Fulcio 返回的私钥对工件摘要进行签名，并将签名结果（包含证书和签名数据）推送到 Rekor。Rekor 返回一个唯一的签名条目 UUID。
- 可选存储： Cosign 也可以将签名数据作为 OCI 制品存储在 OCI Registry 中，与镜像共存。
2.4 验证阶段详细步骤
- 触发验证： 验证者（如 CI/CD 系统、策略引擎）使用
cosign verify命令验证工件。 - 获取签名数据： Cosign 从 OCI Registry 或 Rekor 中获取签名和证书。
- 证书链验证： Cosign 向 Fulcio 验证证书的签发链，确保证书由可信的 CA 签发且未过期。
- 透明性验证： Cosign 检查证书是否存在于 CT Logs 中，防止使用未记录的证书。
- 签名条目验证： Cosign 查询 Rekor，验证签名条目是否被正确记录，并比对工件摘要是否匹配。
- 输出结果： 验证通过后，Cosign 输出签名者的身份信息（如邮箱）和签名时间戳。
策略即代码集成点： 在验证阶段，策略引擎（如 Kyverno、OPA）可以调用 Cosign 的验证结果，并根据签名者身份、证书颁发者、签名时间等属性，决定是否允许部署。这是实现“资源配额模型漂移告警”中签名策略校验的基础。
2.5 组件交互关系总结
| 交互对 | 协议/接口 | 传输内容 | 安全要求 |
|---|---|---|---|
| Cosign ↔ Fulcio | HTTPS (gRPC) | OIDC , 证书请求, 签名证书 | mTLS 或 OAuth 2.0 |
| Fulcio ↔ CT Logs | HTTPS (REST) | X.509 证书 | 或 JWT |
| Cosign ↔ Rekor | HTTPS (REST) | 签名负载, 公钥, 证书, 工件摘要 | 或匿名访问 |
| Cosign ↔ OCI Registry | OCI Distribution Spec | 签名制品 (cosign.sig) | Registry 认证 |
注意： 在生产环境中，Fulcio 和 Rekor 通常部署为公共服务（如 sigstore.dev），但企业也可以自建私有实例。自建时，需要额外配置 CT Logs 和 OIDC 提供商，并确保所有组件之间的网络通信加密。