LiteLLMのリリースノートを追いかけるのが最近の習慣になってる。今回の v1.82.3.dev.7 を見て、真っ先に目に止まったのが Docker イメージの署名検証の話だった。
今回のリリースから、すべての LiteLLM Docker イメージが cosign で署名されている。デプロイ前にイメージの完全性を確認するためのコマンドが公式に案内されていて、こういう感じで使う。
公開鍵は GitHub リポジトリ上の cosign.pub を直接参照する形。成功すると「The cosign claims were validated」「The signatures were verified against the specified public key」という出力が返ってくる。これ、地味だけど本番環境に LiteLLM を乗せてるチームには割と大事な変更だと思う。
正直、今まで LiteLLM の Docker イメージを使うとき、署名検証なんてやってなかった。個人開発ならまあいいかと思ってたけど、スタートアップのプロダクトに組み込むなら話が変わる。特に LLM のプロキシ層ってリクエストのログや API キーが通る場所だから、イメージが意図しないものに差し替えられてたら被害がかなりデカい。
CI/CD に組み込むとしたら、Docker pull の直後に cosign verify を挟むのが自然な流れ。GitHub Actions なら sigstore/cosign-installer アクションが使えるので、実装コストもそこまで高くない。自分のリポジトリに取り入れるなら、以下の順番で整理できる。
これだけで「信頼できるイメージしか本番に入らない」という保証が一段増える。チームの設計判断として、導入を提案するネタにもなる。
v1.82.3.dev.7 という番号を見て、dev ビルドかと思って一瞬躊躇した。でも LiteLLM はこの命名規則で開発版を細かくリリースし続けてる。コミット e3d7412 に対して、コミッターの署名も Verified になってる。リリースタイムスタンプは 4月7日 01:10。実際には割と安定して使えることが多いけど、本番に入れるタイミングは自分でちゃんと判断するしかない。
dev タグのイメージをそのまま本番に流すのはさすがに怖いけど、今回の署名検証の仕組みはちゃんと dev 版にも適用されてる。テスト環境で試すときも署名チェックを通す習慣をつけておけば、ステージングから本番まで一貫したフローが作れる。
まず手元の環境で cosign を入れて、イメージの検証を一回手動でやってみることをおすすめしたい。コマンド一発で動くので、5分もあれば確認できる。
cosignで署名検証ができるようになってる
今回のリリースから、すべての LiteLLM Docker イメージが cosign で署名されている。デプロイ前にイメージの完全性を確認するためのコマンドが公式に案内されていて、こういう感じで使う。
cosign verify \
--key https://raw.githubusercontent.com/BerriAI/litellm/v1.82.3.dev.7/cosign.pub \
ghcr.io/berriai/litellm:v1.82.3.dev.7公開鍵は GitHub リポジトリ上の cosign.pub を直接参照する形。成功すると「The cosign claims were validated」「The signatures were verified against the specified public key」という出力が返ってくる。これ、地味だけど本番環境に LiteLLM を乗せてるチームには割と大事な変更だと思う。
自分のデプロイフローのどこに挟むか
正直、今まで LiteLLM の Docker イメージを使うとき、署名検証なんてやってなかった。個人開発ならまあいいかと思ってたけど、スタートアップのプロダクトに組み込むなら話が変わる。特に LLM のプロキシ層ってリクエストのログや API キーが通る場所だから、イメージが意図しないものに差し替えられてたら被害がかなりデカい。
CI/CD に組み込むとしたら、Docker pull の直後に cosign verify を挟むのが自然な流れ。GitHub Actions なら sigstore/cosign-installer アクションが使えるので、実装コストもそこまで高くない。自分のリポジトリに取り入れるなら、以下の順番で整理できる。
- cosign-installer で cosign をセットアップ
- イメージ pull 後に cosign verify を実行
- 検証失敗時はワークフローを即終了させる
これだけで「信頼できるイメージしか本番に入らない」という保証が一段増える。チームの設計判断として、導入を提案するネタにもなる。
リリース番号が「dev」なのは気にしなくていい？
v1.82.3.dev.7 という番号を見て、dev ビルドかと思って一瞬躊躇した。でも LiteLLM はこの命名規則で開発版を細かくリリースし続けてる。コミット e3d7412 に対して、コミッターの署名も Verified になってる。リリースタイムスタンプは 4月7日 01:10。実際には割と安定して使えることが多いけど、本番に入れるタイミングは自分でちゃんと判断するしかない。
dev タグのイメージをそのまま本番に流すのはさすがに怖いけど、今回の署名検証の仕組みはちゃんと dev 版にも適用されてる。テスト環境で試すときも署名チェックを通す習慣をつけておけば、ステージングから本番まで一貫したフローが作れる。
まず手元の環境で cosign を入れて、イメージの検証を一回手動でやってみることをおすすめしたい。コマンド一発で動くので、5分もあれば確認できる。