Sigstore 无密钥签名怎样降低构建凭据管理成本

Sigstore 无密钥签名真正降低的，不是“所有签名工作都消失了”，而是把长期私钥的分发、备份、轮换和泄露处置，改成一次构建使用的身份认证、临时密钥和可追溯记录。构建任务仍然要被授权，发布侧仍然要验证签名者身份，团队也仍然要维护 OIDC、信任根和异常处置策略。

我在看这类方案时，最容易把“没有手工管理私钥”误解成“没有凭据”。更准确的说法是：Cosign 在内存中生成临时密钥对，Fulcio 根据 OIDC 身份把临时公钥绑定到短期证书，签名事件再进入 Rekor 透明日志。验证方依靠签名、证书、身份约束和日志材料共同判断，而不是相信构建任务自己写的一行成功日志。

Sigstore 官方地址：https://www.sigstore.dev/

Sigstore 官方文档：https://docs.sigstore.dev/

先把长期私钥的成本拆开

传统签名方案常见的固定动作是生成一把长期私钥，把它安全地放入 CI，给不同流水线配置访问权限，再准备公钥分发、轮换、备份和撤销流程。项目少时，这些工作可能只占一个人的几个小时；当仓库、环境和发布团队增加后，真正昂贵的是每次变更都要确认“旧密钥还在哪里”“谁还能读取”“回滚时验证方信任哪个版本”。

Keyless 方案把成本从密钥生命周期转移到身份和记录生命周期：构建任务需要拿到受控的 OIDC 身份，签名过程使用一次性的密钥材料，Fulcio 颁发短期证书，Rekor 留下透明日志记录。这样可以减少长期私钥落盘和跨环境复制，但不会自动解决工作流权限过宽、身份提供方被攻破或验证策略写错等问题。

所以，标题中的“降低成本”应理解为减少长期秘密的操作面，而不是减少安全控制。团队越依赖自动化构建、越需要让多个消费者独立验证，身份和透明日志带来的统一记录越有价值。

身份、临时密钥、短期证书怎样连成一条记录

一条 keyless 签名可以按四个对象理解。第一是 OIDC 身份，它回答“这次构建以哪个身份运行”；第二是只在签名过程使用的临时密钥，它回答“哪个公钥实际签了制品”；第三是 Fulcio 短期证书，它把临时公钥和身份绑定起来；第四是 Rekor 中的透明日志记录，它为签名材料和时间提供可追溯的公共记录。

Fulcio 官方说明中，证书基于 OIDC 身份签发，并且是短期有效的 X.509 证书。Cosign 的快速入门还说明，签名方需要用 Bundle 保存证书、签名和日志包含证明；验证时不能只拿一个字符串形式的“签名成功”，而要把制品、Bundle 和预期身份一起交给验证命令。

这里有一个重要的时间边界：短期证书过期后，验证方仍要依靠签名时的可信时间判断它当时是否有效。Sigstore 文档将 Rekor 纳入时间证明路径，也说明客户端可以使用时间戳机构提供的签名时间。换句话说，签名材料和时间材料应一起保存，不能只保留一个短期证书文件。

构建侧签名，发布侧独立验证

落地时我会把“签名动作”和“放行判断”拆成两个职责。构建侧只对已经确定的制品摘要申请身份并生成签名；发布或部署侧读取同一个摘要、Bundle 和组织策略，明确限制证书身份与 OIDC 签发者。验证器不能从待验证证书里抄出身份，再把抄来的值当成预期身份。

下面的命令展示的是接入形状，不包含真实生产身份、令牌或仓库值。它表达的重点是：签名用构建阶段已有的制品引用，验证用发布阶段预先配置的身份条件。

# 使用构建阶段已经确定的制品摘要，避免重新解析可变标签
: "${IMAGE_REF:?请提供带摘要的制品引用}"
cosign sign "$IMAGE_REF"

