3. Cosign 项目概览：起源、核心功能与 Sigstore 生态
Cosign 是 Sigstore 生态中最核心的客户端工具，也是云原生用户接触软件供应链安全的第一道门槛。本章从项目起源、核心能力以及它在 Sigstore 全链路中的位置三个维度，帮助你建立对 Cosign 的完整认知。
3.1 项目起源：从“签名难”到“一键签名”
在 Cosign 出现之前，容器镜像签名面临几个痛点：
- 密钥管理复杂：开发者需要自行生成、保管和轮换 PGP 或 X.509 密钥对。
- 签名流程割裂：签名、存储、验证需要多个独立工具配合，缺乏端到端体验。
- 缺乏透明性：签名是否被吊销、是否被篡改，没有公开可审计的日志。
Cosign 由 Google、Red Hat、Chainguard 等团队于 2021 年联合发起，目标是让镜像签名像 docker push 一样简单。它原生支持 OCI 制品（容器镜像、Helm Chart、SBOM 等），无需额外搭建 PKI 基础设施，即可在 CI/CD 流水线中快速集成。
关键里程碑：Cosign v1.0 于 2022 年 2 月发布，标志着镜像签名进入“开箱即用”阶段。目前 Cosign 是 CNCF 沙箱项目 Sigstore 的组成部分，社区活跃度极高。
3.2 核心功能矩阵
Cosign 提供从签名生成、存储、验证到策略执行的完整能力。下表梳理了其主要功能模块：
| 功能类别 | 具体能力 | 典型命令/用法 |
|---|---|---|
| 签名生成 | 支持密钥对、密钥less（OIDC + Fulcio）、硬件密钥（YubiKey） | cosign sign --key cosign.key <image> |
| 签名存储 | 将签名作为独立 OCI 制品存入镜像仓库（tag 后缀或 referrers API） | cosign attach signature |
| 签名验证 | 支持公钥验证、密钥less 验证、策略引擎（Kyverno/OPA）集成 | cosign verify --key cosign.pub <image> |
| 透明性日志 | 自动将签名摘要上传至 Rekor，支持离线验证和搜索 | cosign verify --rekor-url https://rekor.sigstore.dev |
| 策略与准入 | 通过 cosign verify-attestation 验证 SBOM、SLSA 证明 |
cosign verify-attestation --type slsaprovenance |
| OCI 扩展 | 支持 Helm Chart、WASM 模块、普通二进制文件的签名 | cosign sign-blob <file> |
3.3 Cosign 与 Sigstore 生态的关系
Cosign 并非孤立工具，而是 Sigstore 全链路中的“客户端执行者”。Sigstore 生态包含三个核心服务，Cosign 与它们协同工作：
- Fulcio（证书颁发机构）：Cosign 在密钥less 模式下，通过 OIDC 身份（如 GitHub、Google、Microsoft）向 Fulcio 申请短期签名证书。Fulcio 验证身份后签发 X.509 证书，证书中嵌入用户身份信息。
- Rekor（透明性日志）：Cosign 每次签名操作都会将签名元数据（包括证书指纹、镜像摘要、签名载荷）提交到 Rekor 日志。Rekor 提供不可篡改的审计线索，任何人都可以查询某个签名是否被记录。
- CT Log（证书透明度日志）：Fulcio 签发的证书会同时提交到公共 CT Log，用于监控和吊销异常证书。Cosign 在验证时也会检查证书是否在 CT Log 中。
一句话总结：Cosign 是“手”，负责执行签名和验证操作；Fulcio 是“身份源”，提供临时证书；Rekor 是“账本”，记录所有签名事件；CT Log 是“监督者”，确保证书签发可审计。
3.4 三种签名模式对比
Cosign 支持三种签名模式，适用于不同安全等级和运维场景：
| 模式 | 密钥管理 | 身份绑定 | 适用场景 | 安全等级 |
|---|---|---|---|---|
| 密钥对模式 | 本地生成私钥/公钥，私钥需安全保管 | 无（仅绑定公钥指纹） | 离线环境、自建 CI/CD | 中 |
| 密钥less 模式 | 无本地密钥，Fulcio 签发短期证书 | 绑定 OIDC 身份（GitHub/GitLab/Google） | 云原生 CI/CD、多团队协作 | 高 |
| 硬件密钥模式 | 私钥存储在 YubiKey / TPM 中 | 绑定硬件设备 | 高安全合规、金融/政府场景 | 最高 |
注意：密钥less 模式是 Sigstore 推荐的默认方式。它消除了私钥泄露风险，同时通过 Rekor 日志提供公开审计能力。但需要确保 CI 环境能够访问 Fulcio 和 Rekor 服务（公网或私有部署）。
3.5 在 Kubernetes 环境中的典型位置
Cosign 在 K8s 环境中的集成点主要集中在以下环节：
- CI/CD 流水线：在镜像构建完成后立即执行
cosign sign，将签名与镜像一起推送。 - 镜像仓库侧：通过仓库的 Webhook 或策略引擎（如 Harbor 的审查功能）验证签名。
- K8s 准入控制：使用 Kyverno、OPA Gatekeeper 或 Cosign 内置的
cosign verify命令，在 Pod 创建前检查镜像签名。 - 审计与合规：通过 Rekor 查询签名历史，用于事后审计和取证。
实践建议：在 K8s 生产环境中，推荐将 Cosign 密钥less 模式与 Kyverno 策略引擎结合。这样既能实现“无密钥”的自动化签名，又能通过策略强制所有镜像必须经过签名验证才能运行。