LiteLLM の v1.86.3 リリースノートを眺めていたら、Docker イメージの署名検証の話が冒頭にどかっと書かれていた。cosign で署名して、公開鍵を pinned commit hash で検証する、というやつ。正直これまで自分のローカル開発では `docker pull` して終わりにしていたので、ちょっと刺さった。
リリースノートを読むと、署名に使われる鍵はコミット `0112e53` で導入されたものに統一されていて、タグではなくコミットハッシュで公開鍵を参照するほうが推奨されている。タグはリポジトリの保護ルールに依存するから「便利だけど信頼の根拠が違う」という整理だ。細かいけど、このあたりの設計の説明がちゃんとリリースノートに入っているのがえぐい。普通こういうの README に埋もれるか、ドキュメントサイトに移譲されるかのどちらかだと思っていた。
このコマンドを手元で実際に叩いてみた。cosign が入っていなかったので `brew install cosign` から始めたのはご愛嬌として、検証が通ったときの出力はちゃんと「The cosign claims were validated」と返ってきた。動いた瞬間は素直に「あ、神だな」と思った。
今チームで LiteLLM を使っているのは、複数の LLM プロバイダを統一インターフェースで叩くためのプロキシとして、という用途だ。OpenAI と Anthropic と Gemini を同じコードから切り替えて使いたいケースがあって、LiteLLM はそこにはまる。本番の Kubernetes クラスタに乗っているわけではないけど、staging 環境では Docker Compose でそこそこ動かしている。
その staging で使っているイメージ、バージョン固定はしていたけど署名検証は一切やっていなかった。CI のステップに cosign verify を入れているプロジェクトを見たことはあったが、自分のチームの運用では「まあ公式から pull してるし」で済ませていた。今回のリリースノートで改めて「これをちゃんとやれ」という意識になった。
やることは単純で、GitHub Actions の workflow に検証ステップを一個追加するだけだ。
これだけで、pull したイメージが改ざんされていないことをデプロイ前に確認できる。コスト ゼロ、作業 10 分のやつだ。なのにやっていなかった、というのが少し恥ずかしい。
LiteLLM はプロキシとして動かすと、各プロバイダへの API キーをそのコンテナが持つ構成になる。つまりコンテナが汚染されたら API キーが全部アウトになる。OpenAI の API キーが漏れたら、悪用されるまでの間にどれだけコストが膨らむかわからない。個人の趣味プロジェクトで使っている人ならもっとシビアに考えたほうがいい話だ。
自分は彼女から「なんでそんな細かいところ気にするの」とよく言われるんだけど、ちょうどこういう話を夕食のときにしたら「鍵のかかってない家に住むようなもんでしょ」と言われた。わかりやすくて笑った。そのたとえ、チームへの説明にも使える。
リリース自体は v1.84.x と v1.85.x の修正を v1.86.x に backport してきたパッチリリースで、機能追加はない。ただセキュリティ運用を整備するきっかけとしては十分だった。LiteLLM のスター数が 49.2k を超えているということは、同じ構成で動かしているチームが世界中にいるはずで、そのうちどのくらいが署名検証をやっているかは気になるところだ。
とりあえず今週中に PR を出して、CI に cosign verify を入れる。それだけで「やった」と言える状態になれる。
リリースノートを読むと、署名に使われる鍵はコミット `0112e53` で導入されたものに統一されていて、タグではなくコミットハッシュで公開鍵を参照するほうが推奨されている。タグはリポジトリの保護ルールに依存するから「便利だけど信頼の根拠が違う」という整理だ。細かいけど、このあたりの設計の説明がちゃんとリリースノートに入っているのがえぐい。普通こういうの README に埋もれるか、ドキュメントサイトに移譲されるかのどちらかだと思っていた。
cosign verify \
--key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \
ghcr.io/berriai/litellm:v1.86.3このコマンドを手元で実際に叩いてみた。cosign が入っていなかったので `brew install cosign` から始めたのはご愛嬌として、検証が通ったときの出力はちゃんと「The cosign claims were validated」と返ってきた。動いた瞬間は素直に「あ、神だな」と思った。
自分たちのプロジェクトへの影響
今チームで LiteLLM を使っているのは、複数の LLM プロバイダを統一インターフェースで叩くためのプロキシとして、という用途だ。OpenAI と Anthropic と Gemini を同じコードから切り替えて使いたいケースがあって、LiteLLM はそこにはまる。本番の Kubernetes クラスタに乗っているわけではないけど、staging 環境では Docker Compose でそこそこ動かしている。
その staging で使っているイメージ、バージョン固定はしていたけど署名検証は一切やっていなかった。CI のステップに cosign verify を入れているプロジェクトを見たことはあったが、自分のチームの運用では「まあ公式から pull してるし」で済ませていた。今回のリリースノートで改めて「これをちゃんとやれ」という意識になった。
やることは単純で、GitHub Actions の workflow に検証ステップを一個追加するだけだ。
- 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 }}これだけで、pull したイメージが改ざんされていないことをデプロイ前に確認できる。コスト ゼロ、作業 10 分のやつだ。なのにやっていなかった、というのが少し恥ずかしい。
LLM プロキシ層のセキュリティをどう考えるか
LiteLLM はプロキシとして動かすと、各プロバイダへの API キーをそのコンテナが持つ構成になる。つまりコンテナが汚染されたら API キーが全部アウトになる。OpenAI の API キーが漏れたら、悪用されるまでの間にどれだけコストが膨らむかわからない。個人の趣味プロジェクトで使っている人ならもっとシビアに考えたほうがいい話だ。
自分は彼女から「なんでそんな細かいところ気にするの」とよく言われるんだけど、ちょうどこういう話を夕食のときにしたら「鍵のかかってない家に住むようなもんでしょ」と言われた。わかりやすくて笑った。そのたとえ、チームへの説明にも使える。
リリース自体は v1.84.x と v1.85.x の修正を v1.86.x に backport してきたパッチリリースで、機能追加はない。ただセキュリティ運用を整備するきっかけとしては十分だった。LiteLLM のスター数が 49.2k を超えているということは、同じ構成で動かしているチームが世界中にいるはずで、そのうちどのくらいが署名検証をやっているかは気になるところだ。
とりあえず今週中に PR を出して、CI に cosign verify を入れる。それだけで「やった」と言える状態になれる。