Cosign 简介：签名验证与供应链安全基石
在软件供应链安全体系中，Cosign 是面向云原生场景的容器镜像签名与验证工具。它由 Sigstore 项目孵化，旨在解决传统 PGP/GPG 签名在密钥管理、分发和验证上的痛点，让开发者能以极低的操作成本为容器镜像、Blob 文件或 OCI Artifact 添加不可篡改的数字签名。
Cosign 与 Sigstore 的关系
Sigstore 是一个开源的安全签名服务生态，而 Cosign 是其最核心的客户端工具。下表梳理了二者的定位差异：
| 维度 | Sigstore | Cosign |
|---|---|---|
| 定位 | 全链路签名基础设施与协议 | 面向用户的 CLI 与 SDK 工具 |
| 核心组件 | Fulcio（证书颁发）、Rekor（透明日志）、Cosign（客户端） | 签名、验证、存储、策略引擎 |
| 密钥模型 | 支持临时密钥 + OIDC 身份绑定 | 支持密钥对、密钥less 模式、KMS 集成 |
| 用户交互 | 提供 REST API 与公共实例 | 提供命令行 cosign sign / cosign verify |
| 依赖关系 | Cosign 依赖 Sigstore 的 Fulcio 和 Rekor | 可独立使用本地密钥，也可对接 Sigstore 服务 |
关键理解：Sigstore 是“高速公路与收费站”，Cosign 是“车辆与驾驶员”。开发者通过 Cosign 调用 Sigstore 基础设施，实现无需管理长期密钥的签名体验。
Cosign 在软件供应链安全中的角色
Cosign 填补了容器化交付中“谁签的、是否被篡改”的信任空白。它在供应链安全中承担以下四个核心角色：
- 镜像完整性保护：对镜像摘要（Digest）进行签名，确保从构建到部署的传输过程中镜像未被替换或篡改。
- 身份绑定：通过 OIDC（OpenID Connect）将签名者身份（如 GitHub Actions、Google Cloud Build）绑定到签名证书，实现“谁构建谁签名”的可审计链路。
- 策略执行：结合 Kyverno、OPA/Gatekeeper 等策略引擎，在集群准入阶段强制要求镜像必须携带有效签名，否则拒绝部署。
- 透明审计：签名记录自动上传至 Rekor 透明日志，任何一方均可公开验证签名时间与身份，防止签名抵赖或证书撤销后仍被滥用。
冷启动场景提示：在函数计算或 Serverless 冷启动场景中，Cosign 验证本身会引入额外的网络 I/O 和证书链解析开销。本课程后续章节将专门针对这一环节进行削峰优化。
Cosign 签名验证流程（内联 SVG）
下图展示了 Cosign 在 Sigstore 生态下的标准签名与验证流程，重点体现身份、签名、日志与策略的交互关系：
Cosign 的核心能力矩阵
以下表格从功能维度总结 Cosign 在供应链安全中的关键能力：
| 能力 | 说明 | 典型命令/配置 |
|---|---|---|
| 镜像签名 | 对镜像摘要进行非对称签名，支持本地密钥、KMS、密钥less 模式 | cosign sign <image> |
| 镜像验证 | 验证签名是否有效、证书链是否可信、是否在有效期内 | cosign verify <image> |
| Blob 签名 | 对任意文件或二进制进行签名，适用于非容器工件 | cosign sign-blob <file> |
| 策略集成 | 输出验证结果供 Kyverno/OPA 消费，支持准入控制 | cosign verify --policy <policy.rego> |
| 透明日志查询 | 通过 Rekor 查询签名记录，支持审计与溯源 | rekor-cli get --uuid <uuid> |
| 密钥管理 | 支持本地文件、AWS KMS、GCP KMS、Azure Key Vault、Hashicorp Vault | cosign generate-key-pair |
性能关注点：在冷启动场景下，
cosign verify 需要从 Rekor 获取证书链、检查 CRL（证书吊销列表）并解析 OIDC 。这些步骤在首次调用时可能产生 200–800ms 的额外延迟，是后续削峰优化的重点对象。
Cosign 的密钥less 模式（内联 SVG）
密钥less 模式是 Cosign 区别于传统签名工具的核心特性。它利用 Sigstore 的 Fulcio 服务为每次签名颁发短期证书，开发者无需管理私钥。下图展示了密钥less 模式下的身份与签名关系：