Docker镜像签名通过绑定manifest哈希实现内容防篡改，签名存储为独立OCI Artifact并强制运行时验证，结合OIDC身份绑定、Rekor日志存证与Fulcio无密钥签名三重机制，并在Kubernetes准入层叠加策略引擎实现双条件放行。
通过Docker镜像签名技术防范容器供应链恶意篡改攻击，核心在于让“内容不可改、来源不可伪、行为不可抵赖”。只要签名验证链完整生效，任何对镜像层、配置或元数据的修改都会导致验证失败，从而在运行前就拦截攻击。
用签名绑定镜像内容与哈希值
镜像签名不是对整个文件打包加密，而是对manifest 的 SHA256 摘要进行非对称加密。这个摘要由镜像所有层的 blob digest 和配置文件 hash 拼接后计算得出——只要任意一层被替换、添加或删减，摘要值就会彻底改变，原有签名立刻失效。
- 例如：攻击者把基础镜像 alpine:3.19 替换为带后门的同名镜像，即使 tag 不变，manifest hash 已不同，cosign verify 或 Notary v2 验证必然失败
- 签名本身存储为独立 OCI Artifact（如
application/vnd.dev.cosign.simplesigning.v1+json），与镜像分离但强关联，不随镜像拉取自动下载，必须显式验证
强制运行时验证签名再加载镜像
签名存在不等于安全，关键是要让容器运行时（如 containerd）在 pull 或 run 阶段主动拒绝未签名或签名异常的镜像。
- 在
/etc/containerd/config.toml中启用策略插件，配置"type": "sigstoreSigned", "policy": "require" - 配合
/etc/containerd/certs.d/下的仓库级 policy.json，可细化控制：比如仅对ghcr.io/internal/命名空间要求签名，而允许docker.io/library/公共镜像临时豁免（需评估风险） - 重启 containerd 后，执行
nerdctl pull或docker pull（需适配）将触发自动校验，失败时直接报错退出，不写入本地存储
切断攻击者伪造签名的路径
单纯验签还不够，得防止攻击者用盗用密钥或伪造身份重新签名。现代方案（如 Sigstore/Cosign）通过三重机制封堵：
-
OIDC 身份绑定：签名时使用 GitHub Actions、Azure AD 等颁发的短期 OIDC token，证书中嵌入
sub和iss字段，验证时用--certificate-identity-regexp限定只认@mycompany.com邮箱 -
透明日志存证（Rekor）：每次
cosign sign同时写入公开、防篡改的时间戳日志，攻击者无法删除或隐藏签名记录 - 无密钥签名（Fulcio）：开发机不存私钥，签名过程由 Fulcio 服务动态签发证书，私钥生命周期极短，杜绝长期密钥泄露风险
在准入环节叠加策略引擎
运行时验证是最后一道防线，更优做法是在 Pod 创建前就拦截。将签名验证前置到 Kubernetes 准入控制器中：
- 用 Kyverno 或 OPA Gatekeeper 编写策略，要求所有
image字段匹配*.myregistry.com/**的镜像，必须通过cosign verify --certificate-oidc-issuer https://token.actions.githubusercontent.com - 策略可附加时间窗口限制，例如“仅接受 72 小时内签名的镜像”，防止攻击者复用旧签名
- 结合镜像扫描结果（如 Trivy 报告），实现“签名有效 + 无高危漏洞”双条件放行
