2. Sigstore 核心组件：Fulcio、Rekor、Cosign、Gitsign 与 Policy Controller 概览

Sigstore 并非单一工具，而是一套由多个开源组件构成的 签名与验证生态。每个组件承担独立职责，通过标准化的接口协同工作，共同实现“无密钥签名、透明日志审计、策略化验证”的云原生安全基线。本章将逐一拆解五大核心组件：Fulcio（证书颁发）、Rekor（透明日志）、Cosign（签名与验证）、Gitsign（Git 提交签名）以及 Policy Controller（策略执行）。

2.1 组件全景与职责分工

下表从功能定位、输入输出、信任锚点三个维度对比五大组件，帮助建立全局认知：

2.2 Fulcio：无密钥证书颁发机构

Fulcio 是 Sigstore 的 短期证书颁发机构（CA），它彻底改变了传统软件签名的密钥管理方式。开发者无需生成、保管或轮换长期私钥，而是通过 OIDC（OpenID Connect） 身份提供商（如 GitHub、Google、Microsoft）进行身份认证，Fulcio 在认证通过后即时签发一张 有效期极短（通常 10 分钟） 的 X.509 证书。

• 工作流程：
  1. 开发者使用 cosign sign 或 gitsign 触发签名操作。
  2. 工具自动向 OIDC 提供商发起认证，获取身份令牌。
  3. 工具将身份令牌发送给 Fulcio 服务。
  4. Fulcio 验证令牌有效性，提取身份信息（如 email、用户名），生成证书签名请求（CSR）。
  5. Fulcio 使用其根 CA 私钥签发证书，返回给客户端。
  6. 客户端使用证书对应的临时私钥对工件进行签名，签名完成后证书和私钥均可丢弃。
• 关键特性：
  • 无密钥管理： 私钥仅在内存中短暂存在，不落盘、不备份。
  • 身份绑定： 证书的 Subject 字段直接绑定 OIDC 身份（如 email:user@example.com），签名者身份可追溯。
  • 证书透明度： Fulcio 签发的证书可被 Rekor 记录，形成完整的审计链。

2.3 Rekor：透明日志与审计溯源

Rekor 是 Sigstore 的 透明日志系统，它提供了一个 不可篡改、可公开审计 的账本，用于记录所有签名相关的元数据。任何签名操作产生的证书、签名载荷、工件哈希都会被提交到 Rekor 日志中，并返回一个唯一的 日志条目索引 和 Merkle 证明。

• 核心功能：
  • 签名存证： 将签名事件永久记录在日志中，任何人都可以查询。
  • 时间戳服务： 通过日志的 Merkle 树结构，可以证明某个签名在某个时间点之前已经存在（存在性证明）。
  • 审计追踪： 验证者可以通过 Rekor 查询签名者的身份、签名时间、工件摘要，形成完整的证据链。
• 日志结构： Rekor 使用 Merkle 树 组织日志条目，每个新条目被追加到树中，并更新根哈希。任何人都可以下载整个日志或部分日志，通过 Merkle 证明验证某个条目是否确实存在于日志中。
• 公开实例： Sigstore 社区维护了一个公共的 Rekor 实例（rekor.sigstore.dev），所有使用默认配置的签名操作都会将记录发送至此。组织也可以部署私有的 Rekor 实例。

2.4 Cosign：容器签名与验证工具

Cosign 是 Sigstore 生态中使用最广泛的 命令行工具，专门用于 容器镜像 及其他 OCI 工件的签名、验证和存储。它深度集成了 Fulcio 和 Rekor，使得“开箱即用”的无密钥签名成为可能。

• 核心命令：
  • cosign sign：对镜像进行签名。支持密钥模式和无密钥模式（通过 Fulcio + Rekor）。
  • cosign verify：验证镜像签名。支持多种验证策略（如检查证书身份、检查 Rekor 条目）。
  • cosign attach：将签名、SBOM（软件物料清单）等附件附加到镜像仓库中。
  • cosign triangulate：查找与镜像关联的签名或附件。
