notary实现docker生产环境强制来源验证的核心是全局启用dct并绑定高可用私有notary服务，通过环境变量、证书配置、ci/cd拦截、k8s准入控制及密钥生命周期管理，确保每个镜像拉取与运行动作默认拒绝未签名或无效签名镜像。
在Docker生产环境中用Notary实现镜像部署的强制来源验证，核心不是“配完就安全”，而是让每个拉取、运行、部署动作都默认拒绝未签名或签名无效的镜像。关键在于把信任检查嵌入到基础设施链路中，而非依赖人工执行命令。
启用Docker内容信任并绑定私有Notary服务
必须全局开启内容信任，且指向企业自建的高可用Notary服务（非本地默认），否则仍走Docker Hub的公共Notary，无法满足内控与审计要求。
- 在所有构建机、CI节点、Kubernetes节点上设置环境变量：export DOCKER_CONTENT_TRUST=1，并持久写入shell配置文件
- 指定私有Notary地址：export DOCKER_CONTENT_TRUST_SERVER=https://notary.prod.example.com:4443
- 将Notary服务的CA证书（由可信CA签发）复制到Docker daemon信任目录：/etc/docker/certs.d/notary.prod.example.com:4443/ca.crt，否则dockerd连接失败
- 禁止使用DOCKER_CONTENT_TRUST=0临时绕过——应在CI流水线和K8s准入控制中硬性拦截该变量篡改行为
为生产镜像仓库配置分级密钥策略
不同环境对应不同密钥，避免“一把密钥打天下”；签名密钥不存于开发者本地，而由CI系统统一调用签名服务生成。
- 为prod命名空间单独生成targets密钥，根密钥离线保管，仅在轮换时短暂上线
- CI流水线中，在docker push前自动触发notary sign操作，并校验返回状态码是否为0；失败则中断发布
- 禁用latest标签推送：强制使用语义化版本（如v2.1.0）或Git commit hash，确保签名可追溯、不可覆盖
- 对基础镜像（如registry.prod.example.com/base/python:3.11）启用独立签名策略，要求其签名者身份必须属于base-images@prod.example.com
在Kubernetes集群中强制拦截未签名镜像
Docker客户端的信任设置只影响docker pull，而K8s中Pod拉取镜像由kubelet执行，需额外策略层控制。
- 部署ImagePolicyWebhook插件，对接内部Notary验证服务：每次创建Pod前，向https://policy.prod.example.com/verify发送镜像digest与签名元数据，仅当返回allowed: true才放行
- 或使用OPA/Gatekeeper编写约束模板，拒绝所有未匹配image.signature.present == "true"的资源请求
- 在kubelet启动参数中添加--image-pull-policy=Always，防止缓存绕过签名检查
- 为所有生产命名空间配置PodSecurityPolicy或PodSecurityAdmission，禁止privileged容器——因恶意镜像常依赖提权逃逸验证逻辑
建立密钥生命周期与验证可观测性
签名机制失效往往不是技术故障，而是密钥过期、证书吊销未同步、日志无记录等运维盲区导致。
- 为每套密钥设定90天有效期，到期前7天自动触发轮换流程：生成新targets密钥、重签名全部有效镜像、更新集群信任列表、归档旧密钥并标记revoked
- 所有cosign verify或notary list调用均采集结构化日志，字段包含image_ref、signature_status、verifier_identity、timestamp
- 对接SIEM平台，对signature verification failed事件实时告警，并自动创建工单关联镜像仓库、CI任务与部署流水线
- 每月执行一次“信任断连演练”：临时停用Notary服务，验证集群是否真正阻断新Pod创建，而非静默降级
