LiteLLM の v1.89.1 リリースノートを眺めていたら、Docker image の署名検証まわりの記述が思ったより丁寧に書かれていた。
普段 `pip install litellm` で済ませていたけど、最近プロキシサーバーとして Docker で動かすケースが増えてきたので、ちょっとちゃんと読んでみた。
リリースノートに出てくる cosign は Sigstore プロジェクトの一部で、コンテナイメージに暗号署名を付けるためのツールだ。
要するに「このイメージ、本当に公式が出したやつだよ」を検証できる仕組みで、供給チェーン攻撃への対策として使われる。
LiteLLM の場合、commit `0112e53` で導入された公開鍵を使って、全リリースに同じキーで署名している。
検証コマンドはリリースノートに 2 パターン書いてあって、コミットハッシュを直接指定する方法とリリースタグを使う方法がある。
リリースノートには「コミットハッシュは cryptographically immutable だから、こっちが stronger」とはっきり書いてある。
タグは protect されているとはいえ、書き換えられる可能性がゼロではないからな、という話だ。
正直に言うと、うちのチームの docker-compose.yml ではずっとこんな感じで運用してた。
`main-latest` タグ固定。えぐい雑さだ。
社内の LLM プロキシとして動かしていて、複数モデルのコスト集計に使ってるのに、イメージの出所をちゃんと検証したことは一度もなかった。
コスト最適化まわりで LiteLLM を選んだのは、OpenAI 互換の unified endpoint にしながら provider ごとの使用量を key ベースで追えるからだ。
そういう「全 LLM トラフィックが通る場所」に雑なイメージを使うのは、さすがにまずいよなと改めて思った。
スタートアップだと「とりあえず動いてる」でそのまま半年経つ、みたいなことは普通に起きる。
3 人しかいないバックエンドチームで、インフラを本業にしてるメンバーがいないのもある。
でも今回のリリースノートを読んで、cosign の verify を CI に組み込むだけなら 30 分もかからないな、と気づいた。
今すぐやることをざっくりまとめるとこんな感じだ。
v1.89.1 の changelog 自体は「backport 1.84.8 patch set + MCP/model-info/DB fixes」という内容で、MCP まわりと DB 周辺のバグ修正がメインだった。
star 数は 50.5k、fork は 8.9k まで伸びてて、もうかなりのエコシステムになってきてる。
これだけ使われてるプロキシのイメージを、verify もせず latest で引っ張るのは流石に怖い。
個人開発でも API コスト管理のために LiteLLM を使おうとしてたところで、そっちにも同じ設定を横展開するつもりだ。
どうせ GitHub Actions を書くなら一回ちゃんと作って、両方に使い回す構成にする。
ソフトウェアの品質は「動くかどうか」だけじゃなくて「何を流してるかわかってるか」でも決まると、今日のリリースノート 1 ページで思い直した。
普段 `pip install litellm` で済ませていたけど、最近プロキシサーバーとして Docker で動かすケースが増えてきたので、ちょっとちゃんと読んでみた。
cosign って何者だっけ
リリースノートに出てくる cosign は Sigstore プロジェクトの一部で、コンテナイメージに暗号署名を付けるためのツールだ。
要するに「このイメージ、本当に公式が出したやつだよ」を検証できる仕組みで、供給チェーン攻撃への対策として使われる。
LiteLLM の場合、commit `0112e53` で導入された公開鍵を使って、全リリースに同じキーで署名している。
検証コマンドはリリースノートに 2 パターン書いてあって、コミットハッシュを直接指定する方法とリリースタグを使う方法がある。
# コミットハッシュ指定 (推奨)
cosign verify \\
--key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \\
ghcr.io/berriai/litellm:v1.89.1リリースノートには「コミットハッシュは cryptographically immutable だから、こっちが stronger」とはっきり書いてある。
タグは protect されているとはいえ、書き換えられる可能性がゼロではないからな、という話だ。
自分のリポジトリ、どう使ってたかを振り返る
正直に言うと、うちのチームの docker-compose.yml ではずっとこんな感じで運用してた。
services:
litellm:
image: ghcr.io/berriai/litellm:main-latest
ports:
- "4000:4000"`main-latest` タグ固定。えぐい雑さだ。
社内の LLM プロキシとして動かしていて、複数モデルのコスト集計に使ってるのに、イメージの出所をちゃんと検証したことは一度もなかった。
コスト最適化まわりで LiteLLM を選んだのは、OpenAI 互換の unified endpoint にしながら provider ごとの使用量を key ベースで追えるからだ。
そういう「全 LLM トラフィックが通る場所」に雑なイメージを使うのは、さすがにまずいよなと改めて思った。
スタートアップだと「とりあえず動いてる」でそのまま半年経つ、みたいなことは普通に起きる。
3 人しかいないバックエンドチームで、インフラを本業にしてるメンバーがいないのもある。
でも今回のリリースノートを読んで、cosign の verify を CI に組み込むだけなら 30 分もかからないな、と気づいた。
next action として整理したこと
今すぐやることをざっくりまとめるとこんな感じだ。
- `main-latest` をやめて固定バージョンタグ (`v1.89.1` など) を使う
- cosign の verify ステップを GitHub Actions のデプロイワークフローに追加する
- LiteLLM のリリースページを RSS かなにかで追いかけて、パッチバージョンの changelog を見る習慣をつける
v1.89.1 の changelog 自体は「backport 1.84.8 patch set + MCP/model-info/DB fixes」という内容で、MCP まわりと DB 周辺のバグ修正がメインだった。
star 数は 50.5k、fork は 8.9k まで伸びてて、もうかなりのエコシステムになってきてる。
これだけ使われてるプロキシのイメージを、verify もせず latest で引っ張るのは流石に怖い。
個人開発でも API コスト管理のために LiteLLM を使おうとしてたところで、そっちにも同じ設定を横展開するつもりだ。
どうせ GitHub Actions を書くなら一回ちゃんと作って、両方に使い回す構成にする。
ソフトウェアの品質は「動くかどうか」だけじゃなくて「何を流してるかわかってるか」でも決まると、今日のリリースノート 1 ページで思い直した。