LiteLLM が v1.87.2 をリリースした。
パッとリリースノートを見た感じ、今回のメインは「Docker イメージを cosign で検証する仕組みの整備」と、Fable 5・CrowdStrike AIDR・Mantle Responses SigV4 あたりのバックポートだ。
機能追加というより、サプライチェーン的な安心感を固めにいったリリースという印象。
正直、cosign を真面目に使ったことがなかった。
LiteLLM は社内の LLM プロキシ層として最近自分のプロジェクトに組み込んでいて、Docker イメージをそのまま `docker pull` してた。
でもこれ、イメージが改ざんされてたら気づかないやつだ。
それを実感してちょっと焦った。
リリースノートには 2 パターンの verify コマンドが載っている。
commit hash を使う方法と、release tag を使う方法だ。
ノートには「commit hash は cryptographically immutable なので stronger」とはっきり書いてある。
tag は人間が読みやすいが、tag protection に依存するので若干信頼度が落ちる。
というわけで自分は commit hash の方を採用した。
実際のコマンドはこれ。
ローカルで流したら `The cosign claims were validated` と `The signatures were verified against the specified public key` が出て、ちゃんと通った。
これを CI のデプロイ前ステップに挟むだけで、「変なイメージを踏んでた」系の事故はかなり防げる。
自分のプロジェクトは GitHub Actions でデプロイしている。
ステージング環境に LiteLLM コンテナを上げる前のジョブに cosign verify を差し込んだ。
`LITELLM_VERSION` は env に `v1.87.2` を入れてある。
バージョンを上げるときに env だけ書き換えればいい構成にした。
一点ハマったのが、Actions の runner に cosign が入っていないケースで、`setup-cosign` action を先に呼ぶ必要があった。
sigstore の `cosign-installer` を使えば一発なので、実質 2 ステップ追加で済む。
このあたり、最初はドキュメントをちゃんと読まずに `cosign: command not found` で詰まってた。
30 分くらいロスしたのは恥ずかしい。
今回のリリースには CrowdStrike AIDR のバックポートも含まれている。
うちのプロジェクトでは使っていないが、企業向けのセキュリティ文脈で LiteLLM を使っている人には刺さる変更だと思う。
あと Mantle Responses の SigV4 対応も入っていて、AWS 系のサービスと繋ぐ人には地味に助かる更新だ。
そもそも LiteLLM は OpenAI / Anthropic / Gemini など複数プロバイダーの API を統一インターフェースで叩けるプロキシ層だ。
つまりここが汚染されると、全モデルへのリクエストが筒抜けになる。
API キーが全部通るレイヤーなので、セキュリティ的には最もやばいポイントの一つだ。
それをこれまで verify なしで動かしていたのは、冷静に考えると怖い。
彼女に「仕事どう?」って聞かれて「LLM のプロキシ周りを直してた」と答えたら「何それ」って顔をされたが、まあそれくらい地味な変更だ。
でも自分の中では割と重要な直しで、こういうの後回しにすると絶対忘れる。
スター数が 50k を超えてる OSS だからといって、イメージの検証を省略していい理由にはならない。
むしろ人気があるからこそターゲットになりやすいという話でもある。
次のバージョンに上げるときは、commit hash を新しいものに差し替えるだけ。
このワークフロー、他の Docker ベースの依存にも横展開しようと思っている。
パッとリリースノートを見た感じ、今回のメインは「Docker イメージを cosign で検証する仕組みの整備」と、Fable 5・CrowdStrike AIDR・Mantle Responses SigV4 あたりのバックポートだ。
機能追加というより、サプライチェーン的な安心感を固めにいったリリースという印象。
正直、cosign を真面目に使ったことがなかった。
LiteLLM は社内の LLM プロキシ層として最近自分のプロジェクトに組み込んでいて、Docker イメージをそのまま `docker pull` してた。
でもこれ、イメージが改ざんされてたら気づかないやつだ。
それを実感してちょっと焦った。
pinned commit hash と tag、どっちで検証する?
リリースノートには 2 パターンの verify コマンドが載っている。
commit hash を使う方法と、release tag を使う方法だ。
ノートには「commit hash は cryptographically immutable なので stronger」とはっきり書いてある。
tag は人間が読みやすいが、tag protection に依存するので若干信頼度が落ちる。
というわけで自分は commit hash の方を採用した。
実際のコマンドはこれ。
cosign verify \
--key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \
ghcr.io/berriai/litellm:v1.87.2ローカルで流したら `The cosign claims were validated` と `The signatures were verified against the specified public key` が出て、ちゃんと通った。
これを CI のデプロイ前ステップに挟むだけで、「変なイメージを踏んでた」系の事故はかなり防げる。
CI への組み込み、実際どうしたか
自分のプロジェクトは GitHub Actions でデプロイしている。
ステージング環境に LiteLLM コンテナを上げる前のジョブに cosign verify を差し込んだ。
- name: Verify LiteLLM image signature
run: |
cosign verify \
--key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \
ghcr.io/berriai/litellm:${{ env.LITELLM_VERSION }}`LITELLM_VERSION` は env に `v1.87.2` を入れてある。
バージョンを上げるときに env だけ書き換えればいい構成にした。
一点ハマったのが、Actions の runner に cosign が入っていないケースで、`setup-cosign` action を先に呼ぶ必要があった。
sigstore の `cosign-installer` を使えば一発なので、実質 2 ステップ追加で済む。
このあたり、最初はドキュメントをちゃんと読まずに `cosign: command not found` で詰まってた。
30 分くらいロスしたのは恥ずかしい。
今回のリリースには CrowdStrike AIDR のバックポートも含まれている。
うちのプロジェクトでは使っていないが、企業向けのセキュリティ文脈で LiteLLM を使っている人には刺さる変更だと思う。
あと Mantle Responses の SigV4 対応も入っていて、AWS 系のサービスと繋ぐ人には地味に助かる更新だ。
LiteLLM を使い続けるなら cosign は必須だと気づいた
そもそも LiteLLM は OpenAI / Anthropic / Gemini など複数プロバイダーの API を統一インターフェースで叩けるプロキシ層だ。
つまりここが汚染されると、全モデルへのリクエストが筒抜けになる。
API キーが全部通るレイヤーなので、セキュリティ的には最もやばいポイントの一つだ。
それをこれまで verify なしで動かしていたのは、冷静に考えると怖い。
彼女に「仕事どう?」って聞かれて「LLM のプロキシ周りを直してた」と答えたら「何それ」って顔をされたが、まあそれくらい地味な変更だ。
でも自分の中では割と重要な直しで、こういうの後回しにすると絶対忘れる。
スター数が 50k を超えてる OSS だからといって、イメージの検証を省略していい理由にはならない。
むしろ人気があるからこそターゲットになりやすいという話でもある。
次のバージョンに上げるときは、commit hash を新しいものに差し替えるだけ。
このワークフロー、他の Docker ベースの依存にも横展開しようと思っている。