Sigstore Cosign 怎样验证容器镜像签名

Cosign 验证容器镜像签名，关键不是只看命令有没有返回成功，而是先固定镜像摘要，再根据签名来源核对公钥或证书身份，最后判断签名载荷中的 claims 是否指向同一个镜像。这样可以把“没有签名”“签名对应了另一个摘要”和“签名者身份不符合策略”分开处理。

官方文档：https://docs.sigstore.dev/cosign/verifying/verify/

本文只讲验证，不展开签名发布和镜像构建。Cosign 官方文档给出的通用形式是 cosign verify [--key ...] ；keyless 验证还要显式提供证书身份和 OIDC 发行者。

先分清验证对象与信任模型

容器标签是便于阅读的入口，但它可能在下一次发布后指向不同内容。签名载荷通常包含镜像的 manifest digest，Cosign 默认会把这个摘要与当前验证对象对照。因此，发布流程或准入策略应优先处理不可变摘要，而不是只记录一个浮动标签。

验证还要回答“信任谁”。如果签名使用本地公钥，就由 --key 指定公钥；如果使用 Sigstore 的 keyless 模式，就要把证书中的身份与 OIDC issuer 写进约束。透明日志、签名载荷和证书不是同一个东西：前者提供可追溯的日志信息，后两者分别承载签名与身份线索。

固定镜像摘要后执行基础验证

先把仓库中的镜像解析为明确的摘要，再把这个引用交给验证命令。下面的地址是示例占位符，读者应替换为自己有权限访问的仓库对象；命令只展示调用关系，不表示本文已经连接该仓库。

# 使用不可变摘要，避免标签漂移改变验证对象
IMAGE_REF="registry.example.com/team/app@sha256:替换为镜像摘要"

# 让 Cosign 检查签名、载荷 claims 与镜像摘要的对应关系
cosign verify "${IMAGE_REF}"

如果镜像采用 keyless 签名，基础命令可能还需要身份约束；如果采用自管理密钥，则要改成带公钥的形式。不要把“仓库能拉到镜像”当成“镜像已通过签名验证”，这两个检查解决的是不同问题。

为 keyless 验证补齐身份与发行者

keyless 验证的重点是证书身份和 OIDC issuer 成对出现。身份可以是签名工作流的邮箱或工作负载标识，issuer 则说明这个身份由哪个 OIDC 提供方声明。只填身份、不限制发行者，会让策略表达得不完整。

# 固定待验证的镜像摘要，避免验证对象随标签变化
IMAGE_REF="registry.example.com/team/app@sha256:替换为镜像摘要"

# 两个条件同时约束签名证书：身份和 OIDC 发行者
cosign verify "${IMAGE_REF}" \
  --certificate-identity="release@example.com" \
  --certificate-oidc-issuer="https://issuer.example.com"

真实策略应使用组织已经确认的身份模式，并把 issuer、仓库、工作流或项目边界写入配置记录。不要因为命令能跑通，就把示例身份直接复制到生产准入规则里。

用本地公钥、claims 和结果信息排查失败

自管理密钥的场景可以使用签名方提供的公钥。这里的公钥文件应通过组织自己的分发和轮换机制取得；文章不提供任何真实密钥，也不建议从不明来源下载。

# 指向经过组织分发和固定的公钥文件
PUBLIC_KEY="./trusted-cosign.pub"
IMAGE_REF="registry.example.com/team/app@sha256:替换为镜像摘要"

# 用指定公钥验证该摘要对应的签名
cosign verify --key "${PUBLIC_KEY}" "${IMAGE_REF}"

排查时可以按下面的边界看返回信息：

如果需要验证镜像上的构建证明，Cosign 还提供 cosign verify-attestation；它检查的是 attestation，不应与普通镜像签名验证混为一谈。生产系统可以把两类结果分别记录，避免只留一个模糊的“校验通过”字段。

常见疑问

为什么推荐摘要而不是标签？摘要能把验证对象固定下来，标签更像一个会移动的名称。准入、发布记录和回滚清单都应尽量保存摘要。

keyless 验证是否等于不需要信任配置？不是。它把信任材料从长期私钥转为证书身份、OIDC issuer、签名载荷和透明日志等约束，策略仍需明确写出允许谁签名。

能否只用 --check-claims=false 解决失败？该参数会跳过 claims 校验，只适用于你明确知道载荷格式不符合默认约定的场景；它不是摘要不一致或身份不匹配的通用修复。

最终可以把验证流程压缩成一句话：先锁定镜像摘要，再选定公钥或 keyless 身份模型，最后按失败信息回到签名对象、claims 和信任根逐项定位。