LiteLLMのリリースノートを眺めていたら、Dockerイメージの署名検証の話が思いのほかしっかり書かれていて、ちょっと立ち止まった。
自分のプロジェクトでLiteLLMをDockerで動かしているけど、正直イメージの署名なんて気にしたことがなかった。「まあ公式が出してるやつだから大丈夫でしょ」って感じで雑にpullしてた。でも今回のリリースノートを読んで、それが少し甘い考えだったかもしれないと思い始めた。
LiteLLMのDockerイメージはcosignで署名されていて、すべてのリリースがコミットハッシュ`0112e53`で導入された同一の鍵で署名されている。リリースノートには2通りの検証方法が書いてある。ひとつはコミットハッシュを固定して検証する方法で、こっちが推奨とされている。
コミットハッシュは暗号学的に不変だから、「本当にあの時点の鍵で署名されたか」を確かめるには一番強い方法、という説明が添えられていた。もうひとつはリリースタグを使う方法で、こっちは読みやすいけどタグの保護ルールに依存している。
これを見て最初に思ったのは、「うちのGitHub Actionsのワークフロー、イメージpullした後に何も確認してないな」ってこと。供給チェーン攻撃の話は最近よく目にするけど、自分のプロジェクトで実際に対策してるかというと、正直できていなかった。
署名の話以外でも、このリリースには気になる変更が入っていた。チームのアクセスグループリソース解決の改善（`feat(teams): resolve access group resources in team endpoints`）と、バーチャルキーのタブでteam_idフィルターがキーエイリアスのドロップダウンに効くようになった修正。自分は複数のLLMプロバイダーをLiteLLMで束ねてチームごとにキー管理しているので、このフィルター周りのバグは地味に気になっていた。バージョン1.83.1から1.83.2へのバンプもこのリリースに含まれている。
nightlyビルドなので本番にそのまま入れるつもりはないけど、この変更が正式リリースに乗ってきたら対応しようと頭の片隅に置いておく。
それより今すぐやりたいのは、cosignの検証をCI/CDに組み込むこと。GitHub Actionsのワークフローで`docker pull`している箇所のすぐ後に`cosign verify`を挟むだけなので、工数は大したことない。問題はcosignをCI環境にインストールするステップを追加する手間と、鍵のURLをハードコードしていいのかという設計の判断くらいだ。
コミットハッシュを固定する方法が推奨されているのも、よく考えると納得感がある。タグは書き換え可能性があるので、「あのリリースで使った鍵と同じか」を厳密に言いたいならハッシュに固定するのが筋だ。自分がライブラリ選定やインフラ設計で「再現性」を重視するのと同じ考え方だと思う。
まず来週、ローカルでcosignのインストールと検証コマンドを試してから、Actionsのワークフローに組み込むところまでやってみるつもりだ。
自分のプロジェクトでLiteLLMをDockerで動かしているけど、正直イメージの署名なんて気にしたことがなかった。「まあ公式が出してるやつだから大丈夫でしょ」って感じで雑にpullしてた。でも今回のリリースノートを読んで、それが少し甘い考えだったかもしれないと思い始めた。
cosignを使った署名検証、具体的に何をやるのか
LiteLLMのDockerイメージはcosignで署名されていて、すべてのリリースがコミットハッシュ`0112e53`で導入された同一の鍵で署名されている。リリースノートには2通りの検証方法が書いてある。ひとつはコミットハッシュを固定して検証する方法で、こっちが推奨とされている。
cosign verify \
--key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \
ghcr.io/berriai/litellm:v1.83.5-nightlyコミットハッシュは暗号学的に不変だから、「本当にあの時点の鍵で署名されたか」を確かめるには一番強い方法、という説明が添えられていた。もうひとつはリリースタグを使う方法で、こっちは読みやすいけどタグの保護ルールに依存している。
これを見て最初に思ったのは、「うちのGitHub Actionsのワークフロー、イメージpullした後に何も確認してないな」ってこと。供給チェーン攻撃の話は最近よく目にするけど、自分のプロジェクトで実際に対策してるかというと、正直できていなかった。
v1.83.5-nightlyの変更内容で自分に関係ありそうな部分
署名の話以外でも、このリリースには気になる変更が入っていた。チームのアクセスグループリソース解決の改善（`feat(teams): resolve access group resources in team endpoints`）と、バーチャルキーのタブでteam_idフィルターがキーエイリアスのドロップダウンに効くようになった修正。自分は複数のLLMプロバイダーをLiteLLMで束ねてチームごとにキー管理しているので、このフィルター周りのバグは地味に気になっていた。バージョン1.83.1から1.83.2へのバンプもこのリリースに含まれている。
nightlyビルドなので本番にそのまま入れるつもりはないけど、この変更が正式リリースに乗ってきたら対応しようと頭の片隅に置いておく。
それより今すぐやりたいのは、cosignの検証をCI/CDに組み込むこと。GitHub Actionsのワークフローで`docker pull`している箇所のすぐ後に`cosign verify`を挟むだけなので、工数は大したことない。問題はcosignをCI環境にインストールするステップを追加する手間と、鍵のURLをハードコードしていいのかという設計の判断くらいだ。
コミットハッシュを固定する方法が推奨されているのも、よく考えると納得感がある。タグは書き換え可能性があるので、「あのリリースで使った鍵と同じか」を厳密に言いたいならハッシュに固定するのが筋だ。自分がライブラリ選定やインフラ設計で「再現性」を重視するのと同じ考え方だと思う。
まず来週、ローカルでcosignのインストールと検証コマンドを試してから、Actionsのワークフローに組み込むところまでやってみるつもりだ。