启用签名验证是防范容器供应链攻击最有效的手段，需强制开启Docker内容信任（DCT）或使用Cosign实现细粒度签名与验证，并在仓库、Kubernetes准入层及运行时叠加策略控制，同时严格管理密钥生命周期。
直接启用签名验证是防范容器供应链攻击最有效的手段。它不是锦上添花的加固项，而是阻止恶意镜像进入生产环境的第一道、也是最关键的防线。
强制启用内容信任（DCT）
这是最基础也最易落地的一步。Docker默认不校验签名，必须显式开启：
- 全局启用：运行 export DOCKER_CONTENT_TRUST=1，此后所有 docker pull 和 docker push 都将只处理已签名镜像；未签名则直接失败，不会静默拉取
- 永久生效：将该变量写入 /etc/environment 或用户 shell 配置文件，避免每次手动设置
- 验证是否生效：执行 echo $DOCKER_CONTENT_TRUST，输出应为 1；也可用 Docker Bench for Security 工具自动检查（对应检查项 4.5）
使用 Cosign 实现细粒度签名与验证
Docker Content Trust 基于 Notary v1，而 Cosign 是当前更轻量、更开放、更适配 OCI 生态的主流选择：
- 对本地镜像签名：运行 cosign sign --key cosign.key registry.example.com/app:v1.2.0，签名会自动上传至兼容 OCI 的仓库（如 GHCR、Harbor 2.8+）
- 拉取前强制验证：在 CI/CD 流水线或集群准入环节执行 cosign verify --key cosign.pub registry.example.com/app:v1.2.0，返回非零码即中断流程
- 绑定身份凭证：支持 OIDC 身份校验，例如验证 GitHub Actions 签发的证书：cosign verify --certificate-oidc-issuer https://token.actions.githubusercontent.com --certificate-identity-regexp 'ci@acme.com'
构建可信分发与运行时拦截双保险
仅靠客户端验证存在绕过风险，需在基础设施层叠加策略控制：
- 私有仓库侧：在 Harbor 中配置“签名策略”，拒绝未签名或签名失效的镜像推送；同时启用透明日志（如 Rekor），记录所有签名行为供审计
- Kubernetes 准入控制：用 Kyverno 或 OPA Gatekeeper 编写策略，要求 Pod 拉取的镜像必须通过 cosign verify，否则拒绝创建
- 运行时强化：配合 seccomp、AppArmor 和只读根文件系统，即使恶意镜像意外运行，也无法持久化或逃逸
密钥与生命周期管理不可忽视
签名机制的安全性最终取决于密钥本身：
- Root 密钥必须离线保管，推荐使用 HSM 或云 KMS（如 AWS KMS、Azure Key Vault）托管，禁止硬编码在 CI 脚本中
- Targets 密钥建议短期轮换（例如每 90 天），尤其在自动化发布场景下；Notary v2 支持 Pending Rotation 状态，可实现平滑过渡
- 禁用 :latest 标签：签名绑定的是镜像 digest（如 sha256:abc123），而非浮动 tag；复用 :latest 会导致签名失效或被覆盖，应改用语义化版本 + commit hash（如 v2.9.0-abc123）
