镜像签名与供应链验证：Cosign/Sigstore 与准入控制深度实践

攻击面：
  - 中间人篡改：HTTPS 到仓库连接被劫持（公网仓库、弱 CA）
  - 仓库失陷：tag 被替换为带后门版本；依赖混淆：冒充官方包名
  - 构建链投毒：CI 缓存/基础镜像被污染后重新发布
无签名的后果：拉取到"看起来同名"但 digest 不同的镜像，无人察觉

keyless 流程：
  OIDC 身份（GitHub/Google 等）→ Fulcio 签发短期证书
  → Cosign 签名 → 签名写入镜像仓库（tag 或 Referrers）
  → 公钥哈希写入 Rekor → 验证时向 Rekor 查询

传统 PGP/私钥签名：私钥长期有效，泄露即全盘失效；分发轮换是负担
Sigstore keyless：
  - 证书有效期短（约 10 分钟），身份来自 OIDC（绑定 CI/开发者）
  - 无需管理长期私钥，泄露风险窗口极小

① 标签式（cosign 早期默认）：ghcr.io/user/app:sha256-<digest>.sig
② OCI 1.1 Referrers（推荐）：Index 通过 subject 字段关联，
   用 ORAS/referrers API 读取
③ Notation/Notary v2（CNCF 生态）：基于 OCI 1.1，x509 证书签名

# 拉镜像并用私钥签名（会产生 .sig 附件）
cosign sign --key cosign.key registry.example.com/app:v1
# keyless 签名（GitHub Actions 环境）
cosign sign --yes registry.example.com/app:v1
# 查看签名附件
cosign tree registry.example.com/app:v1

签名内容（payload）：
  - 被签名镜像的 digest（immutable 绑定）
  - 签名者证书（含 OIDC 身份声明）+ 时间戳
  - 可选自定义声明（如构建材料哈希）

# ORAS 推送任意 artifact（如 SBOM）关联到镜像 subject
oras attach --artifact-type application/spdx+json \
  registry.example.com/app:v1 sbom.spdx.json

# 查看镜像的 referrers（签名、SBOM、漏洞报告）
oras discover registry.example.com/app:v1

# 生成密钥对（长期密钥方案，适合测试/私有）
cosign generate-key-pair
# 生产建议把公钥推送到 KMS/HashiCorp Vault

# GitHub Actions 内 keyless 签名（无需密钥）
cosign sign --yes $IMAGE

# GitHub Actions：构建 + 签名
jobs:
  build:
    permissions:
      id-token: write   # 关键：允许请求 OIDC token
    steps:
      - uses: sigstore/cosign-installer@v3
      - run: docker build -t $IMAGE .
      - run: docker push $IMAGE
      - run: cosign sign --yes $IMAGE

# 同时生成构建出处（provenance），防"构建输入被投毒"
steps:
  - uses: slsa-framework/slsa-github-generator@v2
  - run: cosign attest --predicate predicate.json --type slsaprovenance $IMAGE

□ 只对 immutable digest 签名（v1 → sha256:...），tag 会漂移
□ 每次重建必须重新签名；签名与推送原子化（同一 CI job）
□ 多架构镜像：manifest list 需分别签每个平台清单

# 用公开公钥验证
cosign verify --key cosign.pub registry.example.com/app:v1

# keyless 验证（依赖 Rekor + 信任根）
cosign verify registry.example.com/app:v1 \
  --certificate-identity-regexp ".*@example.com" \
  --certificate-oidc-issuer-regexp ".*github.com"

# 验证并同时校验 SBOM attestation
cosign verify-attestation --type slsaprovenance registry.example.com/app:v1

# cosign policy（示例：只信任指定签发身份）
registry.example.com:
  images:
    app:
      - verified-by: example-corp
        certificate-identity: "release-bot@example.com"
        certificate-oidc-issuer: "https://github.com/login/oauth"

keyless 验证依赖公共信任根（Sigstore TUF 根）：
  - 离线/内网环境需要自建 Sigstore（fulcio+rekor+tuf 自托管）
  - 或退回"私钥 + cosign.pub"方案，把公钥作为信任锚点
验证失败的表现：
  - 签名不存在 / digest 不匹配 / 身份不符 / 证书已过期

# Kyverno ClusterPolicy：镜像必须通过 cosign 校验
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-image-signature
spec:
  validationFailureAction: Enforce
  rules:
    - name: verify-cosign
      verifyImages:
        - image: "registry.example.com/*"
          key: |-
            -----BEGIN PUBLIC KEY-----
            ...（信任锚点公钥）...
            -----END PUBLIC KEY-----

Connaisseur（基于 OCI 签名的准入控制器）：
  - 部署为 Validating Webhook，拦 Pod 创建
  - 策略：require-all（所有镜像必须有有效签名）
  - 支持 cosign 与 notaryv1 签名格式
  - 验证通过才允许 Pod 调度（否则拒绝）

# Docker Engine 开启内容信任（DCT）
export DOCKER_CONTENT_TRUST=1
docker pull registry.example.com/app:v1
# 无签名的镜像会被拒绝拉取

# 生成 SBOM 并附加、签名
syft registry.example.com/app:v1 -o spdx-json > sbom.spdx.json
cosign attach sbom --sbom sbom.spdx.json registry.example.com/app:v1
cosign sign --key cosign.key registry.example.com/app:v1
cosign verify-attestation registry.example.com/app:v1   # 一并校验 SBOM 真实性

SLSA L3 的核心要求之一就是"生成出处 + 签名出处"：
  签名对象 = SLSA provenance（构建器、输入、依赖清单）
  消费端 = 部署准入时验证 provenance 的签名与内容
效果：
  即使镜像本身被重建，出处中的构建输入也能被核对

镜像拉取前依次校验：
  ① 镜像本身签名（谁构建的）        cosign verify
  ② SBOM 附件签名（物料清单真实）    verify-attestation
  ③ SLSA provenance（构建输入可信）   verify slsaprovenance
  ④ 漏洞扫描报告（内容安全）          Trivy/scan（见安全扫描篇）

长期密钥方案：
  - 私钥进 KMS/Vault，绝不进 CI 变量明文
  - 公钥作为信任锚点发布到受控位置（如 GitHub 仓库 + cosign.pub）
keyless 方案：
  - CI 角色需 OIDC federation 配置（GitHub OIDC Provider）
  - 自建 Sigstore 时管理 Fulcio/Rekor/TUF 根

□ 私有仓库需支持 OCI 签名附件（Harbor 2.5+ 支持 cosign 附件）
□ 内网无 Rekor 访问 → 用私钥方案替代 keyless
□ 自建 Sigstore：需部署 fulcio、rekor-server、tuf 根、cosign
□ 离线验证：本地缓存 TUF 根与 Rekor 日志状态

# 证书/密钥轮换：旧签名将无法通过新公钥验证，需重新签名发布
# 撤销策略：
#   - keyless 短证书：过期即失效，天然轮换
#   - 长期密钥：泄露后用 cosign 吊销记录 + 重新签名所有受影响镜像
cosign verify --key old.pub image:v1   # 失败 → 触发重新签名流程