签名校验仅作用于镜像层，发生在拉取或构建阶段，容器运行时不校验；需显式启用DOCKER_CONTENT_TRUST=1或cosign verify等机制，否则默认跳过；签名不保障运行时安全，须叠加扫描、最小权限等措施。
镜像和容器是两个独立但紧密关联的概念，签名校验只作用于镜像层，不涉及运行时的容器本身。校验发生在拉取（docker pull）或构建（docker build）阶段，即镜像被加载到本地前；一旦镜像通过验证并成功加载，后续创建容器（docker run）不再重复校验签名。
签名校验完全绑定在镜像生命周期中
镜像是静态的、只读的模板，包含应用代码、依赖、配置及元数据（如 manifest）。签名对象正是这个 manifest 的 SHA-256 摘要，不是容器运行态的内存、网络或文件系统状态。因此：
- 校验只在镜像被获取或解析时触发——比如
docker pull、docker build --pull或docker run首次需要拉取镜像时 - 已存在的本地镜像若未重新拉取或未启用运行时校验插件，
docker run不会再次检查签名 - 容器只是镜像的一个运行实例，自身不携带签名，也不参与验证流程
启用校验必须靠环境变量或策略配置
Docker 默认跳过所有签名检查。要让镜像加载过程强制校验，需主动开启信任机制：
- 设
DOCKER_CONTENT_TRUST=1：启用 Docker Content Trust（DCT），所有pull/push自动走 Notary v2 签名流程 - 用
cosign verify手动校验：适用于 CI/CD 流水线或 Kubernetes 准入控制，在拉取前调用命令验证指定镜像是否带有效 Cosign 签名 - 配合策略引擎：如 Kyverno 或 OPA/Gatekeeper，在集群层面定义“仅允许已由 prod-keyset@company.com 签名的
myreg/app:stable-*”这类规则
真正起效的关键在消费端而非生产端
一个镜像即使被正确签名并推送，若运行环境没开启校验，就等于没防护。常见断点包括：
- 开发机或测试集群未设置
DOCKER_CONTENT_TRUST=1，导致docker pull静默接受未签名镜像 - Kubernetes 节点使用默认
containerd配置，未启用image verification插件或未配置policy.json - CI 脚本中直接
docker run nginx:alpine，绕过了任何前置校验步骤
签名不等于容器安全，还需配合运行时控制
签名只解决“这镜像是谁发的、有没有被改过”，不保证容器行为安全。实际生产中需叠加：
- 镜像扫描：用 Trivy 或 Snyk 在拉取后检查漏洞和恶意软件
- 最小权限运行：容器以非 root 用户启动，禁用特权模式
- 不可变文件系统：挂载
/etc、/usr为只读，防止运行时篡改 - 进程白名单：通过 seccomp 或 AppArmor 限制系统调用范围
