LiteLLMのリリースノートを追いかけていたら、v1.83.14-stable.patch.1で地味に重要な変更が入っていることに気づいた。Dockerイメージの署名検証の仕組みが整備されていて、cosignを使って配布イメージの正当性を確かめられるようになっている。
普段LLMのAPIコストを抑えるためにLiteLLMをプロキシとして使っている自分としては、これは見逃せないアップデートだった。自分のスタートアップでも、社内のLLMルーティング基盤にLiteLLMを載せているし、Dockerで動かしているから直接関係する話だ。
今回のリリースで強調されているのは、Dockerイメージが改ざんされていないかをcosignで検証できる点だ。LiteLLMのすべてのDockerイメージはcosignで署名されていて、署名に使う鍵はコミット `0112e53` で導入されたものに統一されている。
検証方法は2種類ある。推奨されているのはコミットハッシュを使う方法で、こんなコマンドを叩く。
コミットハッシュは暗号学的に不変なので、「本当にオリジナルの署名鍵を使っているか」を確認する最も確実な手段だとリリースノートに書いてある。もう一つはタグ名を使う方法で、読みやすいけどタグの保護ルールに依存する形になる。
正直、今まで自分のプロジェクトではDockerイメージの署名なんてほぼ意識していなかった。docker pullして動けばOK、くらいの感覚でいた。でも社内でLLMのAPIキーをLiteLLMプロキシ経由で扱っているとなると、話が変わってくる。
サプライチェーン攻撃というのは、使っているOSSや依存ライブラリを汚染して侵入してくるやつだ。イメージが改ざんされていたら、APIキーが外に漏れる経路を作ってしまいかねない。特にGitHub Actionsで自動デプロイしているなら、デプロイ前の検証ステップを入れておくべきだと思った。
具体的には、CIのデプロイジョブの中にcosignのverifyステップを追加して、検証が通らなければデプロイを止める仕組みを作りたい。コミットハッシュで固定する方法は少し手間だけど、tagのピン止めと同じ感覚で扱えばいいはずだ。
依存ライブラリのバージョンをpinするのがもはや当たり前になったように、Dockerイメージの署名検証もそのうち当たり前の工程になっていくと思う。今はまだ「やっている人は意識高い」くらいの温度感かもしれないが、そのうちレビューで「なんでverifyしてないの？」って言われる日が来そうだ。
GitHubのスター数が45.7kまで伸びているLiteLLMは、使っている人が多い分だけセキュリティの穴があったときのインパクトも大きい。自分もユーザーとして、こういう仕組みがちゃんと整備されていくのは素直にありがたい。
自分はまず来週、ローカルでcosignのverifyコマンドを実際に叩いてみるつもりだ。その後、CIへの組み込みをどう実装するかを考えていく。
普段LLMのAPIコストを抑えるためにLiteLLMをプロキシとして使っている自分としては、これは見逃せないアップデートだった。自分のスタートアップでも、社内のLLMルーティング基盤にLiteLLMを載せているし、Dockerで動かしているから直接関係する話だ。
cosignで何ができるのか
今回のリリースで強調されているのは、Dockerイメージが改ざんされていないかをcosignで検証できる点だ。LiteLLMのすべてのDockerイメージはcosignで署名されていて、署名に使う鍵はコミット `0112e53` で導入されたものに統一されている。
検証方法は2種類ある。推奨されているのはコミットハッシュを使う方法で、こんなコマンドを叩く。
cosign verify \
--key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \
ghcr.io/berriai/litellm:v1.83.14-stable.patch.1コミットハッシュは暗号学的に不変なので、「本当にオリジナルの署名鍵を使っているか」を確認する最も確実な手段だとリリースノートに書いてある。もう一つはタグ名を使う方法で、読みやすいけどタグの保護ルールに依存する形になる。
自分のCIパイプラインをどう直すか
正直、今まで自分のプロジェクトではDockerイメージの署名なんてほぼ意識していなかった。docker pullして動けばOK、くらいの感覚でいた。でも社内でLLMのAPIキーをLiteLLMプロキシ経由で扱っているとなると、話が変わってくる。
サプライチェーン攻撃というのは、使っているOSSや依存ライブラリを汚染して侵入してくるやつだ。イメージが改ざんされていたら、APIキーが外に漏れる経路を作ってしまいかねない。特にGitHub Actionsで自動デプロイしているなら、デプロイ前の検証ステップを入れておくべきだと思った。
具体的には、CIのデプロイジョブの中にcosignのverifyステップを追加して、検証が通らなければデプロイを止める仕組みを作りたい。コミットハッシュで固定する方法は少し手間だけど、tagのピン止めと同じ感覚で扱えばいいはずだ。
依存ライブラリのバージョンをpinするのがもはや当たり前になったように、Dockerイメージの署名検証もそのうち当たり前の工程になっていくと思う。今はまだ「やっている人は意識高い」くらいの温度感かもしれないが、そのうちレビューで「なんでverifyしてないの？」って言われる日が来そうだ。
GitHubのスター数が45.7kまで伸びているLiteLLMは、使っている人が多い分だけセキュリティの穴があったときのインパクトも大きい。自分もユーザーとして、こういう仕組みがちゃんと整備されていくのは素直にありがたい。
自分はまず来週、ローカルでcosignのverifyコマンドを実際に叩いてみるつもりだ。その後、CIへの組み込みをどう実装するかを考えていく。