CI 供应链被投毒后，我用 Sigstore + SLSA 给镜像签了一次名就再没睡不踏实

CI 供应链被投毒后我用 Sigstore SLSA 给镜像签了一次名就再没睡不踏实上周凌晨一条 CI 告警把我惊醒构建产出的镜像 digest 和昨晚的基准不一致。不是代码变更不是依赖升级是某个基础镜像 layer 里被人塞进了一个修改过的.so文件。排查了三个小时最后定位到一台镜像缓存节点被污染构建时拉到了被投毒的busybox:1.36.1。那一刻我才意识到我们的 CI 一直在裸奔。没有人验证镜像到底是谁构建的也没有人验证它有没有被改过。天亮后我花了一天时间把 Sigstore SLSA 接到 CI 里。这篇文章不是科普而是想记录一套能直接落地的镜像签名和来源验证流程。被投毒的那一夜先还原一下现场我们的构建流水线从 Docker Hub 拉基础镜像构建业务镜像后推送到内部仓库。镜像 tag 是可变的digest 却没人记录。生产环境拉镜像时只校验 tag不校验签名也不校验来源。攻击者或者内部误操作在某台缓存节点上替换了一个 layer 的 blob。因为 tag 没变构建时直接用了这个被污染的层。最终产出的业务镜像里夹带了后门。这次运气好被改的是测试环境的镜像。如果是生产后果不堪设想。我想要的其实就两件事签名构建完成后镜像必须被不可抵赖的密钥签名。来源任何人都能验证这个镜像是在哪条 CI 流水线上、从哪个 commit 构建出来的。Sigstore 的 cosign 解决第一件事SLSA provenance 解决第二件事。两者加起来刚好覆盖我的诉求。第一步用 cosign 给镜像签名我们先在 CI 里生成密钥对cosign generate-key-pair k8s://ci-namespace/signing-key用的是 Kubernetes KMS 封装私钥不会落地到构建节点。然后构建镜像时IMAGEregistry.internal/myapp:$GIT_COMMIT_SHORTdockerbuild-t$IMAGE.dockerpush$IMAGEcosign sign--keyk8s://ci-namespace/signing-key\--annotationscommit$GIT_COMMIT\--annotationspipeline$CI_PIPELINE_URL\$IMAGE签名的同时我把 commit 和 pipeline URL 也写进 annotations。后续查来源一目了然。验证签名很简单cosign verify--keycosign.pub registry.internal/myapp:abc123\--annotationscommitabc123\--annotationspipelinehttps://ci.example.com/pipelines/42如果镜像被篡改或者不是这条流水线构建的验证直接失败。第二步用 SLSA provenance 记录来源签名只能说明“这个镜像没被改”但没法证明“它是按我期望的方式构建的”。SLSA provenance 就是做这个的。我们在 CI 里接入 SLSA GitHub Generator我们用的是 GitLab所以用它的 generic provenance 模式sign-image:stage:signimage:ghcr.io/slsa-framework/slsa-generator-containerscript:-cosign sign--key k8s://ci-namespace/signing-key $IMAGE-generate-provenance--subjects ${IMAGE}${DIGEST} \--predicate provenance.json-cosign attest--key k8s://ci-namespace/signing-key \--predicate provenance.json--type slsaprovenance $IMAGE生成的 provenance 文件里包含构建器 IDGitLab runner 的 URL源码仓库和 commit SHA构建定义文件CI 配置输入参数和依赖列表部署时我加了一条验证cosign verify-attestation--keycosign.pub\--typeslsaprovenance\--policypolicy.cue\$IMAGEpolicy.cue里规定只允许来自特定仓库、特定分支、使用官方 runner 构建的镜像进入生产命名空间。第三步K8s 准入校验不签名的镜像不许跑光有签名不够必须让集群执行。我装了一个 Kyverno 策略apiVersion:kyverno.io/v1kind:ClusterPolicymetadata:name:verify-image-signaturespec:validationFailureAction:Enforcerules:-name:check-cosign-signaturematch:resources:kinds:-Podnamespaces:-productionverifyImages:-imageReferences:-registry.internal/*key:|-----BEGIN PUBLIC KEY----- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA... -----END PUBLIC KEY-----从那以后任何没签名或签名验证失败的镜像K8s 直接拒绝拉起。测试环境可以先告警生产环境直接拦截。落地后的变化环节改造前改造后镜像来源只认 tag签名 provenance commit部署校验无Kyverno 强制拦截缓存污染无法发现签名验证失败直接暴露回滚追溯靠 tag 猜用 digest 和 commit 精确对应构建器信任任何 runner只允许官方 runner 签名最让我安心的是最后一条即使有人拿到了内部仓库的推送权限没有签名密钥他也无法让镜像通过校验跑起来。三个容易踩的坑1. 不要把私钥存在 CI 变量里早期我图省事把 cosign 私钥放在 GitLab CI variable 里。后来改成 Kubernetes KMS 封装私钥不出 KMS构建节点只拿到临时 token。安全性差了一个数量级。2. 签名一定要基于 digest而不是 tagcosign sign--keyk8s://ci-namespace/signing-key$IMAGE$DIGESTtag 是可变的digest 才是镜像的唯一指纹。验证时也用 digest否则攻击者可以替换同名 tag 的镜像。3. 别忘了给基础镜像也做验证我们只签了自己的业务镜像结果基础镜像还是裸奔。后来把所有 base image 也纳入cosign verify检查并在 Dockerfile 里固定 digestFROM busyboxsha256:abc123...配合 Renovate 自动更新 digest既安全又不耽误升级。写在最后供应链安全不是玄学也不是只有大厂才需要。一台被污染的缓存节点、一个被替换的 base image、一个被盗用的 CI runner都可能让你的镜像在不知不觉间“带毒”。Sigstore SLSA 的组合把镜像从“信任 tag”变成“信任密码学证明”。这套东西落地一天后我再看 CI 流水线终于能睡踏实了。如果你还在用docker pull之后直接kubectl apply建议先从 cosign 签名开始。成本不高但回报是你再也不用担心凌晨被镜像 digest 告警叫醒了。