2. Sigstore 核心组件：Fulcio、Rekor 与 Cosign

Sigstore 并非单一工具，而是一套由三个核心组件构成的开放签名基础设施。理解每个组件的职责及其交互流程，是进行签名验证与资源配额调优的前提。本章将逐一拆解 Fulcio、Rekor 和 Cosign 的功能、架构与关键配置。

2.1 组件总览与职责划分

三个组件分别承担证书颁发、日志审计与签名操作的角色，形成“颁发-记录-验证”的闭环。

2.2 Fulcio：短期证书颁发机构

Fulcio 是 Sigstore 的证书颁发机构，它利用 OIDC（OpenID Connect）协议，将用户的短期身份（如 GitHub Actions 的 ID ）映射为代码签名证书。证书有效期通常为 10 分钟，大幅降低了密钥泄露风险。

2.2.1 证书颁发流程

1. 身份断言：用户通过 OIDC Provider（如 GitHub、Google）获取身份令牌。
2. 证书请求：Cosign 将身份令牌与公钥发送至 Fulcio。
3. 身份验证：Fulcio 验证令牌签名，提取用户身份信息（如邮箱）。
4. 证书签发：Fulcio 生成 X.509 证书，绑定用户身份与公钥，返回给 Cosign。
5. 证书使用：Cosign 使用私钥对工件签名，并将证书附加到签名中。

2.2.2 关键配置参数

2.3 Rekor：透明日志与审计

Rekor 维护一个不可变的、可验证的透明日志，用于存储签名元数据。每次签名操作都会生成一个条目，包含工件哈希、签名、证书等信息。任何人都可以查询日志，验证签名是否在特定时间点存在。

2.3.1 日志条目结构

{
  "kind": "hashedrekord",
  "apiVersion": "0.0.1",
  "spec": {
    "data": {
      "hash": {
        "algorithm": "sha256",
        "value": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
      }
    },
    "signature": {
      "content": "MEUCIQ...",
      "publicKey": {
        "content": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0t..."
      }
    }
  }
}

2.3.2 存储与查询

• 存储后端：支持内存、MySQL、PostgreSQL、Trillian（默认为内存，生产环境建议使用 Trillian + MySQL）。
• 查询接口：通过 REST API 按 UUID、工件哈希或签名证书查询。
• 冷启动影响：Rekor 启动时需要加载已有日志索引，数据库连接池大小直接影响启动速度。

2.4 Cosign：签名与验证客户端

Cosign 是 Sigstore 的 CLI 工具，负责执行实际的签名与验证操作。它支持容器镜像、Blob 文件、记录等多种工件类型。

2.4.1 签名命令示例

# 使用密钥对签名
cosign sign --key cosign.key ghcr.io/myorg/myimage:v1

# 使用 Fulcio + Rekor 进行无密钥签名
cosign sign ghcr.io/myorg/myimage:v1

# 验证签名
cosign verify --key cosign.pub ghcr.io/myorg/myimage:v1

2.4.2 冷启动相关配置

2.4.3 重试与退避策略

在冷启动削峰场景中，Cosign 客户端应实现指数退避重试，避免瞬时高并发压垮 Fulcio 或 Rekor。

# 示例：使用 retry 库实现重试
import (
    "github.com/avast/retry-go"
)

err := retry.Do(
    func() error {
        return cosign.Verify(ctx, imageRef, opts)
    },
    retry.Attempts(3),
    retry.Delay(500 * time.Millisecond),
    retry.MaxDelay(5 * time.Second),
)

2.5 组件协同与冷启动影响

三个组件在签名流程中紧密协作，任何一个组件的冷启动延迟都会拖慢整体签名速度。下表总结了各组件在冷启动阶段的关键瓶颈。