LiteLLM の v1.87.0-dev.1 がリリースされた。個人開発で LiteLLM を使い始めてそろそろ 3 ヶ月になる。最初は「複数の LLM を同一インターフェースで叩けるやつ」くらいの認識だったけど、OpenAI と Anthropic を切り替えながらコスト比較するのに神すぎて今や手放せない。
で、今回のリリースノートを読んでいて地味に目に止まったのが冒頭の Docker イメージ署名の話だ。LiteLLM は全 Docker イメージを cosign で署名していて、コミット `0112e53` から同一キーを使い続けているとある。Star 数が 47.7k まで来たライブラリなら、サプライチェーン攻撃のターゲットになるリスクも普通に上がる。ちゃんと署名してるのは素直にえぐいと思った。
リリースノートには 2 通りの verify 方法が書いてある。タグ指定と commit hash 指定だ。推奨は commit hash の方で、理由は「タグは書き換えられる可能性があるが、commit hash は暗号的に不変だから」と明記されている。確かにそうで、タグが差し替えられたら別のキーで署名したイメージを掴まされる可能性がある。
これを手元で試してみた。成功すると「The cosign claims were validated」「The signatures were verified against the specified public key」の 2 行が出る。出た。とりあえず動いた。
正直に言うと、これまで LiteLLM を Docker で使うとき cosign の検証なんて一度もやったことがなかった。開発環境だから「まあいいか」で pull してそのまま使ってた。でも今の会社のスタートアップ、最近本番 API のプロキシとして LiteLLM を使い始めていて、そこに認証情報やらレート制限やらを乗せるようになってきた。それで「さすがに無検証はまずいかも」という気持ちが芽生えてきたタイミングでこのリリースを見た、という感じだ。
v1.87.0-dev.1 の変更点のうち、自分の環境に刺さるのはこのあたりだ。
embedding_types のやつは素直にハマってた可能性がある。Cohere の embed-multilingual-v3.0 を Bedrock 経由で叩いて embedding_types を渡したとき、結果がおかしかった記憶がある。あのとき自分のコードを疑って 1 時間溶かしたんだけど、ライブラリ側のバグだったなら徒労だったな、という気持ちだ。
とりあえず手元で動かせたので、次は CI に差し込みたい。今うちのチームは GitHub Actions でデプロイしているから、LiteLLM のイメージを pull する前に cosign verify を挟むステップを追加するだけでいい。大した工数じゃない。
バージョンを env で管理しておけば bumping も楽だし、検証が通らなければデプロイが止まる。これをやっておくだけで「イメージが差し替えられていた」という最悪のシナリオを CI の段階で弾ける。
彼女に「また深夜に何やってるの」と言われながら検証コマンドを叩いていたんだけど、「LLM の API を本番に置いてる以上、使うライブラリのイメージ検証くらいはやっておきたくて」と答えたら「よくわからないけど大事なやつね」と言われた。そうなんだよ、大事なやつなんだよ。
こういうセキュリティ周りの作業は地味だし、何も起きなければ評価もされない。でも何か起きてからでは遅い。LiteLLM が cosign を全リリースで使い続けているなら、使う側もそれを活かさないともったいない。まず今週の PR に verify ステップを入れる。
で、今回のリリースノートを読んでいて地味に目に止まったのが冒頭の Docker イメージ署名の話だ。LiteLLM は全 Docker イメージを cosign で署名していて、コミット `0112e53` から同一キーを使い続けているとある。Star 数が 47.7k まで来たライブラリなら、サプライチェーン攻撃のターゲットになるリスクも普通に上がる。ちゃんと署名してるのは素直にえぐいと思った。
pinned commit hash で検証するのが推奨らしい
リリースノートには 2 通りの verify 方法が書いてある。タグ指定と commit hash 指定だ。推奨は commit hash の方で、理由は「タグは書き換えられる可能性があるが、commit hash は暗号的に不変だから」と明記されている。確かにそうで、タグが差し替えられたら別のキーで署名したイメージを掴まされる可能性がある。
cosign verify \
--key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \
ghcr.io/berriai/litellm:v1.87.0-dev.1これを手元で試してみた。成功すると「The cosign claims were validated」「The signatures were verified against the specified public key」の 2 行が出る。出た。とりあえず動いた。
正直に言うと、これまで LiteLLM を Docker で使うとき cosign の検証なんて一度もやったことがなかった。開発環境だから「まあいいか」で pull してそのまま使ってた。でも今の会社のスタートアップ、最近本番 API のプロキシとして LiteLLM を使い始めていて、そこに認証情報やらレート制限やらを乗せるようになってきた。それで「さすがに無検証はまずいかも」という気持ちが芽生えてきたタイミングでこのリリースを見た、という感じだ。
今回の fix で実務に関係するやつ
v1.87.0-dev.1 の変更点のうち、自分の環境に刺さるのはこのあたりだ。
- fix(proxy): gate team allowed_passthrough_routes to proxy admins に変更 — チームごとのルーティング制御をプロキシ管理者に限定するやつ。複数チームでキーを分けて使ってると関係する
- fix(bedrock/cohere): embedding_types を JSON array で送るように修正 — string で送ってたのがバグだったらしい。Cohere を Bedrock 経由で試してたときになんか挙動が変だな、と思ってたのはこれかもしれない
- fix(caching): openai/responses bridge のキャッシュヒットを chat stream として replay — responses API 経由のキャッシュがちゃんと動くようになったぽい
embedding_types のやつは素直にハマってた可能性がある。Cohere の embed-multilingual-v3.0 を Bedrock 経由で叩いて embedding_types を渡したとき、結果がおかしかった記憶がある。あのとき自分のコードを疑って 1 時間溶かしたんだけど、ライブラリ側のバグだったなら徒労だったな、という気持ちだ。
CI に cosign の verify を組み込もうとしている
とりあえず手元で動かせたので、次は CI に差し込みたい。今うちのチームは GitHub Actions でデプロイしているから、LiteLLM のイメージを pull する前に 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 }}バージョンを env で管理しておけば bumping も楽だし、検証が通らなければデプロイが止まる。これをやっておくだけで「イメージが差し替えられていた」という最悪のシナリオを CI の段階で弾ける。
彼女に「また深夜に何やってるの」と言われながら検証コマンドを叩いていたんだけど、「LLM の API を本番に置いてる以上、使うライブラリのイメージ検証くらいはやっておきたくて」と答えたら「よくわからないけど大事なやつね」と言われた。そうなんだよ、大事なやつなんだよ。
こういうセキュリティ周りの作業は地味だし、何も起きなければ評価もされない。でも何か起きてからでは遅い。LiteLLM が cosign を全リリースで使い続けているなら、使う側もそれを活かさないともったいない。まず今週の PR に verify ステップを入れる。