Docker镜像签名（Content Trust）通过密码学签名实现构建、推送、拉取、部署、运行五阶段全链路验证，强制签名准入、密钥分级管控、策略前置拦截及透明日志审计，满足NIST SP 800-190A与等保2.0三级合规要求。
通过Docker镜像签名（Content Trust）确保供应链安全合规，核心在于把“信任”从环境或流程中抽离出来，固化为密码学可验证的声明，并在每个关键环节强制执行验证。它不是一次配置，而是构建、推送、拉取、部署、运行五阶段全链路的策略闭环。
构建与推送阶段：强制签名即准入
启用 DOCKER_CONTENT_TRUST=1 后，docker push 会自动触发签名流程。首次推送时生成根密钥（离线保管）和 targets 密钥（用于签署具体标签），所有镜像必须经 targets 密钥签名才允许入库。未签名或签名密钥不匹配的镜像会被 registry 拒绝，返回 HTTP 403 错误——这已成为 Docker 27+ 默认行为，也是 NIST SP 800-190A 和等保2.0三级的硬性准入红线。
- 生产环境应禁用本地自动生成密钥，改用企业 PKI 或 Fulcio OIDC 签发短期证书，绑定 CI 身份（如 GitHub Actions 工作流）
- 推送前需同步附加 SBOM（CycloneDX 格式）和 SLSA Provenance 声明，使用
oras attach存入同一仓库路径，满足监管对“交付物可追溯”的要求 - 不同环境（dev/staging/prod）使用独立 targets 密钥，禁止跨环境复用，避免测试密钥泄露波及生产
拉取与部署阶段：拒绝未验证即生效
客户端启用 DCT 后，docker pull 不再只是下载镜像，而是自动校验签名有效性、时间戳、密钥 ID 及证书链完整性。若签名过期、被吊销、哈希不匹配或签发者不在信任列表中，命令直接失败并返回 exit code 1。
- Kubernetes 中须集成 ImagePolicyWebhook 或 cosign-webhook admission controller，在 Pod 创建前拦截未签名/签名失效镜像
- CI 流水线应在
docker pull后立即执行cosign verify或notary list，失败则终止部署，不可跳过 - 避免仅靠
docker run --signature-verification这类运行时开关，它依赖 dockerd 版本且易被绕过；策略必须前置到调度层
密钥与策略管理：建立可持续的信任锚点
DCT 的信任模型基于 TUF（The Update Framework），其安全性取决于密钥生命周期是否受控。根密钥一旦泄露，整个仓库信任即崩塌；targets 密钥若长期不轮换，则攻击窗口持续扩大。
- 根密钥必须离线生成、离线存储（如 HSM 或加密 USB），仅在初始化或轮换时短暂接入
- targets 密钥设定 90 天有效期，到期前由自动化脚本触发轮换，并同步更新集群信任配置（如 Kubernetes ConfigMap 中的公钥）
- 定义细粒度策略：例如仅允许
acme.io/app:prod-*标签且由prod-signer@acme.io签署，通过正则匹配 + OIDC 主体约束双重校验
审计与追溯：让每一次签名可验证、不可抵赖
签名本身不等于合规，只有被记录、被监控、被回溯，才能通过等保测评和金融行业穿透式审计。
- 所有签名操作必须写入 Sigstore Rekor 透明日志，提供全局唯一、防篡改的签名事件存证
- 采集
cosign verify失败日志，对 “certificate expired”、“key not in trust store”、“digest mismatch” 分类告警 - 将签名状态与 CMDB 关联，实现“某镜像版本 → 签名者 → CI 流水线 → SBOM → CVE 扫描报告”的一键下钻
