如何用 cosign 验证 LiteLLM Docker 镜像签名以确认镜像未被篡改

部署 LiteLLM Proxy 时，通常会从 GHCR 拉取镜像（例如 docker/README.md 中离线测试使用的 ghcr.io/berriai/litellm:main-stable）。在把它放进生产环境之前，可以用 cosign 验证镜像签名，确认拉取到的就是官方发布的那个镜像、未被篡改。LiteLLM 发布到 GHCR 的所有 Docker 镜像都用 cosign 签名，并且每次发布都使用同一个签名密钥。

验证前需要准备什么

• cosign CLI：签名验证依赖 cosign 工具，README 中的验证命令都以 cosign verify 为入口，需要先安装并配置好该命令行工具。
• 网络可达性：验证命令需要访问 GHCR（ghcr.io）读取镜像及其签名，并访问 README 中给出的 cosign.pub 公钥地址。

验证对象是完整的镜像引用，即 ghcr.io/berriai/litellm:<release-tag> 这种「仓库地址 + 版本 tag」的组合。

推荐方式：用固定的 commit hash 指定公钥

LiteLLM 的签名密钥是在 commit 0112e53 中引入的，之后的所有发布都用这把密钥签名。README 推荐直接把这把密钥的引用固定到该 commit hash 上：

cosign verify \
  --key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \
  ghcr.io/berriai/litellm:<release-tag>

这里 --key 指向的是按 commit hash 取出的 cosign.pub 公钥文件，而不是某个分支或 tag 上的版本。commit hash 在密码学上是不可变的，因此 README 称这是最能确保你使用的就是最初那把签名密钥的方式——即使仓库里的文件被改动，这个地址取到的仍然是引入密钥时的那一份。

命令中只有一处需要替换：把 <release-tag> 换成你实际要部署的版本 tag。README 给出的示例值是 v1.83.0-stable。

替代方式：用 release tag 指定公钥

如果希望命令更易读，也可以用 release tag 来取公钥：

cosign verify \
  --key https://raw.githubusercontent.com/BerriAI/litellm/<release-tag>/cosign.pub \
  ghcr.io/berriai/litellm:<release-tag>

这个仓库对 tag 做了保护，tag 解析出的公钥与固定 commit 方式拿到的是同一把密钥，所以两种方式在正常条件下等价。区别在于 tag 方式依赖仓库的 tag 保护规则，强度上不如固定 commit hash 的方式，README 将其定位为便捷选项。

同样地，<release-tag> 需要替换为你部署的版本（如 v1.83.0-stable），且 --key 与镜像引用中使用的应是同一个 tag。

结果判断与密钥来源

cosign 验证通过，说明该镜像的签名与指定公钥匹配，即可确认你拉取的镜像与官方签名发布的一致；验证不通过则不要继续部署该镜像，并优先检查 <release-tag> 是否与要部署的版本一致、网络是否能访问到 --key 指定的公钥地址。

签名密钥本身就是仓库根目录下的 cosign.pub，内容是一段标准的公钥（BEGIN PUBLIC KEY / END PUBLIC KEY 块），所有 release 共用的就是这一份密钥。

几点边界需要留意：

• README 的签名验证说明针对的是 ghcr.io/berriai/litellm 镜像。仓库中还存在 ghcr.io/berriai/litellm-gateway、litellm-backend、litellm-ui 等组件化镜像（见 terraform/litellm/README.md），README 的签名一节没有针对这些镜像给出单独的验证说明。
• 用 tag 取公钥的方式依赖仓库的 tag 保护规则；如果对密钥不可变性要求最高，使用固定 commit hash 的推荐方式。
• 验证命令需要在能访问 GHCR 的环境中执行；如果目标是离线环境，验证应在拉取镜像的机器上进行，验证通过后再把镜像导入离线环境。