# 发布侧的身份条件来自受控配置，不从待验证材料中临时推导
: "${EXPECTED_IDENTITY:?请提供预期工作流身份}"
: "${EXPECTED_ISSUER:?请提供预期 OIDC 签发者}"
if ! cosign verify "$IMAGE_REF" \
  --certificate-identity "$EXPECTED_IDENTITY" \
  --certificate-oidc-issuer "$EXPECTED_ISSUER"; then
  # 验证失败就停止放行，并把摘要与失败原因写入发布记录
  printf '%s\n' '签名身份或透明日志验证未通过' >&2
  exit 1
fi

这套分工的成本收益很直接：构建环境不必长期保存一把可跨项目复用的私钥，发布环境也不必把所有签名公钥人工复制到每个节点。但策略文件、验证工具、信任根和审计记录变得更重要，尤其是需要明确“哪个仓库、哪条工作流、哪个 OIDC 签发者有权发布”。

透明日志带来的价值，不等于自动放行

Rekor 的价值是让签名事件留下可查询、可审计的透明记录。它帮助验证方确认材料是否被记录、签名时点如何与短期证书对应，也让组织可以监控不应该出现的身份或工作流。日志本身不是业务授权策略，不能替代“这个身份是否有权发布到这个环境”的判断。

因此，发布记录至少应该同时保存制品摘要、签名方式、预期证书身份、OIDC 签发者、Bundle 位置、策略版本、验证工具版本和最终判定。不要保存私钥或原始身份令牌；也不要只保存一个“verify passed”，否则未来无法解释当时验证的对象和策略。

如果团队还需要 SBOM、SLSA 来源证明或其他 attestation，也应把它们当作不同类型的材料分别验证。签名回答“对象和身份是否匹配”，来源证明回答“它由什么构建过程产生”，两者不能互相替代。

失败、服务不可达与回滚怎么处理

Keyless 方案把一些长期密钥问题变成了更容易观察、但必须提前定义的运行边界。下面这张表适合放进发布故障手册：

回滚时应回到明确的旧摘要，再按同一验证策略重新判断。短期证书并不意味着旧制品永远无法验证，关键在于保存了完整 Bundle 和可信时间材料；如果组织改变了身份命名或信任根，也要把策略迁移作为一次有记录的变更，而不是在故障窗口里临时关闭门禁。

到底省下了什么成本，适合哪些团队

如果团队只有一个离线项目、密钥托管已经成熟、发布频率很低，那么迁移到 keyless 的直接收益可能有限。相反，多个仓库共用 CI、构建环境经常弹性创建、需要让下游团队自行验证，或经常因为密钥轮换而改发布配置时，减少长期密钥分发通常更有吸引力。

我的判断是，Sigstore 无密钥签名最适合被当成“构建身份治理的一部分”引入，而不是孤立的签名命令。先固定制品摘要和验证策略，再接入 OIDC、Fulcio、Rekor 与 Bundle 保存，最后把验证结果接入发布门禁。这样省下的是长期秘密的运维复杂度，换来的则是对身份、时间和透明记录更明确的依赖。

无密钥签名是不是完全没有私钥

不是。Cosign 会在签名过程中使用临时密钥，关键区别是它不要求团队长期保存和分发一把可复用的私钥。

只验证签名是否足够

不够。还要验证制品对象、证书身份、OIDC 签发者、信任根和透明日志或 Bundle；漏洞、来源证明和策略合规也需要其他控制。

OIDC 账户被盗后会怎样

攻击者可能获得签发身份，组织应依靠最小权限、工作流约束、透明日志监控和快速处置发现异常。Keyless 缩小了长期密钥的影响面，但不会让身份提供方风险消失。

没有长期私钥还需要保存什么

至少保存制品摘要、签名 Bundle、预期身份和签发者、验证策略版本、信任根来源以及验证结果。不要把身份令牌或私钥写进发布记录。

参考资料：https://docs.sigstore.dev/cosign/signing/overview/、https://docs.sigstore.dev/quickstart/quickstart-cosign/、https://docs.sigstore.dev/certificate_authority/overview/、https://docs.sigstore.dev/about/security/、https://docs.sigstore.dev/cosign/verifying/verify/。