防篡改的核心是建立可验证的信任链，而非简单加锁；通过docker content trust（基于notary协议）实现构建、推送、拉取、运行全链路签名验证，配合harbor策略管控、固定digest引用及运行时opa校验，确保完整性与来源可信。
防篡改的核心是确保镜像从构建、推送、拉取到运行全过程的完整性与来源可信。关键不在于“加锁”，而在于建立可验证的信任链。
启用内容信任（Docker Content Trust）
这是 Docker 原生支持的签名机制，基于 Notary 协议实现：
- 构建并推送前，需设置环境变量 DCT_ENABLED=true，并配置签名密钥（首次会自动生成）
- 执行 docker push my-registry/myapp:1.2.0 时，Docker 自动对镜像 manifest 签名并上传签名元数据
- 拉取时默认校验签名；若未开启信任，docker pull 会失败（除非显式加 --disable-content-trust=false）
- 生产环境建议在 CI 流水线中强制开启，并将私钥交由密钥管理服务（如 HashiCorp Vault）托管，避免硬编码
使用 Harbor 的 Notary 集成签名
企业级私有仓库通常用 Harbor 替代原生 DCT，提供更细粒度控制：
- 在 Harbor UI 中启用“Content Trust”并配置 Notary 服务
- 设置策略：例如要求所有 prod 项目下的镜像必须签名，否则禁止推送
- 配合漏洞扫描（Clair）联动：高危漏洞（CVSS≥7.0）镜像即使签名也自动阻断上线
- 签名状态可在 Harbor 界面直接查看，支持按签名者、时间、是否过期筛选
固定镜像 digest，杜绝 tag 漂移
tag（如 :latest 或 :v2.1）本质是可变指针，易被覆盖重写，无法防篡改；而 digest 是镜像 manifest 的 SHA256 哈希值，不可变：
- 构建后立即记录完整 digest：sha256:6a5f1c5d19...
- Dockerfile 中写死引用：FROM registry.example.com/base:1.0@sha256:6a5f1c5d19...
- Kubernetes Deployment 中也应使用 digest 而非 tag，避免因 tag 被覆盖导致意外部署旧版或恶意镜像
- CI 流水线可自动提取 digest 并注入 Helm values 或 K8s YAML，确保部署一致性
运行时校验（可选增强）
在容器启动前做二次确认，适合高安全等级场景：
- 在 entrypoint 脚本中调用 skopeo inspect 获取远端 registry 中该 digest 对应的 manifest，并比对本地镜像 ID
- 结合 OPA（Open Policy Agent）编写策略：拒绝运行未签名、或签名者不在白名单中的镜像
- 注意：此方式增加启动延迟，一般用于金融、政务等强合规环境，非必需
