登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  科技周边 >  业界新闻

OCI 镜像供应链如何核对来源、摘要和部署对象的一致性

来源:17golang原创

时间:2026-09-15 22:57:03 244浏览 收藏

核对 OCI 镜像供应链时,不能只看仓库名和版本标签。更可靠的做法是把“来源声明、registry 中的 manifest 摘要、目标平台选择出的摘要、Deployment 模板和 Pod 实际身份”串成一条证据链。tag 只是可移动的引用,sha256 digest 才是需要固定比较的内容身份;多架构镜像还要把 index 摘要和具体平台 manifest 摘要分开记录。

要点速览
  • 先记录完整镜像引用,再解析 index、平台 manifest、config 和 layers 的摘要。
  • Kubernetes 的 Deployment 要核对 PodTemplate,运行中的 Pod 还要核对实际 image ID。
  • 来源、摘要、平台和部署对象任一项不一致,都只能标记为待核查,不能用 tag 相同代替证明。

先把 OCI 镜像的身份链拆开

OCI Image Specification 把镜像描述为 manifest、可选的 image index、配置和文件系统层的组合。manifest 通过 descriptor 引用 config 与 layers,每个 descriptor 都带有 mediaType、size 和 digest。这个结构意味着“镜像名”只是入口,真正可复核的是被摘要锁定的内容对象。

建议发布记录至少保留下面几列:

对象要记录的字段核对目的
来源仓库、提交或构建流水线标识说明制品从哪里来
引用registry/repository:tag定位人类可读入口,但不作为最终身份
内容index 或 manifest 的 sha256 digest固定 registry 中的制品对象
平台os、architecture 与平台 manifest digest确认实际拉取的架构版本
部署Deployment image、Pod image ID确认集群最终运行的对象
OCI 镜像来源、tag、image index、平台 manifest、config、layers 和 sha256 摘要的关系说明图
图1:OCI 镜像身份链说明图,展示来源、索引、平台 manifest 与摘要的对应关系。

先判断你拿到的是 index 摘要还是平台摘要

同一个 tag 可能指向 image index。index 再按操作系统和 CPU 架构指向不同的 manifest。发布清单只保存 index digest,仍然不足以说明某台节点实际执行了哪一个平台对象;至少要把目标平台和平台 manifest digest 一起保存。

核对时按这个顺序做:第一步,记录完整引用,不要先把 tag 替换成自定义别名;第二步,读取 registry 返回的 media type,确认它是 index 还是单一 manifest;第三步,若是 index,按目标节点的 os/architecture 选择子 manifest;第四步,继续核对 config 和 layers 的摘要是否来自同一个 manifest。OCI 规范中的 digest 是内容寻址身份,不能把 config 的 DiffID 和 manifest 中的 layer digest 混成一个字段。

这里还要留意来源附件。OCI Image 1.1 引入了 subject 关系,Distribution 1.1 提供了按摘要查询 referrers 的路径。它适合挂接 SBOM、签名或其他制品,但附件存在不等于附件已经被当前部署流程验证;来源策略仍需由发布系统明确规定。

把摘要核对到 Deployment 和 Pod

Kubernetes 文档明确区分 tag 与 digest:tag 可以移动,digest 固定一份内容。生产清单可以保留 tag 便于阅读,但应同时写成带 digest 的引用,例如下面的 YAML。代码中的摘要是格式示例,不代表某个真实仓库的发布结果。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: checkout-api
spec:
  template:
    spec:
      containers:
        - name: api
          # tag 便于人读,digest 才是部署时固定的内容身份
          image: registry.example/checkout-api:2026.09@sha256:0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef
          # 明确拉取策略,避免把本地缓存误当成发布证据
          imagePullPolicy: IfNotPresent

实际检查要分两层。先看 Deployment 的 .spec.template.spec.containers[].image,确认模板已经更新;再看运行中 Pod 的状态字段和容器运行时记录,确认实际 image ID 与目标 digest 对得上。只看 Deployment 对象,可能漏掉旧 ReplicaSet 尚未完全退出;只看 Pod 名称,也可能漏掉不同架构节点选出的子 manifest。

registry 摘要、Kubernetes Deployment、PodTemplate、Pod image ID 和来源附件的一致性核对说明图
图2:部署一致性核对说明图,展示 Deployment、Pod 与 registry 摘要之间的证据链。

用四个断点快速定位不一致

  • tag 漂移:发布记录中的 tag 没变,但重新解析得到的 digest 变了。回到 registry 事件和构建回执,禁止用新摘要覆盖旧记录。
  • 架构分叉:index digest 一致,amd64 与 arm64 的平台 manifest 不同。比较平台字段和子 manifest,不要把这种差异误判为供应链篡改。
  • 模板未更新:registry 已有新 digest,但 Deployment 的 PodTemplate 仍引用旧对象。先改声明式配置,再观察 rollout 状态。
  • 实际对象不明:模板写了 digest,但 Pod 状态只有 tag 或本地运行时展示不完整。补采集 image ID、节点平台和拉取事件,不能仅凭镜像名结论。

最终清单可以收敛为四个判断:来源是否能追到构建输入;registry 摘要是否与发布回执一致;目标平台的 manifest 是否明确;Deployment 与 Pod 是否都指向同一内容身份。任何一项缺失都应标成“证据不足”,而不是把检查结果写成已验证。

常见问题

只有镜像 tag,没有 digest,还能证明部署一致吗?

不能。tag 可以被重新指向,最多证明配置写了同一个文字引用;要证明内容一致,必须保存解析出的 digest。

image index digest 和平台 manifest digest 应该保存哪个?

两者都保存。index 说明多架构入口,平台 manifest 说明目标节点实际选择的对象,二者用途不同。

有了 OCI referrers 就等于完成供应链验证吗?

不等于。referrers 只提供按 subject 组织附件的机制,是否检查签名、SBOM 或来源声明,仍由发布策略决定。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>