3、Cosign概述：Cosign项目起源、核心功能（签名、验证、存储）、与Sigstore生态的关系

3.1 项目起源：从“谁构建了这份镜像”到“可验证的信任链”

在云原生供应链安全实践中，一个根本性问题长期悬而未决：“如何证明一个容器镜像确实由声称的组织构建，且自构建后未被篡改？” 传统的镜像拉取依赖传输层加密（TLS）和 registry 访问控制，但无法防止构建管道被攻陷、镜像被替换或中间人注入恶意层。

Cosign 项目由 Sigstore 社区于 2021 年发起，旨在解决上述信任真空。其核心设计理念是：让容器镜像的签名与验证像使用 SSH 密钥一样简单，无需复杂的 PKI 基础设施、无需管理证书颁发机构（CA），即可实现端到端的签名、分发和验证。

3.2 核心功能：签名、验证与存储

Cosign 围绕三个核心操作构建，覆盖镜像从构建到部署的完整信任生命周期：

3.2.1 签名流程（Sign）

Cosign 的签名并非直接对镜像层进行签名，而是对镜像的 清单摘要（Manifest Digest） 进行签名。这保证了签名与镜像内容的强绑定：

1. 计算摘要： 对镜像清单（manifest）进行 SHA-256 哈希，得到唯一摘要值。
2. 生成签名： 使用签名者的私钥对摘要值进行加密签名，生成签名载荷。
3. 附加到 Registry： 将签名载荷作为 OCI 制品（类型为 application/vnd.dev.cosign.sig.v1+json）推送到镜像所在的 registry，通过标签引用关联。

3.2.2 验证流程（Verify）

验证是签名的逆过程，也是准入控制的核心：

1. 拉取签名： 根据镜像标签或摘要，从 registry 拉取对应的签名层。
2. 获取公钥： 从本地密钥环、KMS 或 Sigstore 的 Fulcio（证书颁发机构）获取验证公钥。
3. 验证签名： 使用公钥解密签名，并与镜像摘要进行比对。若匹配，则证明镜像未被篡改且签名者身份可信。
4. 可选验证： 结合 Rekor（透明日志）检查签名是否被记录，提供不可否认性。

3.2.3 存储模型：OCI 层附加

Cosign 采用 “签名即层” 的存储策略，避免了传统签名方案需要独立签名服务器或 Sidecar 的复杂性：

• 无侵入： 签名不修改原始镜像层，仅作为附加层存储在 registry 中。
• 可发现： 通过 cosign triangulate 命令可自动发现镜像关联的所有签名和 attestation。
• 可审计： 签名层本身也是 OCI 制品，支持内容寻址和版本管理。

3.3 与 Sigstore 生态的关系

Cosign 并非孤立工具，它是 Sigstore 生态中面向容器镜像签名的核心组件。Sigstore 是一个由 Linux 基金会托管的开源项目，旨在为所有软件制品提供免费的、基于公钥基础设施（PKI）的签名与验证服务。Cosign 与 Sigstore 其他组件的关系如下：

3.3.1 核心组件分工

3.3.2 生态协作流程

1. 身份绑定： 开发者通过 OIDC（如 GitHub OAuth）向 Fulcio 证明身份，Fulcio 签发短期 X.509 证书。
2. 签名与记录： Cosign 使用该证书对镜像摘要签名，并将签名同时推送到 OCI Registry 和 Rekor 透明日志。
3. 验证与准入： 在部署阶段，Policy Controller 或 cosign verify 从 Rekor 和 Registry 拉取签名与证书，验证镜像完整性和签名者身份。
4. 审计与追溯： 安全团队可通过 Rekor 查询所有历史签名记录，追溯镜像的构建来源和签名时间。

3.4 小结