从原理到落地的完整指南
目录导读
- 为什么关基环境必须做容器镜像签名？
- 容器镜像签名的底层逻辑与核心标准
- 主流签名工具对比：Cosign vs Notation vs Docker Content Trust
- 手把手实战：基于Cosign的镜像签名与验证
- 镜像签名在关基场景下的高阶策略
- 常见问题与误区（含问答）
为什么关基环境必须做容器镜像签名？
关键信息基础设施（关基）的容器化部署面临严峻的供应链攻击风险，根据2023年云原生安全报告，超过60%的漏洞源于容器镜像的不可信来源，镜像签名通过密码学保证，解决三大核心问题：
- 完整性：防止镜像在构建、存储、传输过程中被篡改
- 身份真实性：验证镜像发布者的数字身份，防止仿冒镜像植入后门
- 不可否认性：签名者无法抵赖自己对镜像的发布行为
在关基场景下（如金融、电力、政务），未签名镜像可能导致监管合规违规（如等保2.0、关键信息基础设施安全保护条例），同时极易成为APT攻击入口。
容器镜像签名的底层逻辑与核心标准
签名流程本质
核心标准
- OCI Distribution Spec：定义了签名作为镜像的“扩展属性”存在，可被镜像仓库存储和分发
- Notary Project（原Docker Notary）：基于TUF（The Update Framework）的签名框架
- Sigstore：开源社区推动的免密钥管理方案，核心组件包括Cosign、Fulcio、Rekor
签名存储方式
- 标签法：将签名写入镜像的特定标签（如
myimage:sha256-xxxx.sig） - Referrers API：OCI 1.1 新标准，通过引用结构关联镜像和签名，更优雅
主流签名工具对比
| 工具 | 密钥管理方式 | 适用场景 | 关基合规性 |
|---|---|---|---|
| Cosign | 支持KMS、硬件密钥、密钥环 | 云原生生态，适合CI/CD自动化 | 高（支持等保审计日志） |
| Notation | 依赖证书体系（X.509） | 需要企业PKI集成时首选 | 高（配套HashiCorp Vault） |
| Docker Content Trust | 内置但较重 | 传统Docker Hub用户 | 中（不推荐新项目） |
推荐：关基环境建议 Cosign + KMS（如AWS KMS、Azure Key Vault） 或 Notation + HSM。
手把手实战：基于Cosign的镜像签名与验证
环境准备
# 安装Cosign（版本≥2.0） sudo apt install cosign # 生成密钥对（使用KMS示例） cosign generate-key-pair --kms gcpkms://projects/xxx/locations/global/keyRings/test/cryptoKeys/signing-key
签名镜像
# 拉取并签名 docker pull gcr.io/your-project/myapp:v1 cosign sign --key gcpkms://... gcr.io/your-project/myapp:v1 # 验证签名 cosign verify --key gcpkms://... gcr.io/your-project/myapp:v1
CI/CD集成最佳实践
- 构建阶段：在Dockerfile中使用多阶段构建，生成不可变摘要
- 签名阶段：使用专门签名任务（非构建节点），密钥不暴露给构建环境
- 部署阶段：Kubernetes准入控制器（如Kyverno）强制验证签名，拒绝无签名或签名失败的镜像
镜像签名在关基场景下的高阶策略
策略1：分层签名
- 基础镜像签名：由安全团队审核并签发
- 应用层签名：由开发商使用企业CA证书签名
- 部署签名：运维团队加签，表示“该镜像已通过环境合规检查”
策略2：结合SBOM（软件物料清单）
镜像签名 + SBOM = 完整可信链通过Cosign同时签名镜像元数据（含SBOM摘要），验证时同时检查组件漏洞。
策略3：离线签名
在关基的隔离网络中,使用HSM（硬件安全模块）进行离线签名，然后通过手动方式导入镜像仓库，流程示例：
- 在气隙环境构建镜像 → 导出摘要文件
- 通过U盘传输到签名工作站（带HSM）
- cosign sign --key hsm://... --payload payload.json image.tar
- 将签名文件反向导入生产环境
常见问题与误区（含问答）
Q1：镜像签名能防止运行时攻击吗？
不能，签名只在镜像拉取和部署阶段保证源头可信，运行时安全需要配合RASP（运行时应用自保护）、机密计算等技术。
Q2：签名的密钥丢了怎么办？
需要密钥轮换机制，定期更换签名密钥，同时保留旧密钥的可信度（通过证书吊销列表或透明日志），Cosign支持“密钥验密”机制，旧签名仍可验证但标记为“来自已轮换密钥”。
Q3：必须使用KMS吗？没有KMS能否上线？
可以但不推荐,如果使用本地私钥：
- 必须将私钥加密存储在HSM或密码保险箱（如Vault）
- CI/CD中通过临时环境变量传入，且日志要屏蔽
- 生产环境建议至少使用KMS云服务或自建Vault
Q4：签名需要签所有层吗？
不需要。签名基于镜像清单（Manifest） 的摘要，而清单包含各层的哈希值，只要清单未变，任何层被篡改都会导致摘要变化，验证失败。
Q5：跨地域仓库如何签名？
可以使用远程签名模式，在中心化管理节点完成签名后，通过OCI Referrers API将签名对象同步到各地域仓库，注意同步机制需要支持最终一致性验证。
