Cosign：
此前我在使用Agentcy : 博文 中 遇到了Cosign的一些问题，为此去了解了一下Cosign的相关知识：
在云原生和软件供应链安全领域，Cosign被誉为“改变了制品签名游戏规则”的工具
一、Cosign 做了什么：
1. "OCI 原生存储"：把签名当成一种特殊的镜像
：不依赖任何外部签名数据库，直接把签名存在 OCI Registry 本身。
-
当你用
cosign sign [my-registry.com/my-agent:v1.0](https://my-registry.com/my-agent:v1.0)签名时： -
Cosign 会计算该镜像（或 Agent 资产）的 SHA256 Digest。
-
用私钥对 Digest 生成一段数字签名。
-
将签名包装成一个标准的 OCI Artifact（极简镜像层），并自动生成一个特定的 Tag 推送回同一个镜像仓库（例如
sha256-<digest>.sig，或通过现代 OCI 1.1 的 Referrers API 关联）。 -
好处：只要你的镜像仓库支持存 Docker 镜像（Harbor、GHCR、AWS ECR、ACR），它就天然支持存 Cosign 签名，零额外运维成本！镜像镜像到哪，签名就跟着同步到哪。
2. "Keyless（无密钥签名）"：消灭私钥泄露的根源
这是整个 Sigstore 生态（Fulcio + Rekor + Cosign）的王牌特性。
- 核心痛点：传统签名最大的风险是“私钥泄露”。
- Cosign 的解法：根本不留长效私钥，改用 OIDC 身份临时生成。
- 当 GitHub Actions 运行编译时，Cosign 向 Sigstore 的 CA（Fulcio）发起请求，附带 GitHub 签发的 OIDC 身份 Token（证明“我是 repo:agntcy/dir 在 main 分支触发的 Action”）。
- Fulcio 验证通过后，现场颁发一张有效期仅 10~15 分钟的临时 X.509 数字证书。
- Cosign 用这个临时证书完成签名，并把签名记录公开写入防篡改的透明日志库（Rekor，类似于区块链的公开审计账本）。
- 证书到期立即作废，哪怕内存泄露也无密钥可偷。验签时，只要去 Rekor 查日志确认“签名时刻证书合法且归属正确的 GitHub 仓库”即可。
3. 不仅签镜像，还能签一切“物料证明”
除了签名镜像本身，Cosign 还能挂载并签名：
- SBOM（软件物料清单）：证明该镜像包含哪些依赖组件。
- Attestation（来源证明/SLSA）：证明该镜像是在哪个特定的 GitHub Actions commit、哪台构建机上安全编译出来的。
- Agent Skills / Model Weights：在
agntcy/dir中，正是利用这一特性对 Agent 元数据和 Skill 配置打上防篡改签名。
二、开发者视角的极简体验
场景 1：传统带密钥模式（离线/自建场景常用）
# 1. 一键生成密钥对（cosign.key 和 cosign.pub）
cosign generate-key-pair
# 2. 签名（直接推送到远程镜像仓库）
cosign sign --key cosign.key ghcr.io/my-org/my-agent:v1
# 3. 任何人在任何地方用公钥验证
cosign verify --key cosign.pub ghcr.io/my-org/my-agent:v1
场景 2：在 CI/CD 中使用 Keyless 签名
# 在 GitHub Actions 中甚至不需要配置任何 Secret 私钥！
- name: Sign the container image
run: |
cosign sign --yes ghcr.io/my-org/my-agent@${{ steps.build.outputs.digest }}
验签时只需指定证书的颁发者和主体身份：
cosign verify \
--certificate-identity "https://github.com/my-org/my-repo/.github/workflows/build.yml@refs/heads/main" \
--certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
ghcr.io/my-org/my-agent:v1
三、其他
作用是什么？
数字签名的本质，是解决分布式网络环境下软件分发中的“信任危机”。如果没有签名，软件分发就像寄出一封没有封蜡火漆的信，谁都可以在路上拆开换掉。
具体到容器镜像和 AI Agent 资产，它的核心作用是提供四大安全保证：
- 防篡改（Integrity / 完整性）：
- 保证用户/集群拉取到的内容，与作者编译发布时的内容一模一样，哪怕只被恶意改动了一个字节，验签都会立即失败。
- 防冒充（Authentication / 身份认证）：
- 确认这个镜像/制品确实是由持有特定密钥（或通过合法 OIDC 身份认证）的特定实体发布的，而不是黑客伪造的“影子镜像”。
- 不可否认性（Non-repudiation）：
- 签名者无法否认自己曾发布过该制品，因为私钥只由其本人持有，或临时证书有防篡改的公开审计日志证明。
- 准入控制（Admission Control）拦截依据：
- 在 Kubernetes 集群或 Agent 运行时前端充当“门卫”。集群可以配置策略：“凡是没有官方 Cosign 签名的镜像，一律拒绝部署/拉起”。
签名的数学与密码学原理
数字签名基于非对称加密（Asymmetric Cryptography）和密码学单向哈希函数（Cryptographic Hash）。
其基本法则是：私钥签名，公钥验签；私钥绝对保密，公钥天下公开。
整个流程分为“签名”与“验签”两个阶段：
【签名阶段】(发布者)
原始文件/镜像 ----(SHA256 哈希)----> 摘要 (Digest) ----(私钥加密)----> 数字签名 (Signature)
【验签阶段】(使用者)
原始文件/镜像 ----(SHA256 哈希)----> 摘要 A
比较 A 和 B 是否相同？
数字签名 ----(公钥解密)------> 摘要 B
相同 => 未被篡改且来源真实！
不同 => 内容被改或伪造！
1. 签名阶段（发布者执行）
- 提取指纹（Hash）：无论镜像文件有多大（几个 MB 还是几十个 GB），先通过不可逆的哈希算法（如 SHA-256）计算出一个固定长度的字符串，称为摘要（Digest）。
- 特点：只要原内容有一丁点变化，算出来的哈希值会彻底改变（雪崩效应）。
- 加密摘要（Sign）：发布者使用只有自己掌握的私钥（Private Key）对这个哈希值进行加密计算。加密后的这段密文，就是数字签名（Signature）。
- 打包分发：发布者把“原始制品”和“数字签名”一起发布到仓库中。
2. 验签阶段（使用者 / 集群 / SDK 执行）
- 计算当前指纹：下载拉取到的制品，用同样的 SHA-256 算法现场计算出它的摘要（记为 摘要 A）。
- 解密签名还原指纹：拉取附带的数字签名，使用发布者公开的公钥（Public Key）对其进行解密，得到发布者当初签下的原始摘要（记为 摘要 B）。
- 比对核验：
- 如果 摘要 A == 摘要 B：证明该签名确实是用对应的私钥签出的（身份可信），且制品自签名后没有被任何第三方修改过（内容完整）。
- 如果 摘要 A != 摘要 B（或解密失败）：说明内容被篡改了，或者签名本身是假的，立即终止加载或报警。
浙公网安备 33010602011771号