LiteLLM v1.87のcosign対応、自分のDocker運用を見直した

鈴木 蓮
鈴木 蓮 20代・ ソフトウェアエンジニア
LiteLLM の v1.87.0-rc.1 のリリースノートを読んでいて、一番目に止まったのが cosign によるイメージ署名の話だった。

うちのチームは LiteLLM を proxy として社内に立てていて、OpenAI / Gemini / Claude をまとめてルーティングしている。コスト管理のために litellm の spend_counter を使っているし、モデルによって routing を切り替えているので、正直 LiteLLM がないと今のアーキテクチャは成立しない。そのわりにイメージの署名検証なんて一回もやったことがなかった。

cosign 検証、とりあえず手元で動かしてみた



リリースノートには推奨手順として commit hash を使った検証方法が載っていた。タグより hash の方が cryptographically immutable で安全、という説明で、確かにその通りだと思う。タグは force push で書き換えられるけど commit hash は変わらない。

cosign verify \
  --key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \
  ghcr.io/berriai/litellm:v1.87.0-rc.1

これをローカルで叩いたら普通に通った。cosign 自体は homebrew で入れたことがあったので詰まらなかったが、CI に組み込んでいない環境でただ docker pull してるだけだったのはちょっとまずかったなと反省している。

うちの deploy フローは GitHub Actions で image を pull して ECS に投げる構成になっている。その Actions の step に cosign verify を挟んでいなかった。LiteLLM は star 数 48k、fork 数 8.3k あるくらい使われているライブラリだから信頼はしているが、supply chain attack のリスクはゼロじゃない。

今回のリリースで実際に直すコード



セキュリティの話以外で気になったのが spend_counter の fix だった。Redis counter を SET NX でシードするように変えたというやつで、これは cross-pod での double-seed を防ぐためのものだ。

うちは ECS で複数タスクを走らせているので、この問題モロに踏んでいた可能性がある。spend のカウントがズレることがあって、Slack に飛ばしているコストアラートが微妙に信頼できない感覚があった。チームメンバーと「たまにおかしくない?」って話してたやつがこれだったのかもしれない。RC だけど早めに試したい。

あと gemini-3.1-flash-lite のコストマップが追加されたのも地味に助かる。自分で model のコスト設定を手書きで書いていたので、公式のマップに乗ってくれると管理が楽になる。

model_list:
  - model_name: gemini-flash-lite
    litellm_params:
      model: gemini/gemini-3.1-flash-lite
      api_key: os.environ/GEMINI_API_KEY

こういう設定をずっと書いていたけど、コストが公式に乗ることでダッシュボードの spend 表示が正確になる。今まで Unknown cost みたいな表示になっていたモデルが減るはず。

CI に cosign を足す方針を決めた



とりあえず今週の作業として Actions の deploy.yml に cosign verify を入れることにした。手順としては cosign の binary を step でインストールして、docker pull の前に verify を挟む。失敗したら deploy を止める。

これが意外と後回しにしがちな作業で、動いているものを触るのが億劫で放置してしまう。でも今回のリリースノートに丁寧に手順が書いてあったのでやるモチベーションになった。LiteLLM チームが commit `0112e53` を signing key の起点として明示しているのも、どこから信頼の連鎖が始まるかが明確で好感が持てる。

彼女に「週末どっか行こう」と言われているが、土曜の午前中はこの作業を先に片付けてから出かけるつもりだ。ちょうど spend_counter の fix も確認したいし、RC で動かして問題なければ本番反映まで持っていきたい。

supply chain の問題は一回やらかしてから対処するより、地味でも事前にやっておく方が絶対に楽だ。

無料相談受付中

AI開発・DX推進についてお気軽にご相談ください。オンライン30分から。

無料相談を申し込む