2. Cosign 核心概念：签名、验证、公钥基础设施 (PKI)、透明日志 (Rekor)、OIDC 身份认证
在深入故障排查之前，必须牢固掌握 Cosign 的五大核心支柱。这些概念构成了镜像签名与验证的信任基础。任何环节的断裂都会导致供应链信任边界失效。本章将逐一拆解这些概念，并揭示它们之间的协作关系。
2.1 核心概念全景图
下图展示了 Cosign 签名与验证的完整生命周期，以及各核心组件之间的数据流与信任传递关系。
2.2 签名 (Sign) 与验证 (Verify)
签名与验证是 Cosign 最基础的操作。签名将镜像摘要与签名者身份绑定，验证则确认该绑定未被篡改。
2.2.1 签名机制
- 签名对象：Cosign 对镜像的
digest（SHA256 哈希）进行签名，而非对整个镜像层签名。这保证了签名与镜像内容的唯一绑定。 - 签名存储：签名以 OCI 制品的形式存储在镜像仓库中，通常使用
sha256-xxxx.sig的 Tag 命名规则。 - 签名算法：默认使用 ECDSA-P256 私钥签名，支持 RSA 和 Ed25519。
故障排查要点： 签名验证失败最常见的原因是签名与镜像不匹配。检查
cosign verify 输出的 sha256: 摘要是否与 docker inspect 或 crane digest 返回的摘要一致。
2.2.2 验证流程
验证者执行 cosign verify 时，内部执行以下步骤：
- 从镜像仓库拉取签名制品。
- 从指定位置加载公钥（或通过 OIDC 信任根）。
- 使用公钥验证签名的有效性。
- （可选）查询 Rekor 透明日志，验证签名是否被记录。
- 输出验证结果，包含镜像摘要、签名者身份、证书链信息。
# 签名命令示例
cosign sign --key cosign.key ghcr.io/myorg/myapp:v1
# 验证命令示例
cosign verify --key cosign.pub ghcr.io/myorg/myapp:v12.3 公钥基础设施 (PKI)
Cosign 支持两种信任模型：传统的公钥对模型和基于 PKI 的证书链模型。在生产环境中，PKI 模型提供了更灵活的密钥轮换和撤销能力。
| 特性 | 公钥对模型 | PKI 证书链模型 |
|---|---|---|
| 密钥管理 | 直接使用私钥/公钥对 | 通过 CA 签发证书，支持中间 CA |
| 密钥轮换 | 需要重新分发公钥 | 仅需更新 CA 证书，子证书可自动轮换 |
| 撤销能力 | 无内置撤销机制 | 支持 CRL 和 OCSP |
| 信任根 | 单一公钥 | CA 根证书 |
| 适用场景 | 小团队、实验环境 | 企业级、多团队、合规要求 |
最佳实践： 在故障排查时，如果使用 PKI 模型，请检查证书链是否完整。使用
cosign verify --certificate-identity 和 --certificate-oidc-issuer 可以精确匹配签名者身份，避免因证书链不完整导致的验证失败。
2.4 透明日志 (Rekor)
Rekor 是 Sigstore 项目的透明日志组件，为所有签名提供不可篡改的审计追踪。它解决了“我什么时候签了名？”和“这个签名当时有效吗？”的问题。
2.4.1 Rekor 的核心作用
- 不可否认性：签名条目一旦写入 Rekor，无法被删除或修改。
- 时间戳证明：Rekor 返回 Signed Entry Timestamp (SET)，证明签名在某个时间点之前已经存在。
- 公开审计：任何人都可以查询 Rekor 日志，验证签名的存在性和完整性。
2.4.2 故障排查中的 Rekor 查询
当验证失败时，直接查询 Rekor 日志可以帮助定位问题：
# 查询特定镜像的 Rekor 条目
rekor-cli search --sha <镜像摘要>
# 获取条目详情
rekor-cli get --log-index <索引号>
# 验证 SET 时间戳
cosign verify --rekor-url https://rekor.sigstore.dev ghcr.io/myorg/myapp:v1
常见故障： 如果 Rekor 服务不可用或网络隔离，
cosign verify 默认会失败。可以通过 --insecure-ignore-sct 或 --skip-rekor 跳过 Rekor 验证（仅用于临时排查，生产环境不建议）。
2.5 OIDC 身份认证
OIDC（OpenID Connect）是 Sigstore 实现无密钥签名的基础。它允许开发者使用现有的身份提供商（如 GitHub、GitLab、Google）进行身份认证，无需管理私钥。
2.5.1 OIDC 工作流程
- CI 流水线或开发者向 OIDC 提供商请求身份令牌。
- Cosign 使用该令牌向 Sigstore 的 Fulcio CA 请求短期证书。
- Fulcio 验证令牌后，签发一个绑定身份信息的 X.509 证书。
- Cosign 使用该证书对镜像进行签名。
2.5.2 身份绑定验证
验证者可以通过以下方式确认签名者的身份：
# 验证时指定期望的身份和签发者
cosign verify \
--certificate-identity "user@example.com" \
--certificate-oidc-issuer "https://accounts.google.com" \
ghcr.io/myorg/myapp:v1| OIDC 提供商 | Issuer URL | 典型身份格式 |
|---|---|---|
| GitHub Actions | https://.actions.githubusercontent.com |
repo:owner/repo:ref:refs/heads/main |
| GitLab CI | https://gitlab.com |
project_path:group/project:ref:main |
https://accounts.google.com |
user@example.com |
2.6 概念关系总结
下表总结了五个核心概念在信任边界中的角色与故障排查关注点：
| 概念 | 信任角色 | 故障排查关注点 |
|---|---|---|
| 签名 (Sign) | 绑定镜像与身份 | 签名算法、签名存储位置、签名与镜像摘要匹配 |
| 验证 (Verify) | 确认签名有效性 | 公钥/证书加载、签名算法支持、验证参数 |
| PKI | 提供信任根 | 证书链完整性、CA 证书有效性、密钥轮换 |
| Rekor | 提供审计证明 | 日志可达性、SET 时间戳、日志一致性 |
| OIDC | 提供身份认证 | 令牌有效性、Issuer 配置、身份匹配规则 |