docker save 命令不支持直接导出带数字签名的镜像包，仅生成含镜像层和元数据的纯 tar 文件；如需签名，须先确保镜像已通过 Docker Content Trust 或 cosign 在 registry 中签名，再对导出的 tar 文件用 GPG 等工具手动签名。
Docker 原生的 docker save 命令不支持直接导出带数字签名的镜像包。它导出的是纯 tar 归档文件（含镜像层和元数据），但该过程本身不包含签名机制，也不会验证或嵌入任何密码学签名。
如果你需要“带数字签名的镜像包”，实际要分两步走：
✅ 先确保镜像是已签名的镜像（即在推送前用 Docker Content Trust 签署过）；
✅ 再导出时单独对 tar 文件进行外部签名（如用 GPG），并配套分发签名文件。
一、前提：镜像必须已启用内容信任（DCT）并签名
Docker 的数字签名能力依赖于 Docker Content Trust（DCT），它基于 The Update Framework（TUF），只作用于 远程 registry（如 Docker Hub、Harbor）上的镜像拉取/推送环节，不延伸到本地 save/load 流程。
操作步骤：
- 启用 DCT：
export DOCKER_CONTENT_TRUST=1
- 推送时自动签名（需有 root key 和 repo key）：
docker push my-registry.io/myapp:1.0
✅ 此时
my-registry.io/myapp:1.0在 registry 中是已签名状态。
❌ 但docker save my-registry.io/myapp:1.0 -o app.tar导出的app.tar不包含签名信息，只是原始镜像数据。
二、导出后手动签名 tar 文件（推荐做法）
这是目前最实用、可验证的方式：
- 用
gpg对导出的 tar 文件签名：docker save -o app.tar my-registry.io/myapp:1.0 gpg --detach-sign --armor app.tar # 生成 app.tar.asc
- 分发时同时提供
app.tar和app.tar.asc； - 接收方用公钥验证：
gpg --verify app.tar.asc app.tar
⚠️ 注意：这种签名保护的是 tar 文件完整性与来源可信性，不是 Docker 镜像本身的 TUF 签名。两者层级不同，但可互补。
三、替代方案：用 cosign 签名 OCI 镜像（更现代）
如果你使用的是支持 OCI 的 registry（如 GitHub Container Registry、Harbor v2.8+、ECR），推荐用 cosign 对镜像做独立签名（非 DCT）：
- 签名已推送到 registry 的镜像：
cosign sign --key cosign.key my-registry.io/myapp@sha256:abc123
- 拉取签名 + 验证（无需导出）：
cosign verify --key cosign.pub my-registry.io/myapp@sha256:abc123
- 若仍需离线分发：可配合
oras或skopeo导出带签名的 OCI bundle（非标准 Docker tar），但需目标环境支持 OCI 解析。
小结对比
| 方式 | 是否原生支持 docker save 带签名 |
是否可验证 | 适用场景 |
|---|---|---|---|
docker save 直接导出 |
❌ 不支持 | — | 仅基础迁移，无安全要求 |
| GPG 签名 tar 文件 | ✅ 手动追加 | ✅ 是（文件级） | 离线交付、内部审计、简单可信分发 |
| Docker Content Trust（DCT） | ❌ 仅作用于 push/pull registry | ✅ 是（镜像 tag 级） | 联网环境，依赖 Docker 官方信任链 |
cosign + OCI registry |
❌ 需先 push 到支持 OCI 的 registry | ✅ 是（细粒度、SHA256 绑定） | 云原生流水线、零信任架构、K8s 生态 |
不复杂但容易忽略：签名本身不加密内容，只保证「没被篡改」和「来自谁」——关键还是密钥管理和分发渠道可信。
