LiteLLM の v1.88.0-dev.1 のリリースノートを眺めていたら、Docker image の署名検証周りの記述が増えていた。cosign を使って全 image に署名するようになったらしい。GitHub の star 数が 48.7k を超えてる今、サプライチェーン周りを整備し始めたのは自然な流れだと思う。
とりあえず試してみた。リリースノートに pinned commit hash を使った方法と release tag を使った方法の 2 パターンが書いてある。推奨は前者で、commit hash は cryptographically immutable だからという理由。確かに tag は後から書き換えられるリスクがあるので、CI に組み込むならコミットハッシュの方が安全だ。
これを叩くと 「cosign claims were validated」「signatures were verified against the specified public key」の 2 行が出てくる。ローカルで動かしてちゃんと通った。自分でも忘れがちだけど、公式 image をそのまま pull して本番に流してる構成って割と普通にある。そこに悪意ある差し替えが入ると気づかない可能性が高い。
今の自分のチームはスタートアップで 8 人のエンジニア構成だ。LiteLLM を proxy として挟んでマルチプロバイダーの cost 管理をしている。OpenAI / Anthropic / Gemini のキーを一箇所で管理できるのが便利で、去年の夏頃から使い始めた。
deploy フローはざっくり GitHub Actions から ECS にデプロイする構成で、image の pull は普通にやっている。正直 cosign での検証は入れていなかった。今回の記事を読んで「あ、ちゃんとやらないといけないな」となった。
やるとしたら Actions の step に cosign の install と verify を差し込む形になる。
environment variable でバージョンを管理して、verify が通らなかったら deploy を止める形にすれば最低限のガードは入る。コスト 0 でできるので入れない理由がない。
リリースノートには他にもいくつか fix が入っている。自分が特に気になったのは 2 つだ。
後者は自分のコードに直接影響する可能性がある。streaming response をキャッシュから返す処理をしていて、ちょっとレスポンスの形式が変わることがある。staging 環境に v1.88 入れてみて挙動を確認しておく必要がある。以前 LiteLLM のマイナーアップデートでレスポンスのフォーマットがじわっと変わって、パースでハマったことがある。あのとき 2 時間溶かしたので、今回は先にちゃんと確認する。
それと Prometheus 周りで user_email と user_alias が user budget metrics に追加された (PR #28155)。自分のチームはユーザーごとのトークン消費を Grafana で可視化しようとしていて、ちょうど欲しかった情報だ。メトリクスのラベルが増えるのは地味にえぐくて、既存のダッシュボードのクエリを直さないといけないけど、長期的には便利になる。
cosign の検証を CI に入れつつ、staging での streaming cache の挙動確認を今週中にやる。セキュリティ系の対応って後回しにしがちだけど、今回みたいに公式がちゃんと仕組みを用意してくれたタイミングで入れてしまうのが一番ラクだ。
cosign 検証、実際どうやるか
とりあえず試してみた。リリースノートに pinned commit hash を使った方法と release tag を使った方法の 2 パターンが書いてある。推奨は前者で、commit hash は cryptographically immutable だからという理由。確かに tag は後から書き換えられるリスクがあるので、CI に組み込むならコミットハッシュの方が安全だ。
cosign verify \
--key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \
ghcr.io/berriai/litellm:v1.88.0-dev.1これを叩くと 「cosign claims were validated」「signatures were verified against the specified public key」の 2 行が出てくる。ローカルで動かしてちゃんと通った。自分でも忘れがちだけど、公式 image をそのまま pull して本番に流してる構成って割と普通にある。そこに悪意ある差し替えが入ると気づかない可能性が高い。
うちのチームの CI に入れるとしたら
今の自分のチームはスタートアップで 8 人のエンジニア構成だ。LiteLLM を proxy として挟んでマルチプロバイダーの cost 管理をしている。OpenAI / Anthropic / Gemini のキーを一箇所で管理できるのが便利で、去年の夏頃から使い始めた。
deploy フローはざっくり GitHub Actions から ECS にデプロイする構成で、image の pull は普通にやっている。正直 cosign での検証は入れていなかった。今回の記事を読んで「あ、ちゃんとやらないといけないな」となった。
やるとしたら Actions の step に cosign の install と verify を差し込む形になる。
- 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 }}environment variable でバージョンを管理して、verify が通らなかったら deploy を止める形にすれば最低限のガードは入る。コスト 0 でできるので入れない理由がない。
他に入った変更で気になったところ
リリースノートには他にもいくつか fix が入っている。自分が特に気になったのは 2 つだ。
- Bedrock の Cohere embedding で embedding_types を JSON array ではなく string で送っていたバグの修正 (PR #28172)
- キャッシュ周りで openai/responses bridge のキャッシュヒットを chat stream として replay する修正 (PR #28158)
後者は自分のコードに直接影響する可能性がある。streaming response をキャッシュから返す処理をしていて、ちょっとレスポンスの形式が変わることがある。staging 環境に v1.88 入れてみて挙動を確認しておく必要がある。以前 LiteLLM のマイナーアップデートでレスポンスのフォーマットがじわっと変わって、パースでハマったことがある。あのとき 2 時間溶かしたので、今回は先にちゃんと確認する。
それと Prometheus 周りで user_email と user_alias が user budget metrics に追加された (PR #28155)。自分のチームはユーザーごとのトークン消費を Grafana で可視化しようとしていて、ちょうど欲しかった情報だ。メトリクスのラベルが増えるのは地味にえぐくて、既存のダッシュボードのクエリを直さないといけないけど、長期的には便利になる。
cosign の検証を CI に入れつつ、staging での streaming cache の挙動確認を今週中にやる。セキュリティ系の対応って後回しにしがちだけど、今回みたいに公式がちゃんと仕組みを用意してくれたタイミングで入れてしまうのが一番ラクだ。