litellm の v1.84.4 リリースノートを眺めていたら、Docker image の署名検証についての説明がやたら丁寧に書いてあった。cosign を使って image を検証する手順が、commit hash 指定と tag 指定の 2 パターンで説明されていた。
個人的にずっと「litellm の Docker image、本当に安全に引っ張れてる？」と思いながらそのままにしていたので、このタイミングで腰を上げた。
リリースノートには「commit hash は cryptographically immutable なので、signing key の確認方法としてこちらが最強」と書いてある。tag は便利だけど tag protection rules に依存するから、セキュリティ上は commit hash の方が信頼できるという話だ。実際に試したのがこれ。
`The cosign claims were validated` と `The signatures were verified against the specified public key` が出れば OK という確認方法で、想像の 3 倍あっさり終わった。今まで「cosign ってなんか難しそう」と後回しにしていたのが正直ハマりポイントだったけど、公開鍵の URL をそのまま渡すだけで動くのはえぐい楽だった。
ちなみに今の自分のチームは 5 人規模で、LLM の API プロキシとして litellm を staging 環境に立ててある。本番はまだ検討中という微妙な状態だ。その staging の compose ファイルが image の digest を pin してなくて、毎回 `latest` に近い運用になっていた。それが気になっていた理由でもある。
リリースノートを読んだあと、まず compose ファイルの image 指定を `v1.84.4` の digest に固定した。そのうえで CI に cosign の verify ステップを足している。
これを GitHub Actions の deploy ジョブの前段に挟んだ。verify が通らなければ deploy が止まる構成にしてある。
チームメンバーに「CI に署名検証入れたよ」と Slack で共有したら「そんなのあったっけ」という反応が返ってきた。LLM 系のライブラリは更新が速いぶん、supply chain のリスクがじわじわ高まっているのは感じていた。今回の v1.84.4 が特に何かインシデントがあったわけではないけど、commit `0112e53` で signing key が導入されてからすべてのリリースが同じ鍵で署名されているという事実は、運用上の信頼ベースになる。
star 数が 48,800 を超えているプロジェクトで、fork も 8,500 以上ある。それだけ使われているなら supply chain 攻撃のターゲットになりやすいとも言える。cosign を入れておくのは普通にやっておきたい話だった。
ここ数週間ずっと litellm の routing 設定を触って、モデルの fallback 順序とかコスト per token の最適化ばかりやっていた。でもその前に image の integrity を担保する方が優先度が高かった気がしている。
彼女に「最近また夜中まで PC 触ってる」と言われたんだけど、「Docker の署名検証してた」と答えたら「何もわからない」と返ってきた。まあそれはそう。でも自分的にはやっと片付いた感覚がある。
litellm を使っている人で、compose や Kubernetes manifest に image digest も cosign verify も入れていないなら、今日のリリースノートは一読する価値がある。
個人的にずっと「litellm の Docker image、本当に安全に引っ張れてる？」と思いながらそのままにしていたので、このタイミングで腰を上げた。
commit hash で verify するのが想像以上にちゃんとしてた
リリースノートには「commit hash は cryptographically immutable なので、signing key の確認方法としてこちらが最強」と書いてある。tag は便利だけど tag protection rules に依存するから、セキュリティ上は commit hash の方が信頼できるという話だ。実際に試したのがこれ。
cosign verify \
--key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \
ghcr.io/berriai/litellm:v1.84.4`The cosign claims were validated` と `The signatures were verified against the specified public key` が出れば OK という確認方法で、想像の 3 倍あっさり終わった。今まで「cosign ってなんか難しそう」と後回しにしていたのが正直ハマりポイントだったけど、公開鍵の URL をそのまま渡すだけで動くのはえぐい楽だった。
ちなみに今の自分のチームは 5 人規模で、LLM の API プロキシとして litellm を staging 環境に立ててある。本番はまだ検討中という微妙な状態だ。その staging の compose ファイルが image の digest を pin してなくて、毎回 `latest` に近い運用になっていた。それが気になっていた理由でもある。
digest pin と署名検証、どっちも入れた
リリースノートを読んだあと、まず compose ファイルの image 指定を `v1.84.4` の digest に固定した。そのうえで CI に cosign の verify ステップを足している。
- name: verify litellm image
run: |
cosign verify \
--key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \
ghcr.io/berriai/litellm:v1.84.4これを GitHub Actions の deploy ジョブの前段に挟んだ。verify が通らなければ deploy が止まる構成にしてある。
チームメンバーに「CI に署名検証入れたよ」と Slack で共有したら「そんなのあったっけ」という反応が返ってきた。LLM 系のライブラリは更新が速いぶん、supply chain のリスクがじわじわ高まっているのは感じていた。今回の v1.84.4 が特に何かインシデントがあったわけではないけど、commit `0112e53` で signing key が導入されてからすべてのリリースが同じ鍵で署名されているという事実は、運用上の信頼ベースになる。
star 数が 48,800 を超えているプロジェクトで、fork も 8,500 以上ある。それだけ使われているなら supply chain 攻撃のターゲットになりやすいとも言える。cosign を入れておくのは普通にやっておきたい話だった。
コスト最適化より先にやることがあった
ここ数週間ずっと litellm の routing 設定を触って、モデルの fallback 順序とかコスト per token の最適化ばかりやっていた。でもその前に image の integrity を担保する方が優先度が高かった気がしている。
彼女に「最近また夜中まで PC 触ってる」と言われたんだけど、「Docker の署名検証してた」と答えたら「何もわからない」と返ってきた。まあそれはそう。でも自分的にはやっと片付いた感覚がある。
litellm を使っている人で、compose や Kubernetes manifest に image digest も cosign verify も入れていないなら、今日のリリースノートは一読する価値がある。