1. 镜像仓库的本质：内容分发 + 权限边界 + 审计中心
Registry 不只是“放镜像的地方”，它至少承担四个角色：
- 分发：把镜像层分发给构建与运行环境（pull）。
- 命名与组织：把镜像按团队/系统/环境组织（namespace）。
- 权限与策略：谁能 push、谁能 pull、能不能覆盖 tag、能不能删。
- 审计与保留：谁在什么时候推了什么 digest、是否被签名、是否被部署。
现实建议：把“生产可用镜像”的入口收敛到一个受控命名空间，并且默认只允许 CI 身份写入，禁止个人账号直接 push。
2. 组织与权限：命名空间是你的治理边界
一个好用的镜像仓库层级通常像这样：
- org：公司/组织级（统一策略与审计）。
- project：业务系统/微服务集合。
- repo：单个服务/组件。
- tags/digests：版本指针与内容地址。
图 1：Registry 的治理模型。命名空间是边界，写权限收敛到 CI 身份，prod 拉取需要更强的验证与策略。
3. 签名与验证：让“部署”变成“验证后部署”
供应链攻击最爱钻的空子是：你以为你部署的是你构建的东西，但中途有人替换了内容（或替换了 tag 指向）。 解决方法是：对 digest 签名，并在部署时验证签名与策略。
- 签名对象：image digest（不是 tag）。
- 签名来源：CI 身份（理想是短期凭证/OIDC）。
- 验证位置：部署前（CD/GitOps 控制器）与/或 集群入口（Admission）。
一句话：签名让“你说你是谁、你构建了什么”变成可验证事实；策略让“什么东西允许进生产”变成可执行规则。
图 2：签名与验证链路。把“可部署”升级为“验证后才可部署”，并用策略把规则固化为默认正确。
4. SBOM + provenance：把“里面有什么”和“怎么来的”都交代清楚
供应链安全常见两个问题：
- SBOM：镜像里到底带了哪些依赖？哪些组件有漏洞？
- Provenance：这个镜像是从哪个 commit、用哪个构建器、在什么环境里构建的？
当你把 SBOM 与 provenance 作为 attestation 绑定到镜像 digest 上，就形成了可审计的证据链：某次部署用的 digest， 能反查到其依赖清单、构建来源与签名者。
实战价值：当爆出某个高危 CVE，你可以快速回答：“哪些生产镜像包含它？是否被部署？部署在什么环境？能否阻断继续部署？”
图 3：SBOM + provenance 的可信交付链。把“里面有什么”和“怎么来的”绑定到 digest 上，部署时验证，出事时可快速定位与止损。
5. 最小落地清单（让镜像从“能用”变成“可信”）
- 命名空间治理：按 org/project/repo 组织；prod 镜像入口受控。
- 权限收敛：CI 身份 push；人类默认只读；break-glass 必须审计。
- 不可变策略：关键 tags 禁止覆盖；交付引用 digest。
- 签名与验证：对 digest 签名；部署前验证；策略即代码拒绝不合规制品。
- SBOM/Provenance：生成并绑定到 digest；建立漏洞响应与阻断机制。
你现在应该能回答：
1) Registry 的治理边界是什么？写权限收敛到谁？prod 拉取怎么控？
2) 为什么签名必须签 digest 而不是 tag？验证在哪里做最有效？
3) SBOM 与 provenance 各回答什么问题？如何用于漏洞响应与阻断发布？
1) Registry 的治理边界是什么？写权限收敛到谁？prod 拉取怎么控？
2) 为什么签名必须签 digest 而不是 tag？验证在哪里做最有效？
3) SBOM 与 provenance 各回答什么问题？如何用于漏洞响应与阻断发布？