容器镜像签名需确保完整性与来源可信，全程贯穿构建至部署；推荐用OIDC自动签发短期证书（如GitHub Actions+Flucio），绑定SLSA Provenance、SBOM等元数据，并通过Webhook或CI前置验证，密钥分级隔离轮换。
容器镜像签名不是加个标签就完事，而是用密码学把“谁构建的”“内容有没有改过”这两件事钉死在每个环节。核心就两点：完整性 + 来源可信。只要签名验证贯穿构建、推送、拉取、部署全流程，攻击者就很难在中间替换或污染镜像。
签名必须绑定真实构建身份
别再用本地生成的长期私钥签名。生产环境推荐用 OIDC 身份自动签发短期证书，比如 GitHub Actions 运行时向 Fulcio 申请证书，cosign 直接用它签名。这样每次构建都有唯一、有时效、可审计的身份凭证，避免密钥泄露后被长期滥用。
- GitHub Actions 中只需加一行：
cosign sign --oidc-issuer https://token.actions.githubusercontent.com --oidc-audience sigstore --yes $IMAGE - 验证时不用分发公钥，直接信任 Fulcio 根证书即可：
cosign verify --certificate-oidc-issuer https://token.actions.githubusercontent.com $IMAGE - 签名自动带 SLSA Provenance 元数据，清楚记录触发流水线的仓库、分支、提交 SHA 和构建时间
签名要和 SBOM、证明文件一起存
光有签名还不够，得知道镜像里到底有什么、是怎么来的。SBOM（软件物料清单）列出所有依赖组件和许可证；Provenance（出处声明）说明是谁、在哪、怎么构建的。它们都以标准格式（如 spdx-json、slsa-generic）作为附加 artifact 推送到同一镜像仓库路径，比如：sha256-abc123.sbom、sha256-abc123.att。
- 用 Trivy 一键生成 SBOM：
trivy image --format spdx-json --output sbom.json myapp:v1 - 用 cosign attach 把 SBOM 和证明文件推上去：
cosign attach sbom --sbom sbom.json $IMAGE - 下游扫描工具或策略引擎能自动关联并检查：某个漏洞组件一曝光，立刻定位受影响的所有镜像
验证必须前置到部署入口
签名没被验证就等于没签。不能靠开发人员手动执行 cosign verify，而要把验证逻辑嵌入基础设施层。
- Kubernetes 集群启用 Validating Admission Webhook，比如 Connaisseur 或 cosign-webhook，Pod 创建前自动校验镜像签名
- CI 流水线中，在
docker pull后立即跑cosign verify，失败则终止整个发布流程 - Quay 等企业仓库开启“信任模式”，未签名镜像连 push 都被拒绝，从源头卡住不合规制品
密钥与策略要分级、隔离、可轮换
不同环境必须用不同签名密钥，dev/staging/prod 绝对不能混用。根密钥离线保管，targets 密钥按仓库或服务粒度分发，定期轮换（建议 90 天），并接入日志系统监控签名失败事件。
- Quay 仓库级信任开关控制是否允许签名操作，实现细粒度权限收敛
- Docker Content Trust 可配置多级密钥：root（离线）、repository（每个仓库独立）、snapshot（快照一致性）
- 用 Kyverno 编写策略，强制要求镜像必须含有效 SBOM 和 Provenance，并由指定 OIDC 发行方签发
