litellmのリリースノートを眺めていたら、v1.85.2のchangelogよりも上に書いてある「Verify Docker Image Signature」のセクションが目に入った。
Dockerイメージをcosignで署名して、全リリースをcommit `0112e53`で導入した同じ鍵で署名し続けているという話だ。
GitHub Stars 48.4kのプロジェクトがこういうのをちゃんとやってるの、えぐいなと思いながら読み進めた。
自分はここ半年ほど、社内のLLMゲートウェイとしてlitellmを使っている。
モデルをOpenAIからAnthropicに切り替えるとき、APIキーの管理をまとめたいとき、とりあえずlitellmのProxyを立てれば話が早いという感じで運用してきた。
Dockerで立ててるんだけど、正直イメージの検証なんて一度もやったことなかった。
リリースノートにはverifyのやり方が2パターン書いてある。
commitハッシュはcryptographically immutableなので、鍵が差し替えられていないことを保証できる。
タグはタグ保護ルールに依存しているので、GitHubのリポジトリ設定が崩れたら理論上上書きできてしまう。
実際に攻撃されるかどうかはともかく、サプライチェーン攻撃を意識するなら前者一択だ。
これをローカルで打ったら `The cosign claims were validated` が出た。
なるほど、ちゃんと動く。
とりあえず動かしてみるのが好きなので、まずここからやってみた。
問題は「毎回手動で打つ」が続くわけないということだ。
CI上でPull Requestマージ後にDockerイメージをpullして検証、失敗したらデプロイを止める、という構成にしたかった。
`LITELLM_VERSION` はリポジトリのenvに持たせて、バージョンを上げるときはそこだけ変える運用にした。
コミットハッシュ側のURLはv1.85.2以降も同じ鍵を使い続けると明記されているので、ここは固定でいい。
チームにSlackで「litellmのイメージ検証をCIに入れたよ」と流したら、後輩のAくん (入社1年目) が「cosignって何ですか」と聞いてきた。
Sigstoreプロジェクトが作ってるコンテナ署名ツールで、鍵ペアを使ってイメージにサインして後から検証できる仕組みだよ、と説明した。
GitHub ActionsのIDトークンと組み合わせてkeylessで使う方法もあるけど、今回litellm側は公開鍵URLで検証する方式を選んでいる。
そこまで話したらAくんが「なるほど、npm auditみたいなもんですね」と言っていて、まあ近いと思う。
v1.85.2自体のchangelogはcherry-pickが2件だけで、実質パッチリリースだ。
`restore npm to non_root builder` というdockerのfixが含まれているのは地味に助かる。
以前rootで動いてるビルダーコンテナを見て「これ本番使いしていいのか」とハマったことがあったので、non_rootに戻してくれているのは神対応だと思っている。
自分がlitellmに乗っかり続けているのは、モデルの切り替えが楽というのもあるけど、こういうセキュリティまわりをちゃんと整備してくれているからでもある。
Star数が多いOSSだからといって署名されているとは限らない。
次にライブラリを選定するとき、cosign対応しているかどうかをチェック項目に追加しようと決めた。
Dockerイメージをcosignで署名して、全リリースをcommit `0112e53`で導入した同じ鍵で署名し続けているという話だ。
GitHub Stars 48.4kのプロジェクトがこういうのをちゃんとやってるの、えぐいなと思いながら読み進めた。
自分はここ半年ほど、社内のLLMゲートウェイとしてlitellmを使っている。
モデルをOpenAIからAnthropicに切り替えるとき、APIキーの管理をまとめたいとき、とりあえずlitellmのProxyを立てれば話が早いという感じで運用してきた。
Dockerで立ててるんだけど、正直イメージの検証なんて一度もやったことなかった。
cosign verify、ピン留めcommitハッシュ版のほうを使うべき理由
リリースノートにはverifyのやり方が2パターン書いてある。
- pinned commit hash を使う方法 (推奨)
- release tag を使う方法 (convenience)
commitハッシュはcryptographically immutableなので、鍵が差し替えられていないことを保証できる。
タグはタグ保護ルールに依存しているので、GitHubのリポジトリ設定が崩れたら理論上上書きできてしまう。
実際に攻撃されるかどうかはともかく、サプライチェーン攻撃を意識するなら前者一択だ。
cosign verify \\
--key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \\
ghcr.io/berriai/litellm:v1.85.2これをローカルで打ったら `The cosign claims were validated` が出た。
なるほど、ちゃんと動く。
とりあえず動かしてみるのが好きなので、まずここからやってみた。
GitHub Actionsのデプロイフローに組み込んだ
問題は「毎回手動で打つ」が続くわけないということだ。
CI上でPull Requestマージ後にDockerイメージをpullして検証、失敗したらデプロイを止める、という構成にしたかった。
- 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 }}`LITELLM_VERSION` はリポジトリのenvに持たせて、バージョンを上げるときはそこだけ変える運用にした。
コミットハッシュ側のURLはv1.85.2以降も同じ鍵を使い続けると明記されているので、ここは固定でいい。
チームにSlackで「litellmのイメージ検証をCIに入れたよ」と流したら、後輩のAくん (入社1年目) が「cosignって何ですか」と聞いてきた。
Sigstoreプロジェクトが作ってるコンテナ署名ツールで、鍵ペアを使ってイメージにサインして後から検証できる仕組みだよ、と説明した。
GitHub ActionsのIDトークンと組み合わせてkeylessで使う方法もあるけど、今回litellm側は公開鍵URLで検証する方式を選んでいる。
そこまで話したらAくんが「なるほど、npm auditみたいなもんですね」と言っていて、まあ近いと思う。
v1.85.2自体のchangelogはcherry-pickが2件だけで、実質パッチリリースだ。
`restore npm to non_root builder` というdockerのfixが含まれているのは地味に助かる。
以前rootで動いてるビルダーコンテナを見て「これ本番使いしていいのか」とハマったことがあったので、non_rootに戻してくれているのは神対応だと思っている。
自分がlitellmに乗っかり続けているのは、モデルの切り替えが楽というのもあるけど、こういうセキュリティまわりをちゃんと整備してくれているからでもある。
Star数が多いOSSだからといって署名されているとは限らない。
次にライブラリを選定するとき、cosign対応しているかどうかをチェック項目に追加しようと決めた。