校验解决的是「执行的到底是哪份内容」
剧本在执行时通常经过多个环节：从仓库取出、经流水线处理、被推送到执行节点、再被解释执行。链条越长，越难保证最终执行的内容与审核通过的内容一致——中间任何一环被替换或改动，结果都不会体现在命令输出里。签名与校验的作用就是给这条链条加上可验证的锚点：用签名证明来源，用摘要证明内容未变，两者叠加才能回答「执行的这一段内容，是不是我批准的那一段」。
基本信息
| 适用对象 | 剧本文件、制品包、容器镜像与流水线产物 |
|---|---|
| 两类手段 | 签名证明来源可信，摘要证明内容未变 |
| 校验时机 | 使用前校验，而不是下载后长期信任 |
| 密钥要求 | 签名私钥与验证公钥分开管理，私钥严格受限 |
| 配套要求 | 校验失败必须中止，不能降级继续执行 |
落地要点
- 来源签名：对发布标签或提交做签名，执行端验证签名后再取用
- 内容摘要：对制品计算摘要并固定记录，使用前重新计算比对
- 镜像固定：按摘要而非标签引用镜像，标签可被重新指向而摘要不会
- 产物证明：流水线生成的制品附带构建来源信息，便于追溯由谁在何时构建
- 校验时机前置：在任何执行动作之前完成校验，避免边执行边校验
- 失败即中止：校验不通过时终止流程并告警，不允许人工跳过继续
校验操作示例
校验操作示例
git tag -v v1.4.2 # 验证标签签名是否有效
git log --show-signature -1 # 查看最近提交的签名信息
gpg --verify site.tar.gz.asc site.tar.gz # 校验制品签名与内容摘要
sha256sum -c site.tar.gz.sha256 # 按摘要文件校验
skopeo inspect docker://registry.example.com/app@sha256:... # 按摘要引用镜像
sha256sum playbook.yml > playbook.yml.sha256 && sha256sum -c playbook.yml.sha256 # 内容未变验证手段与防护对象
| 手段 | 防的是什么 | 局限 |
|---|---|---|
| 标签或提交签名 | 来源被冒充与内容被替换 | 需验证公钥可信且分发正确 |
| 内容摘要比对 | 传输或存储中被改动 | 摘要本身若同源被改则失效 |
| 按摘要引用镜像 | 标签被重新指向其他内容 | 摘要更新流程需配套 |
| 构建来源证明 | 产物与源码不对应 | 依赖构建环境本身可信 |
签名与摘要要防止「同源替换」：如果待校验的内容和它的摘要、公钥都放在同一处且可被一起改写，校验会全部通过。校验所需的可信信息应从独立渠道获取，这是整套机制成立的前提。
在执行端做校验比在流水线里做更值得投入：流水线的校验只保证进入流水线的内容正确，执行端的校验才能保证真正运行的内容正确，两者都做才是完整覆盖。