harbor支持cosign防伪审计需嵌入构建、推送、拉取、运行四环节：1.启用content trust并配置oci artifact存储；2.用kms托管密钥签名后推送，harbor自动绑定签名与镜像；3.跨harbor复制时勾选“include signatures”保持绑定；4.通过admission controller强制运行时校验，并聚合审计日志实现全链追溯。
要让 Harbor 支持 Cosign 签署并贯穿整个发布链实现防伪审计，关键不是“加一个签名工具”，而是把签名动作嵌入构建、推送、拉取、运行四个环节，并由 Harbor 统一承载和关联签名与镜像。以下分四步落地，每步都对应真实可验证的控制点。
1. 在 Harbor 中启用 Cosign 集成并配置签名存储
Harbor v2.5+ 原生支持 Cosign，无需额外部署签名服务。需确认以下配置已生效：
- 在 Harbor Admin Console → Configuration → Content Trust 中开启 “Enable content trust” 和 “Enforce signed images for pull”（强制拉取签名镜像）
- 确保 Harbor 后端存储（如 S3/NFS）允许写入 OCI Artifact 类型数据，Cosign 签名以
application/vnd.cncf.notary.signature类型作为附件保存，与镜像清单强绑定 - 若使用 Helm 部署，
values.yaml中应含：
notary: { enabled: true }
trivy: { enabled: true }
core: { env: { CONTENT_TRUST: "enabled" } }
2. 构建阶段用 cosign 签名并推送到 Harbor
签名必须发生在镜像构建完成、推送前，且密钥不暴露在 CI 环境中：
- CI 脚本中调用：
cosign sign --key $KMS_KEY_URI myharbor.example.com/project/app:v1.0.0
其中$KMS_KEY_URI指向 Vault/HSM/KMS 托管的密钥（如hashicorp-vault://kv/signing-key），禁止使用本地.key文件 - 签名后立即推送：
docker push myharbor.example.com/project/app:v1.0.0
Harbor 自动捕获签名并建立镜像与签名的 OCI Artifact 关系，界面中可见“1 signature attached”标签 - 签名验证可在推送后立刻执行：
cosign verify --key cosign.pub myharbor.example.com/project/app:v1.0.0
3. 复制与分发时保持签名完整性
签名不是元数据，而是制品的一部分；跨仓库同步必须保留其绑定关系：
- Harbor 复制规则中，选择目标为“另一个 Harbor 实例”，勾选“Include signatures” —— 此时签名与镜像作为一对 OCI Artifact 同步，目标 Harbor 仍能显示签名状态和验证按钮
- 若复制到非 Harbor 目标（如 ECR 或自建 registry），签名会丢失绑定逻辑，仅存为独立 blob；此时需在目标侧重新签或禁用该路径
- 建议所有生产集群只从已启用 Content Trust 的 Harbor 拉取，避免中间环节断链
4. 运行时强制校验 + 审计留痕
签名防伪价值最终体现在 K8s 调度那一刻，需阻断未签名/签名失效镜像的启动：
- 在 Kubernetes 集群部署 Notary v2 Admission Controller（如
cosign-attest-admission），配置策略：拒绝拉取无有效 Cosign 签名的镜像 - Harbor 自带审计日志会记录每次签名上传、验证失败、拉取请求等事件，日志字段含：
"operation": "sign", "resource": "project/app:v1.0.0", "user": "ci-bot-2026" - 结合 SIEM 工具（如 ELK）聚合 Harbor audit.log 与 K8s audit log，可追溯“谁在何时对哪个镜像做了签名，又被哪个集群的哪个 Pod 拉取并运行”
