LiteLLM の v1.86.2 リリースノートを眺めていたら、Docker イメージの署名検証について丁寧に書かれていて、ちょっとハッとした。
うちのチームでは LiteLLM を proxy サーバーとして立てて、OpenAI / Gemini / Anthropic の API を一元管理している。コスト計測とか rate limit の管理がかなり楽になってて、個人的にはかなり気に入ってるセットアップだ。ただ、毎回 `docker pull` してそのまま使ってた。署名検証なんて一切やってなかった。
今回のリリースノートには cosign を使ったイメージ検証の手順が書いてある。commit `0112e53` で導入した signing key を使っていて、推奨は「pinned commit hash で verify する」方法だ。
tag ベースの verify も使えるけど、「cryptographically immutable だから commit hash の方が強い」とリリースノートに明記してある。言われてみると確かにそうで、tag は後から書き換えられる可能性がゼロじゃない。commit hash は変わらない。これは素直に納得した。
ここ最近、社内の LLM 周りのインフラを自分が中心で整備している。proxy サーバーに乗っかってるのはかなりセンシティブな API キーで、OpenAI のキーが漏れたら普通に数十万円単位の被害になりうる。そのリスクを毎回 pull しながら全然気にしてなかったのは、冷静に考えるとまずかった。
サプライチェーン攻撃って話は SolarWinds の件とかで何度も見てきたけど、「自分の使ってる OSS でそれが起きたら」という具体的なイメージが薄かった。今回の cosign の記述を読んで、ようやく自分ごとになった感じがある。
LiteLLM のスター数は執筆時点で 48.5k を超えてて、Fork も 8.4k ある。それなりに広く使われてるライブラリだから、むしろ攻撃対象になるリスクは高い。そういうプロジェクトがちゃんと cosign で signing を整備しているのは、普通にいい取り組みだと思う。
今日の作業で、GitHub Actions の workflow に verify ステップを追加した。こんな感じのシンプルな構成にした。
バージョンは env で管理して、上げるときに一箇所だけ変えれば済む形にした。verify が通らなければそこで落ちるので、意図しないイメージを本番に持ち込む事故は防げる。
とりあえず手元で動かしてみたら、`The cosign claims were validated` と `The signatures were verified against the specified public key` という expected output 通りのメッセージが出て、ちゃんと動いた。ハマるかと思ったけど意外とあっさりだった。
cosign 自体は brew で入るし、CI では `sigstore/cosign-installer` action を使えばすぐ使える。正直もっと早くやっておけばよかった。
これを機に、Dockerfile で使ってるイメージ全体を見直してみると、署名検証をちゃんとサポートしているものとそうでないものがはっきり分かれる。LiteLLM はちゃんとやってるけど、自分のサービスで使ってる別の OSS はそもそも cosign 対応すらしていなかったりする。
すべてに cosign を入れるのは現実的じゃないとしても、API キーを扱うコンポーネントだけでも digest pinning くらいはやっておくべきだと感じた。今週中に Dockerfile の棚卸しをするつもりでいる。
うちのチームでは LiteLLM を proxy サーバーとして立てて、OpenAI / Gemini / Anthropic の API を一元管理している。コスト計測とか rate limit の管理がかなり楽になってて、個人的にはかなり気に入ってるセットアップだ。ただ、毎回 `docker pull` してそのまま使ってた。署名検証なんて一切やってなかった。
今回のリリースノートには cosign を使ったイメージ検証の手順が書いてある。commit `0112e53` で導入した signing key を使っていて、推奨は「pinned commit hash で verify する」方法だ。
cosign verify \
--key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \
ghcr.io/berriai/litellm:v1.86.2tag ベースの verify も使えるけど、「cryptographically immutable だから commit hash の方が強い」とリリースノートに明記してある。言われてみると確かにそうで、tag は後から書き換えられる可能性がゼロじゃない。commit hash は変わらない。これは素直に納得した。
なんでこれが刺さったか
ここ最近、社内の LLM 周りのインフラを自分が中心で整備している。proxy サーバーに乗っかってるのはかなりセンシティブな API キーで、OpenAI のキーが漏れたら普通に数十万円単位の被害になりうる。そのリスクを毎回 pull しながら全然気にしてなかったのは、冷静に考えるとまずかった。
サプライチェーン攻撃って話は SolarWinds の件とかで何度も見てきたけど、「自分の使ってる OSS でそれが起きたら」という具体的なイメージが薄かった。今回の cosign の記述を読んで、ようやく自分ごとになった感じがある。
LiteLLM のスター数は執筆時点で 48.5k を超えてて、Fork も 8.4k ある。それなりに広く使われてるライブラリだから、むしろ攻撃対象になるリスクは高い。そういうプロジェクトがちゃんと cosign で signing を整備しているのは、普通にいい取り組みだと思う。
実際に CI に組み込んだ
今日の作業で、GitHub Actions の workflow に 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 }}バージョンは env で管理して、上げるときに一箇所だけ変えれば済む形にした。verify が通らなければそこで落ちるので、意図しないイメージを本番に持ち込む事故は防げる。
とりあえず手元で動かしてみたら、`The cosign claims were validated` と `The signatures were verified against the specified public key` という expected output 通りのメッセージが出て、ちゃんと動いた。ハマるかと思ったけど意外とあっさりだった。
cosign 自体は brew で入るし、CI では `sigstore/cosign-installer` action を使えばすぐ使える。正直もっと早くやっておけばよかった。
他のライブラリも見直す気になった
これを機に、Dockerfile で使ってるイメージ全体を見直してみると、署名検証をちゃんとサポートしているものとそうでないものがはっきり分かれる。LiteLLM はちゃんとやってるけど、自分のサービスで使ってる別の OSS はそもそも cosign 対応すらしていなかったりする。
- cosign 対応してる: LiteLLM、sigstore 系のツール群など
- digest pinning で代替: 公式イメージは digest をハードコードすることで immutable にできる
- 何もしてない: 正直ここが一番多い
すべてに cosign を入れるのは現実的じゃないとしても、API キーを扱うコンポーネントだけでも digest pinning くらいはやっておくべきだと感じた。今週中に Dockerfile の棚卸しをするつもりでいる。