01 · 镜像签名技术演进
镜像签名的目标是在“拉取”环节为消费方提供密码学保证：此镜像来自某个已声明的身份，且自构建后未被篡改。技术路线经历了三代演进：
| 代际 | 技术 | 信任模型 | 局限 |
|---|---|---|---|
| 第一代：GPG分离签名 | 开发者以GPG私钥对digest手工签名，验证方持有公钥环 | 点对点身份信任 | 密钥分发与吊销困难，几乎无法规模化自动化 |
| 第二代：Docker Content Trust / Notary v1 | 基于TUF（The Update Framework）的委托签名，镜像tag与digest绑定 | 委托角色密钥体系 | 运维复杂、密钥管理重，跨仓库支持有限，生态采用率低 |
| 第三代：Sigstore/cosign与Notary v2 | 基于OIDC的无密钥签名（keyless）+透明度日志；Notary v2（CNCF项目，实现为Notation）提供厂商中立的签名规范 | 短期身份凭证+透明日志审计 | 依赖公共信任基础设施可用性（私有部署可缓解） |
注：TUF与in-toto的规范演进（含sigstore整合TUF作为信任根的分发实践）由安全学术社区长期维护，细节以各自官方规范为准。
02 · Sigstore生态组件详解
Sigstore由Linux基金会托管、OpenSSF推动，2021年3月宣布、cosign 1.0于2021年7月发布，目标是为开源软件分发提供“无需长期私钥”的签名基础设施。其三大公共组件构成完整信任链：
| 组件 | 职能 | 关键事实 |
|---|---|---|
| Fulcio | 免费短期证书CA：对OIDC身份（邮箱/GitHub账号/工作负载身份）签发短时（约10分钟）代码签名证书 | 证书绑定身份而非长期密钥；私钥仅存于内存、签名后销毁 |
| Rekor | 透明度日志：所有签名/证明条目只可追加记录，提供密码学审计（inclusion proof） | 第三方可通过监控日志发现异常签名行为；公开实例rekor.sigstore.dev |
| cosign | 签名/验证CLI：支持keyless与KMS/硬件密钥；签名的证明（attestation）以OCI artifact形式存入同一仓库 | 与容器仓库解耦设计，支持私有部署全栈（Fulcio私有实例+私有Rekor） |
无密钥签名（Keyless）的信任逻辑：签名者身份=OIDC令牌中的身份声明（如GitHub Actions的工作负载身份联邦）；证书十分钟有效期使“密钥失窃”这一传统签名最大风险源自然消解；Rekor日志使“某人签了什么”永久可查——三者叠加实现了对SolarWinds式“长期驻留密钥滥用”的制度性缓解。sigstore于2023年发布2.0，进入通用可用阶段。
03 · 验证模式与Kubernetes准入落地
3.1 验证的三层形态
| 形态 | 执行点 | 强度 | 局限 |
|---|---|---|---|
| 客户端拉取前验证 | docker/crictl pull时cosign verify | 依赖操作者自觉 | 绕过容易，仅适合开发期 |
| 准入时验证（推荐） | Kubernetes API Server准入链（policy-controller/Kyverno等） | 平台强制，未通过即拒绝Pod创建 | 需妥善设计例外机制（见3.3） |
| 持续/事后验证 | 运行时控制器周期校验在运行镜像签名与策略 | 发现漂移与“先准入后替换” | 资源开销，需与准入互补 |
3.2 准入验证示例（sigstore policy-controller）
# 策略示例：仅允许来自本组织GitHub仓库且经cosign keyless签名的镜像
apiVersion: policy.sigstore.dev/v1beta1
kind: ClusterImagePolicy
metadata:
name: dm-signed-images
spec:
images:
- glob: "registry.example.com/dm/**"
authorities:
- keyless:
url: https://fulcio.sigstore.dev
identities:
- issuer: https://token.actions.githubusercontent.com
subjectRegExp: "^https://github.com/dimiao-org/.*$"
注：policy-controller（原cosign policy webhook）由Sigstore项目维护，CRD版本随演进更新，字段以官方安装文档为准；私有信任基础设施时authority中指定自建Fulcio/Rekor地址。
3.3 例外机制设计（防止策略沦为纸面）
- 应急通道：签名基础设施故障时启用预审批的“熔断策略”，限定命名空间、限时（如4小时）、全程审计留痕，事后强制补签并复盘；
- 遗产镜像：建立存量清单+digest白名单，逐批完成签名替换，禁止无限期豁免；
- 第三方镜像：对无法取得签名的外部镜像，要求SBOM+扫描报告+digest三方固化，并经变更评审。
04 · Notation（Notary v2）与多云互操作
Notation是CNCF Notary v2项目的参考实现，提供厂商中立的OCI镜像签名规范：签名以OCI artifact形式与镜像同仓存储，验证方可由任意符合规范的客户端执行。2023年起，AWS Signer-ECR、Azure Container Registry、阿里云ACR等均已提供对Notation/Notation生态的支持或互通能力——多云环境下以“cosign处理自研制品、Notation对接云厂商托管制品”的双轨制为现实路径。选型关注三点：
- 信任根归属：公共实例（sigstore.dev）适合开源生态；生产环境建议私有Fulcio/Rekor或云厂商托管信任根，避免外部基础设施单点影响发布；
- 证明类型覆盖：镜像签名之外，SBOM（第3页）、SLSA provenance（第4页）、VEX均可作为cosign attestations一并签名存储——同一信任链承载多层证明；
- 供应链联动：镜像替换漏洞（如CVE-2024-21626类运行时补丁）应触发“重签—重验—滚动更新”闭环，而非绕开签名直接热修。
05 · 透明度日志的安全事件与监控价值
- 发现伪造：Rekor条目监控可在“有人冒用组织身份签名未知镜像”时第一时间告警（比对subject与组织身份白名单）；
- 审计取证：事后追溯某digest全部签名与证明历史，支撑事件调查与司法举证；
- 生态问责：公开日志使开源项目维护者的签名行为可社会监督，与OpenSSF Scorecard（第8页）共同构成上游信任画像。
本节参考来源（第5页）
Sigstore官方文档（cosign、Fulcio、Rekor）：docs.sigstore.dev；sigstore.dev项目主页：sigstore.dev。
cosign官方仓库与发布记录（1.0发布于2021年7月）：github.com/sigstore/cosign。
sigstore policy-controller文档：docs.sigstore.dev/policy-controller。
Notary v2与Notation（CNCF）：notaryproject.dev。
The Update Framework（TUF）官方规范：theupdateframework.io；Docker Content Trust官方文档：docs.docker.com。
GitHub Artifact Attestations文档（2024年5月公测）：docs.github.com。
AWS Signer / ECR镜像签名、Azure ACR Notation支持文档：docs.aws.amazon.com/signer、learn.microsoft.com。
CNCF Notary项目孵化档案：cncf.io/projects/notary。