• 签名存储： Cosign 将签名作为 OCI 制品 存储在容器镜像仓库中，与镜像本身共存。这使得签名管理简单，无需额外的存储后端。
• 验证流程：
  1. 从镜像仓库拉取签名和镜像。
  2. 从签名中提取证书或公钥。
  3. 验证证书链（信任 Fulcio 根证书）。
  4. （可选）查询 Rekor 日志，验证签名是否被记录且未被篡改。
  5. 验证签名是否匹配镜像摘要。

# 无密钥签名示例（默认使用 Fulcio + Rekor）
cosign sign ghcr.io/myorg/myapp:v1

# 验证签名（自动查询 Rekor 并验证证书身份）
cosign verify ghcr.io/myorg/myapp:v1 \
  --certificate-identity-regexp '.*@myorg\.com$' \
  --certificate-oidc-issuer-regexp 'https://github\.com/login/oauth'

2.5 Gitsign：Git 提交的密钥签名

Gitsign 将 Sigstore 的无密钥签名能力引入 Git 提交 验证。它替代了传统的 GPG 或 SSH 签名方式，开发者无需管理任何密钥，即可对 Git 提交进行签名，并将签名记录到 Rekor 日志中。

• 工作方式：
  1. 配置 Git 使用 Gitsign 作为签名后端：git config --global gpg.format x509 和 git config --global gpg.x509.program gitsign。
  2. 执行 git commit -S 时，Gitsign 自动触发 OIDC 认证。
  3. 从 Fulcio 获取短期证书，对提交对象进行签名。
  4. 将签名和证书信息提交到 Rekor 日志。
  5. 在提交信息中嵌入 Rekor 条目索引，方便后续验证。
• 验证方式： 使用 git verify-commit 或 gitsign verify 命令，Gitsign 会自动从 Rekor 拉取证书和日志证明，验证提交的完整性和签名者身份。
• 优势：
  • 消除了 GPG 密钥的生成、上传、轮换等繁琐操作。
  • 签名者身份直接绑定 OIDC 账户，审计更直观。
  • 所有签名记录集中存储在 Rekor 中，便于组织级审计。

2.6 Policy Controller：集群内策略执行

Policy Controller 是 Sigstore 生态中的 Kubernetes 准入控制器，它允许集群管理员定义 签名验证策略，在 Pod 创建或更新时自动验证镜像签名，拒绝未签名或签名无效的镜像运行。

• 架构位置： Policy Controller 作为 动态准入 Webhook 部署在 Kubernetes 集群中，拦截 Pod 创建请求。
• 策略定义： 使用 CUE 语言 或 Rego 语言 编写策略，支持以下验证维度：
  • 签名者身份： 只允许特定 OIDC 身份（如 user@myorg.com）签名的镜像。
  • 证书颁发者： 只信任来自特定 Fulcio 实例的证书。
  • 透明日志： 要求签名必须在 Rekor 日志中有记录。
  • 密钥策略： 支持公钥白名单模式。
• 工作流程：
  1. 用户执行 kubectl apply -f pod.yaml。
  2. API Server 将请求发送给 Policy Controller Webhook。
  3. Policy Controller 解析 Pod 中的镜像引用。
  4. 调用 Cosign 库验证镜像签名（包括查询 Rekor 和验证证书）。
  5. 根据策略规则做出决策：允许（Allow）或拒绝（Deny）。

# 示例策略（CUE）：只允许由 myorg.com 邮箱签名的镜像
package sigstore

import (
  "github.com/sigstore/policy-controller/pkg/apis/policy/v1beta1"
)

#ImagePattern: "ghcr.io/myorg/*"

#ValidIdentity: v1beta1.IdentitySpec{
  Issuer:  "https://github.com/login/oauth",
  Subject: ".*@myorg\\.com$",
}

#ValidSignature: v1beta1.SignatureVerification{
  Identities: [#ValidIdentity],
}

2.7 组件协作关系图

下图展示了 Sigstore 核心组件在“签名-记录-验证”全生命周期中的协作关系：

2.8 组件选择与部署建议

在实际落地 Sigstore 时，并非所有组件都必须部署。下表根据不同的使用场景给出推荐组合：