LiteLLMがv1.86.7をリリースした。変更差分を見てみたら、今回のメインはUIのdashboardビルド成果物の更新とバックポートいくつか、という地味なパッチリリースだ。ただ、リリースノートにがっつり書いてあるcosignによるDockerイメージの署名検証、これが前から気になっていたので今回ちゃんと触ってみた。
うちのチームはLiteLLMをプロキシとして使っていて、OpenAIやAnthropicなど複数のLLM APIを束ねている。コスト管理がしやすいのとモデル切り替えが楽なのが理由だ。ただ正直、Dockerイメージの署名検証なんてCI上でちゃんとやってなかった。本番で動かしているのに、イメージの出所を信頼しきっていたのはさすがにまずいなとうっすら思っていた。
commit hashで検証するのが一番安全という話
リリースノートに2種類の検証方法が書いてある。タグ指定とcommit hash指定だ。「commit hashは暗号学的に不変だからこちらを推奨」とドキュメントに書いてあって、これは確かにそうだなと思った。タグはリポジトリの保護設定に依存するので、運用ミスや悪意ある変更でずれる可能性がゼロじゃない。対してcommit hashは書き換わらない。
実際に試した検証コマンドはこれだ。
cosign verify \
--key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \
ghcr.io/berriai/litellm:v1.86.7ローカルで動かしたらちゃんと「The cosign claims were validated」と出た。えぐいくらいあっさり通った。cosignの存在は知っていたけど、実際に手を動かしたのは今回が初めてだった。これだけで済むなら早く組み込めばよかった。
CIパイプラインに組み込んだ
とりあえずGitHub Actionsのdeployワークフローに差し込んだ。imageをpullする前にcosignで検証するステップを追加した形だ。
- 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.LITELLM_VERSIONは別途管理しているバージョン変数だ。これで検証が失敗したらdeployが止まるようになった。コード自体は10行も書いてない。でも「検証してないまま本番に流している」という状態から抜け出せたのは大きい。
ちなみに、cosignをrunnerにインストールする必要があって、そこだけ少しハマった。GitHub Actionsのubuntu-latestにはデフォルトで入っていない。sigstore/cosign-installerというActionを使うと一発で解決する。これはXで拾った情報で助かった。
LiteLLMを触り始めた経緯と今の使い方
LiteLLMを導入したのは3ヶ月前くらいだ。当時、チームでモデルをClaude 3.5 SonnetとGPT-4oで使い分けていたが、それぞれのSDKを直接呼び出していた。APIキーが各サービスに散らばっていて、コスト集計が地獄だった。LiteLLMのプロキシを挟んだら、APIキーの管理が一元化できてコスト可視化もダッシュボードで追えるようになった。神ツールだと思ってる。
今回のv1.86.7はダッシュボードのビルド成果物も更新されているので、UIの細かいバグが直っている可能性がある。うちのチームは非エンジニアのメンバーもLiteLLMのダッシュボードを見てコスト確認しているので、UI周りのアップデートはわりと影響がある。次のスプリントでイメージバージョンを上げる予定だ。
今回cosignの検証を組み込んでみて改めて思ったのは、OSSのプロキシを本番で動かすならsupply chain周りのケアは外せないということだ。LiteLLMはStar数が51.6kある人気プロジェクトだし、依存しているチームも多い。それだけ攻撃対象として魅力的でもある。パッチリリースでも署名検証の仕組みが整備されているのは、プロジェクトの姿勢として信頼できる。
次は自分の個人開発プロジェクトでも同じ仕組みを入れてみるつもりだ。本番で動かしているものがあるなら、一度リリースノートをちゃんと読んでみるといい。意外と自分のCI設計の穴に気づく。