1. Cosign概述：起源、角色与对比
1.1 Cosign的起源
Cosign 诞生于 2021 年，由 Sigstore 开源社区发起，旨在解决软件供应链中容器镜像与制品的签名难题。Sigstore 是一个非营利性项目，由 Google、Red Hat、Purdue University 等联合推动，其核心理念是“让签名变得简单、免费且可验证”。
在 Cosign 出现之前，开发者对容器镜像进行签名通常需要自行管理复杂的 PKI 体系、申请证书、搭建密钥管理基础设施，门槛极高。Cosign 通过以下创新降低了签名门槛：
- 无密钥模式（Keyless Signing）：利用 OIDC（OpenID Connect）身份提供商（如 GitHub、Google、Microsoft）进行临时身份绑定，无需长期管理私钥。
- 透明日志（Rekor）：所有签名记录自动上传至公开可审计的透明日志，确保证书链可追溯、不可篡改。
- OCI 原生集成：签名直接作为 OCI 制品（如容器镜像）的附件存储，无需额外仓库或数据库。
关键里程碑：Cosign v1.0 于 2022 年 3 月发布，标志着容器签名进入生产可用阶段。截至 2025 年，Cosign 已成为 CNCF（云原生计算基金会）沙箱项目，并被数千家企业用于 CI/CD 流水线。
1.2 在软件供应链安全中的角色
软件供应链安全的核心目标是确保从代码提交到生产部署的每一个环节都未被篡改。Cosign 在以下三个关键环节发挥作用：
- 制品完整性验证：对容器镜像、Helm Chart、二进制文件等制品进行签名，确保其内容在构建后未被恶意修改。
- 身份与来源绑定：签名中嵌入签名者身份（如 GitHub Actions 工作流、开发者邮箱），使消费者能够确认制品的发布者。
- 策略执行与准入控制：与 Kubernetes 准入控制器（如 Kyverno、OPA Gatekeeper）集成，只允许经过 Cosign 验证的镜像运行。
1.3 与传统签名工具的对比
传统签名工具（如 GPG、OpenSSL、Notary v1）在容器化场景中存在明显短板。下表从多个维度进行对比：
| 对比维度 | Cosign | GPG | OpenSSL | Notary v1 |
|---|---|---|---|---|
| 签名对象 | 容器镜像、OCI 制品、二进制文件 | 文件、邮件、Git 提交 | 文件、证书、数据 | Docker 镜像（已弃用） |
| 密钥管理 | 支持无密钥模式（OIDC） | 需自行管理私钥 | 需自行管理私钥与证书 | 需自行管理私钥 |
| 透明日志 | 内置 Rekor 透明日志 | 无 | 无 | 无 |
| OCI 集成 | 原生支持，签名作为 OCI 附件 | 需手动附加 | 需手动附加 | 专有格式 |
| CI/CD 友好度 | 高，CLI 简洁，支持 GitHub Actions | 中等，需配置密钥环 | 低，命令复杂 | 低，已停止维护 |
| 策略集成 | 与 Kyverno/OPA 深度集成 | 需自定义脚本 | 需自定义脚本 | 有限 |
| 社区活跃度 | 高（CNCF 沙箱） | 高（通用工具） | 高（通用工具） | 低（已弃用） |
核心差异总结：Cosign 专为云原生供应链设计，将签名、身份、透明日志、策略执行整合为统一工作流；而 GPG/OpenSSL 是通用加密工具，在容器镜像签名场景中需要大量额外工程工作。Notary v1 虽曾是 Docker 官方签名方案，但已停止维护，Cosign 是其事实上的替代者。
1.4 为什么选择 Cosign？
从实际工程角度看，Cosign 带来以下直接收益：
- 零成本入门：无需购买证书、无需搭建 CA，使用 GitHub/GitLab 账号即可完成签名。
- 审计友好：所有签名操作记录在 Rekor 中，满足 SOC2、FedRAMP 等合规要求。
- 模板化配置：通过 Cosign 的
--template参数和策略模板，可将签名规则固化到 CI/CD 流水线中，实现“一次配置，处处验证”。 - 生态兼容：与 Docker、Podman、Kubernetes、Harbor、GitHub Actions 等主流工具无缝集成。
注意：虽然 Cosign 支持无密钥模式，但在生产环境中建议结合硬件安全模块（HSM）或密钥管理服务（KMS）保护长期密钥。无密钥模式适用于 CI/CD 临时签名，长期密钥用于组织级根信任。