Docker镜像签名通过数字签名绑定镜像与发布者身份，启用DCT或cosign实现来源可信与内容防篡改，需在CI/CD、Kubernetes及运行时强制校验，并配合密钥轮换与监控形成持续验证链。
通过 Docker 镜像签名，可以验证镜像来源可信、内容未被篡改，是保障容器生产环境安全的关键实践。核心在于用数字签名绑定镜像与发布者身份，运行前强制校验签名有效性。
启用 Docker Content Trust（DCT）
Docker 原生支持的签名机制，基于 Notary 项目实现。启用后，所有 docker push 和 docker pull 操作默认走签名流程。
- 开启方式：设置环境变量
export DOCKER_CONTENT_TRUST=1（Linux/macOS），或在 Windows PowerShell 中运行$env:DOCKER_CONTENT_TRUST=1 - 首次推送时会自动生成根密钥和仓库级签名密钥，私钥默认存于
~/.docker/trust/private，务必备份并严格保护 - 团队协作时，建议使用独立的离线根密钥，并通过
notaryCLI 分发信任根，避免单点泄露风险
使用可信证书机构签发的签名密钥
默认 DCT 使用本地生成的密钥，适合开发测试；生产环境应对接企业 PKI 或可信 CA，提升密钥可信度和吊销能力。
- 可将 Notary 服务后端替换为支持 TLS 客户端证书认证的私有部署实例
- 用
cosign（Sigstore 生态）替代 DCT，直接绑定 OIDC 身份（如 GitHub Actions、Azure AD），实现“谁构建、谁签名、自动审计” - 签名时附加 SLSA 级别声明或 SBOM（软件物料清单），增强供应链透明度
在 CI/CD 和集群中强制校验签名
签名本身无意义，关键在于消费端严格执行验证策略。
- CI 流水线中，在
docker pull前检查notary list <repo></repo>是否存在有效签名；失败则中断部署 - Kubernetes 中，通过
ImagePolicyWebhook或 OPA/Gatekeeper 策略拦截未签名或签名失效的镜像拉取请求 - 运行时工具如
dockerd可配置--signature-verification（需配合 dockerd 20.10+ 和 trust store）
定期轮换密钥并监控签名状态
长期使用同一密钥会放大泄露后果，需建立密钥生命周期管理机制。
- 为不同环境（dev/staging/prod）分配独立签名密钥，禁止跨环境复用
- 设定密钥有效期（如 90 天），到期前自动触发轮换流程，并同步更新集群信任列表
- 接入日志系统，采集
notary或cosign verify的失败事件，对“签名过期”“证书不可信”“哈希不匹配”等告警
镜像签名不是一次性配置，而是贯穿构建、分发、部署、运行的持续验证链。重点不在技术多复杂，而在每个环节是否真正拒绝了未经验证的镜像。
