2. Sigstore 核心组件：架构与职责
Sigstore 并非单一工具，而是一套由多个开源组件构成的 签名与透明度基础设施。在云原生配置管理的准入控制场景中，每个组件承担着不可替代的职责：Cosign 负责签名与验证，Fulcio 提供短期证书，Rekor 记录不可篡改的证据，Gitsign 将签名能力扩展到 Git 提交。理解这四者的架构关系，是构建声明式准入策略的基础。
核心原则：Sigstore 通过“签名 + 透明度日志 + 短期证书”的组合，消除了传统 PKI 中密钥管理的痛点，使任何开发者都能在无需托管长期私钥的情况下完成可验证的签名。
2.1 组件总览与职责对比
下表从核心职责、产出物、交互对象三个维度，快速对比四个组件的定位：
| 组件 | 核心职责 | 关键产出物 | 主要交互对象 |
|---|---|---|---|
| Cosign | 容器镜像/工件签名与验证 | 签名（.sig）、SBOM、附件 | OCI 仓库、Rekor、Fulcio |
| Fulcio | 基于 OIDC 签发短期代码签名证书 | X.509 证书（有效期通常为 10 分钟） | OIDC 提供商、Cosign/Gitsign |
| Rekor | 透明日志，存储签名与元数据 | 日志条目、Merkle 树根哈希 | Cosign、Fulcio、审计者 |
| Gitsign | Git 提交签名与验证 | Git 签名提交、Rekor 条目 | Git、Fulcio、Rekor |
2.2 架构交互流程
下图展示了 Sigstore 核心组件在一条典型签名-验证流程中的协作关系：
2.3 Cosign：签名与验证的执行者
Cosign 是 Sigstore 中使用最广泛的组件，直接面向容器镜像、Blob、SBOM 等工件的签名与验证。其核心能力包括：
- 无密钥签名：通过 Fulcio 获取短期证书，无需管理长期私钥。
- 密钥对签名：支持传统的本地密钥对模式，适用于离线或高安全场景。
- 镜像签名与附件：将签名作为 OCI 附件存储在镜像仓库中，与镜像生命周期一致。
- 策略验证：支持基于
cosign verify命令的准入策略，可集成到 Kubernetes 动态准入控制中。
实践要点：在声明式准入策略中，Cosign 的
cosign verify 输出（包括证书链、Rekor 条目、OIDC 身份）是策略引擎判断“是否允许部署”的核心证据。
2.4 Fulcio：基于 OIDC 的证书颁发机构
Fulcio 解决了传统代码签名中“证书管理复杂”的痛点。它作为 短期证书颁发机构（CA），通过 OIDC 协议验证签名者身份，并签发 X.509 证书。
| 特性 | 说明 |
|---|---|
| 身份绑定 | 证书主体（Subject）直接映射 OIDC 身份（如 email、GitHub 用户名） |
| 证书有效期 | 通常为 10 分钟，过期后无法使用，降低私钥泄露风险 |
| 支持的 OIDC 提供商 | GitHub、Google、Microsoft、GitLab 等主流平台 |
| 证书链 | Fulcio 根证书公开可查，验证者无需额外信任配置 |
2.5 Rekor：不可篡改的透明度日志
Rekor 是 Sigstore 的 审计与证据存储层。所有签名元数据（包括证书、签名值、工件哈希）都会被记录到 Rekor 的 Merkle 树中，提供以下保障：
- 不可否认性：一旦写入，条目无法被删除或修改。
- 可审计性：任何人都可以查询 Rekor 日志，验证签名是否在特定时间点存在。
- 离线验证：通过 Merkle 树根哈希，验证者可以在不直接访问 Rekor 的情况下确认条目存在。
注意：Rekor 日志本身不存储工件内容，只存储工件的哈希摘要和签名元数据。工件本身仍存储在 OCI 仓库或对象存储中。
2.6 Gitsign：Git 提交的 Sigstore 签名
Gitsign 将 Sigstore 的签名能力扩展到 Git 提交层面。它替代了传统的 GPG 签名，使用 Fulcio 证书和 Rekor 日志来保护 Git 提交的完整性和身份真实性。
Gitsign 的工作流程如下：
- 开发者执行
git commit -S时，Gitsign 拦截签名操作。 - Gitsign 通过 Fulcio 获取短期证书（基于 OIDC 身份）。
- 签名后的提交被推送到 Git 仓库，同时签名证据被记录到 Rekor。
- 验证者使用
git verify-commit或gitsign verify检查提交签名，并自动查询 Rekor 确认证据。
在云原生配置管理场景中，Gitsign 确保 GitOps 流水线中的每一次配置变更（如 Helm Chart 更新、Kustomize 清单修改）都经过身份验证，为准入策略提供“提交级”的可信证据。
2.7 组件协作与准入策略证据链
在声明式准入策略评审中，四个组件共同构成一条完整的证据链：