2. Sigstore 架构深度解析:信任模型、无密钥签名与协作流程

Sigstore 并非单一工具,而是一套由三个核心组件构成的开放安全服务体系。其设计目标是在不依赖长期密钥管理的前提下,为软件供应链提供可验证的签名与透明性保障。本章将深入拆解 Sigstore 的信任模型、无密钥签名(Keyless Signing)原理,以及 Rekor 与 Fulcio 的协作流程。

2.1 Sigstore 信任模型:从 PKI 到动态信任

传统 PKI(公钥基础设施)依赖长期有效的证书和私钥,密钥泄露是供应链攻击的主要入口。Sigstore 采用 动态、短时、基于身份 的信任模型,核心变化如下:

维度 传统 PKI 模型 Sigstore 信任模型
密钥生命周期 长期(年/月) 短时(分钟/小时)
信任锚点 根 CA 证书 OIDC 身份提供商 + 透明日志
签名者身份 证书 CN/OU OIDC 中的邮箱/身份
密钥泄露影响 吊销困难,历史签名失效 密钥短时,泄露窗口极小
可审计性 依赖 CRL/OCSP 透明日志强制公开

Sigstore 的信任不再依赖“谁持有密钥”,而是依赖“谁在特定时间点通过 OIDC 证明了身份”。这种模型将信任从密钥管理转移到了身份认证与公开审计上。

2.2 无密钥签名(Keyless Signing)原理

无密钥签名是 Sigstore 最具颠覆性的设计。它并非“没有密钥”,而是“签名者不长期持有私钥”。其核心流程如下:

  1. OIDC 身份认证:开发者使用 GitHub、Google、Microsoft 等 OIDC 提供商登录,获取一个短期身份 。
  2. 临时密钥对生成:客户端(如 Cosign)在本地生成一个一次性密钥对(私钥 + 公钥)。
  3. Fulcio 证书请求:客户端将公钥与 OIDC 发送给 Fulcio 证书颁发机构。
  4. 短期证书签发:Fulcio 验证 OIDC 有效后,签发一个有效期极短(通常 10 分钟)的 X.509 证书,将公钥绑定到 OIDC 身份。
  5. 签名与上传:使用临时私钥对工件签名,并将签名、证书、公钥一并上传到 Rekor 透明日志。
  6. 私钥丢弃:签名完成后,临时私钥立即被丢弃,不留存任何长期密钥材料。
关键安全属性: 即使攻击者获取了临时私钥,由于证书有效期极短且已记录在透明日志中,攻击者无法伪造历史签名。验证者只需检查 Rekor 日志即可确认签名在证书有效期内生成。

2.3 Fulcio:轻量级证书颁发机构

Fulcio 是 Sigstore 的证书颁发机构(CA),专门为无密钥签名设计。它不管理长期证书数据库,而是根据 OIDC 身份动态签发短期证书。

  • 证书格式:遵循 X.509 v3 标准,包含 OIDC 身份信息(如 email)、公钥、有效期。
  • 证书有效期:默认 10 分钟,大幅降低密钥泄露风险。
  • 身份绑定:通过 OIDC 中的 sub(subject)和 email 声明将证书与真实身份绑定。
  • 无状态设计:Fulcio 不存储已签发证书,所有证书记录由 Rekor 透明日志负责。
实践建议: 在私有部署中,Fulcio 可以对接企业内部的 OIDC 提供商(如 Keycloak、Azure AD),实现与组织身份体系的集成。

2.4 Rekor:不可篡改的透明日志

Rekor 是 Sigstore 的透明日志系统,充当所有签名事件的公开账本。它基于 Merkle Tree 数据结构,提供以下核心能力:

能力 说明
不可篡改性 一旦写入,无法删除或修改,Merkle Tree 保证完整性
可审计性 任何人都可以查询日志,验证签名事件的存在性
时间戳证明 每条记录包含时间戳,提供签名时间的客观证据
去中心化验证 验证者无需信任任何中心节点,只需检查 Merkle 证明

Rekor 存储的每条记录(Entry)包含:签名、公钥、证书、工件哈希、时间戳以及可选的额外元数据。验证者通过查询 Rekor 即可获取所有验证所需信息,无需与签名者直接交互。

2.5 协作流程:Fulcio + Rekor 的完整交互

下图展示了 Sigstore 无密钥签名过程中,客户端、Fulcio 与 Rekor 三者的完整协作流程:

Sigstore 无密钥签名协作流程 客户端 (Cosign) 生成临时密钥对 OIDC 提供商 GitHub / Google / MS Fulcio CA 签发短期证书 Rekor 透明日志 记录签名事件 工件 (Artifact) 容器镜像 / 二进制 ① 身份认证 ② ③ 公钥+ ④ 短期证书 ⑤ 签名 ⑥ 上传签名+证书 流程说明 ① 客户端通过 OIDC 提供商完成身份认证,获取短期 。 ② 客户端生成临时密钥对,将公钥与 发送至 Fulcio。 ③ Fulcio 验证 后签发短期 X.509 证书,绑定身份与公钥。 ④ 客户端使用临时私钥签名工件,将签名、证书、公钥上传至 Rekor。

2.6 验证流程:如何信任一个无密钥签名

验证者(如 Kubernetes 准入控制器)在收到一个已签名的镜像时,执行以下验证步骤:

  1. 从 Rekor 获取签名记录:根据镜像摘要查询 Rekor,获取对应的签名、证书和时间戳。
  2. 验证证书有效性:检查证书是否由 Fulcio 签发、是否在有效期内、是否被吊销。
  3. 验证 OIDC 身份:从证书中提取 OIDC 身份信息(如邮箱),与策略中允许的身份列表比对。
  4. 验证签名:使用证书中的公钥验证签名是否匹配工件哈希。
  5. 验证透明日志:检查 Rekor 的 Merkle 证明,确认该签名事件确实被记录且未被篡改。
注意: 验证者必须信任 Fulcio 的根证书和 Rekor 的公共实例。在私有部署中,需要将内部 Fulcio CA 证书和 Rekor 实例地址配置到验证者的信任存储中。

2.7 信任模型对比:无密钥 vs 传统密钥

对比维度 传统密钥签名 Sigstore 无密钥签名
密钥管理 需要安全存储私钥 无需管理长期私钥
身份绑定 通过证书或密钥 ID 间接绑定 通过 OIDC 直接绑定真实身份
密钥泄露风险 高,泄露后影响所有历史签名 低,密钥短时且记录在日志中
审计能力 依赖签名者主动公开 强制公开到透明日志
入门门槛 需要 PKI 知识 只需 OIDC 账号

Sigstore 的无密钥签名模型将软件供应链安全从“密钥管理”转向“身份验证 + 透明审计”,大幅降低了安全实践的门槛,同时提供了更强的可审计性和抗抵赖性。