OCI 镜像签名怎样接入供应链发布流程

OCI 镜像签名接入发布流程，关键是固定镜像摘要、保存可验证的签名材料，并在独立的发布或部署节点按预期身份执行验证。签名任务显示成功，只说明签名动作完成，不能代替“这个制品符合本次发布策略”的判断。

OCI 在 2024 年发布 Image 与 Distribution 1.1 时，将关联制品的表达和发现纳入规范：subject、artifactType 与 referrers API 为签名、证明等元数据提供共同的关联方式。这是已有规范背景，不是本文宣称的新发布事件。对交付团队而言，真正要落地的是镜像、关联材料和验证策略能够一起进入发布链路。

OCI 官方地址：https://opencontainers.org/

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

为什么镜像已经签名，发布仍然不能放行

设想构建流水线签了一个 release 标签，部署侧稍后再按同名标签拉取。若标签指向的对象发生变化，两边看到的就不一定是同一个制品。另一个常见问题是只确认“存在签名”，却没有限制谁有资格签名。

先沿三个问题定位：待验证对象是哪一个摘要，关联材料能否读取，签名身份是否符合策略。不要从关闭检查开始排错。签名能证明的内容取决于签名对象和信任配置；它本身不证明镜像没有漏洞，也不能证明构建过程满足所有组织要求。

固定摘要与签名材料

构建并推送镜像后，从构建工具或注册表结果取得实际摘要，将完整的 仓库地址@sha256:摘要 写入发布记录。后续签名、验证和部署都引用它。摘要是内容标识；标签可以保留作为人类可读名称，但不应让各节点分别再次解析一个可变标签。

使用 keyless 签名时，需要考虑 OIDC 身份、证书、信任根和预期签发者。使用自管密钥时，则需要可信公钥来源和密钥使用权限。两种方式都不能把“签名者自己临时提供的任意信任材料”直接当成组织信任策略。

签名、SBOM 和构建来源证明也要区分：签名负责把对象和签名者关联；SBOM 描述组成；来源证明描述特定构建信息。保存了某种附件，不等于已经验证其内容或满足业务要求。若策略要求后两者，应给它们单独的类型与验证规则。

把签名和放行放在不同节点

构建侧生成制品，签名任务对确定摘要生成签名；发布记录保存摘要和相关定位信息；独立验证器读取策略配置并验证，部署引用再使用被放行的摘要。这里的独立是职责和权限分离，不一定要求另一套平台。

验证器应知道预期的仓库、工作流或签名身份以及对应的 OIDC 签发者，而不是从待验证材料中复制一个身份再当作期望值。否则任何能完成某种签名的人，都可能被当成合法发布者。

以下是 keyless 方式的命令形状。变量必须来自当前流水线配置与真实构建输出；本文不提供可直接指向生产环境的值，也没有执行签名或验证。

# 镜像引用必须是已取得的实际仓库地址与摘要，不要重新解析可变标签
: "${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

签名节点需要自己的授权机制和注册表写权限；验证节点需要读取镜像及关联材料，并使用受信任的工具和信任配置。CI 的 OIDC 签发者应以实际平台为准，不能把交互登录的身份提供方地址套到工作流身份上。代码中的停止行为只是门禁示例，完整发布步骤还应把验证成功与后续部署条件正确连接。

注册表复制后，为什么又找不到签名

跨注册表提升镜像时，仅复制镜像内容可能遗漏关联材料。应确认复制工具是否支持所用附件形式、目标注册表能否保存和发现这些材料，以及消费者使用的 Cosign 版本与格式是否兼容。当前 Cosign 文档描述使用 OCI 1.1 referrers 关联签名；历史工具链可能有不同存储约定，不能只看注册表里镜像标签存在就推断迁移完成。

在目标环境验证实际部署引用。如果迁移或重新打包改变了摘要，应按新的制品对象处理，不能把旧摘要的成功记录直接搬过去。多平台镜像还应写清策略签的是镜像索引还是平台子清单；不要把对子对象的验证自动解释为整个发布集合都已验证。

失败、回滚与记录如何收尾

发布记录宜包含镜像摘要、签名方式、期望身份或公钥标识、策略版本、验证工具版本和判定结果。记录不得包含私钥或身份令牌。保留这些字段，是为了以后解释“当时依据什么放行”，而不是让一条成功日志永久替代部署时的策略。

回滚应回到明确的旧摘要，并按当前流程处理相关材料，不是简单把标签指回去就跳过验证。若依赖服务不可达，区分验证失败与无法完成验证；发布流程应采用事先确定的处置规则，不能在故障时临时取消身份约束。

有签名是否意味着镜像安全

不能这样推断。签名验证回答对象与身份的关联，漏洞、恶意行为和配置风险需要相应的其他控制。

能否只在 CI 验一次

取决于部署链路能否保证对象和放行记录不被替换。多团队、多注册表或动态部署环境通常需要在更接近实际使用的位置核对摘要和策略。

参考：OCI 1.1 关联制品规范背景；Cosign 容器签名；Cosign 签名验证。