LiteLLMのリリースノートを追いかけていたら、v1.84.5でDocker imageのsignature検証まわりのドキュメントが整備されていた。
チームのプロキシサーバーにLiteLLMを使い始めてから3ヶ月ほど経つ。
そろそろセキュリティ面もちゃんとしなきゃと思っていたタイミングだったので、軽く手を動かしてみた。
リリースノートに書いてあった検証コマンドはこれだ。
commit hash固定でpublic keyを引っ張ってくる方式は地味にえぐい。
tagはprotectedだから書き換えられないという説明もあるが、commit hashは"cryptographically immutable"という表現が使われていて、こっちの方が確実性が高い。
うちのCI/CDパイプラインに突っ込むならhash固定版で行く。
ちなみにコミットIDは `0112e53` が署名鍵を導入した最初のコミットだ。
このhashで公開鍵を固定しているから、鍵ローテーションが起きない限りどのバージョンでも同じコマンドで検証できる設計になっている。
シンプルだけど、ここはよく考えられていると感じた。
今の自分のプロジェクトでは、LiteLLMのDockerイメージをそのままpullしてcompose upするだけで終わっていた。
正直、署名検証なんて「エンタープライズがやること」くらいの認識で、スタートアップの小さなチームでは後回しにしていた部分だ。
でも実際に手を動かしてみると、cosignのインストールから検証まで5分かからない。
GitHub Actionsに入れるとしたらこんな構成が現実的だと思った。
deploy jobの直前に挟めば、改ざんされたイメージを知らずに本番に上げるリスクをほぼ潰せる。
コスト0で実装できることを考えると、やらない理由がない。
うちのチームではLiteLLMをOpenAI互換のプロキシとして立てて、複数のLLM APIを一本化している。
OpenAI・Anthropic・Geminiを用途に応じて使い分けているが、エンドポイントとkey管理をLiteLLMに集約することでコスト追跡もしやすくなった。
最初にこの構成を提案したとき、同僚には「また鈴木が面倒なもの入れようとしてる」と言われた。
でも先月、想定外にAPIのトークン消費が跳ね上がった時に、LiteLLMのログから原因のエンドポイントをすぐ特定できた。
あの時ばかりは「入れておいてよかった」と素直に思った。
ただ、プロキシサーバーがsupply chain attackの対象になることを考えると、イメージ検証は後回しにしていい話ではなかった。
v1.84.5のリリースノートに星49.2kもついているリポジトリが、わざわざcosignの検証手順をドキュメント化してきたのはそういうことだ。
メンテナ側も「ちゃんと検証してくれ」というメッセージを出している。
今週末に、まずローカル環境でcosignの検証フローを一通り試してみる。
問題なければ来週にはCIに組み込んで、チームのdocker-compose.ymlにもversion pinningを徹底するつもりだ。
チームのプロキシサーバーにLiteLLMを使い始めてから3ヶ月ほど経つ。
そろそろセキュリティ面もちゃんとしなきゃと思っていたタイミングだったので、軽く手を動かしてみた。
cosignで署名検証、こんな感じで動く
リリースノートに書いてあった検証コマンドはこれだ。
cosign verify \\
--key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \\
ghcr.io/berriai/litellm:v1.84.5commit hash固定でpublic keyを引っ張ってくる方式は地味にえぐい。
tagはprotectedだから書き換えられないという説明もあるが、commit hashは"cryptographically immutable"という表現が使われていて、こっちの方が確実性が高い。
うちのCI/CDパイプラインに突っ込むならhash固定版で行く。
ちなみにコミットIDは `0112e53` が署名鍵を導入した最初のコミットだ。
このhashで公開鍵を固定しているから、鍵ローテーションが起きない限りどのバージョンでも同じコマンドで検証できる設計になっている。
シンプルだけど、ここはよく考えられていると感じた。
自分のDockerfileとCI、どこを直すか
今の自分のプロジェクトでは、LiteLLMのDockerイメージをそのままpullしてcompose upするだけで終わっていた。
正直、署名検証なんて「エンタープライズがやること」くらいの認識で、スタートアップの小さなチームでは後回しにしていた部分だ。
でも実際に手を動かしてみると、cosignのインストールから検証まで5分かからない。
GitHub Actionsに入れるとしたらこんな構成が現実的だと思った。
- name: Verify LiteLLM image signature
run: |
cosign verify \\
--key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \\
ghcr.io/berriai/litellm:v1.84.5deploy jobの直前に挟めば、改ざんされたイメージを知らずに本番に上げるリスクをほぼ潰せる。
コスト0で実装できることを考えると、やらない理由がない。
LiteLLMをプロキシとして使っている現場の話
うちのチームではLiteLLMをOpenAI互換のプロキシとして立てて、複数のLLM APIを一本化している。
OpenAI・Anthropic・Geminiを用途に応じて使い分けているが、エンドポイントとkey管理をLiteLLMに集約することでコスト追跡もしやすくなった。
最初にこの構成を提案したとき、同僚には「また鈴木が面倒なもの入れようとしてる」と言われた。
でも先月、想定外にAPIのトークン消費が跳ね上がった時に、LiteLLMのログから原因のエンドポイントをすぐ特定できた。
あの時ばかりは「入れておいてよかった」と素直に思った。
ただ、プロキシサーバーがsupply chain attackの対象になることを考えると、イメージ検証は後回しにしていい話ではなかった。
v1.84.5のリリースノートに星49.2kもついているリポジトリが、わざわざcosignの検証手順をドキュメント化してきたのはそういうことだ。
メンテナ側も「ちゃんと検証してくれ」というメッセージを出している。
今週末に、まずローカル環境でcosignの検証フローを一通り試してみる。
問題なければ来週にはCIに組み込んで、チームのdocker-compose.ymlにもversion pinningを徹底するつもりだ。