[{"data":1,"prerenderedAt":281},["ShallowReactive",2],{"blog-ja-kubernetes-image-signing-sigstore-supply-chain":3,"blog-related-ja-kubernetes-image-signing-sigstore-supply-chain":231,"blog-ja-kubernetes-image-signing-sigstore-supply-chain-alt":220},{"id":4,"title":5,"author":6,"body":7,"date":214,"description":215,"extension":216,"image":217,"locale":218,"meta":219,"navigation":220,"path":221,"seo":222,"stem":223,"tags":224,"__hash__":230},"blog\u002Fblog\u002Fja\u002Fkubernetes-image-signing-sigstore-supply-chain.md","イメージタグは誰でも書き換えられる。Kubernetesのイメージ署名にSigstoreで『来歴』を刻むという発想","Kubo Team",{"type":8,"value":9,"toc":205},"minimark",[10,15,23,26,29,40,44,50,61,74,77,81,87,90,93,105,117,129,132,141,145,151,159,168,177,183,186,189,192],[11,12,14],"h2",{"id":13},"cicdの密封された箱神話-テストに通ったのはそのイメージなのか","CI\u002FCDの「密封された箱」神話 — テストに通ったのは\"そのイメージ\"なのか",[16,17,18],"p",{},[19,20],"img",{"alt":21,"src":22},"CI\u002FCDパイプラインの一般的な流れと「本当にこのイメージなのか」という疑問符","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-image-signing-sigstore-supply-chain\u002Fsection01.webp",[16,24,25],{},"コンテナイメージは「一度ビルドすれば、どこに持っていっても同じように動く」という前提のもとで信頼されています。テストをパスしたコードがイメージにパッケージ化され、そのままレジストリを経由してKubernetesクラスタへ届く。この一連の流れがCI\u002FCDパイプラインの基本形です。",[16,27,28],{},"しかし、多くの現場が見落としている問いがあります。「クラスタが実行しているイメージは、本当にCIがテストしたビルド成果物と同一なのか」という点です。コンテナイメージ署名を検証する仕組みがなければ、この問いに答えることはできません。",[16,30,31,32,39],{},"CNCFのソフトウェアサプライチェーンセキュリティに関する取り組みでも、オープンソースコンポーネント・コンテナイメージ・Helmチャート・サードパーティのCI\u002FCDアクションが積み重なることで依存関係の表面積が拡大し、SBOM・アーティファクト署名・来歴（Provenance）追跡・脆弱性スキャンの必要性が高まっていると指摘されています（",[33,34,38],"a",{"href":35,"rel":36},"https:\u002F\u002Fwww.cncf.io\u002Fblog\u002F2023\u002F04\u002F19\u002Fbuilding-secure-software-supply-chains-in-cncf-with-slsa-assessments\u002F",[37],"nofollow","CNCF Blog","）。テストの安全網は、その先にあるイメージの正当性を保証するものではないのです。",[11,41,43],{"id":42},"イメージタグは誰でも書き換えられるdigest固定だけでは守れない理由","イメージタグは誰でも書き換えられる。digest固定だけでは守れない理由",[16,45,46],{},[19,47],{"alt":48,"src":49},"タグ運用・digest固定・署名検証のセキュリティレベル比較","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-image-signing-sigstore-supply-chain\u002Fsection02.webp",[16,51,52,56,57,60],{},[53,54,55],"code",{},":latest"," のようなタグはもちろん、",[53,58,59],{},"v1.2.3"," のようなバージョンタグであっても、レジストリへの書き込み権限さえあれば上書きが可能です。つまりタグは「参照」に過ぎず、中身の同一性を保証しません。",[16,62,63,64,67,68,73],{},"この問題への対策としてよく語られるのが、イメージダイジェスト（",[53,65,66],{},"sha256:...","）による固定です。ダイジェストはイメージの内容そのものから算出されるハッシュ値のため、中身が変われば値も変わり、改ざんを検知できます。Sigstoreの公式ドキュメントでも、Cosignによる署名はローカルの鍵ペアやクラウドKMSで管理された鍵を使ってコンテナイメージに紐づけられ、OCI 1.1のリファラー仕様でレジストリに保存される仕組みが説明されています（",[33,69,72],{"href":70,"rel":71},"https:\u002F\u002Fdocs.sigstore.dev\u002Fcosign\u002Fsigning\u002Fsigning_with_containers\u002F",[37],"Sigstore Docs","）。",[16,75,76],{},"ただし、ダイジェスト固定だけでは「そのイメージを誰がビルドしたのか」「どのCIパイプラインを経由したのか」という来歴までは証明できません。改ざん検知（integrity）と来歴証明（provenance）は別の問題であり、後者を解決するのが署名とその検証の仕組みです。",[11,78,80],{"id":79},"sigstorecosignとkyvernoで未署名イメージは弾くを実装する","Sigstore（cosign）とKyvernoで「未署名イメージは弾く」を実装する",[16,82,83],{},[19,84],{"alt":85,"src":86},"cosign署名からKyverno Admission Controllerでの検証までのアーキテクチャ","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-image-signing-sigstore-supply-chain\u002Fsection03.webp",[16,88,89],{},"コンテナイメージ署名を実際にクラスタで強制する仕組みとして中心的な役割を果たすのが、SigstoreのCosignとKyvernoの組み合わせです。",[16,91,92],{},"Cosignは鍵ペアによる署名に加え、OpenID Connectのアイデンティティに短命な証明書を紐づける「キーレス署名」に対応しています。署名イベントは透明性ログ（Rekor）に記録され、後から誰が・いつ署名したかを検証可能な形で追跡できます。",[16,94,95,96,99,100,73],{},"署名されたイメージをクラスタ側で強制するには、Kubernetesの Admission Controller の仕組みを使います。Kubernetes公式ドキュメントでは、Podが実行される前に外部Webhookでイメージを検証する ",[53,97,98],{},"ImagePolicyWebhook"," が用意されており、クラスタ管理者が承認したイメージのみ実行を許可する構成が可能だと説明されています（",[33,101,104],{"href":102,"rel":103},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Freference\u002Faccess-authn-authz\u002Fadmission-controllers\u002F",[37],"Kubernetes 公式ドキュメント",[16,106,107,108,111,112,73],{},"実務ではより柔軟な選択肢として、ポリシーエンジンのKyvernoを使うケースが増えています。Kyvernoの公式ドキュメントによれば、",[53,109,110],{},"verifyImages"," ルールでSigstoreやNotaryの署名を検証でき、対象イメージのパターン指定やレジストリ認証情報の管理、検証結果のTTLベースキャッシュにも対応しています（",[33,113,116],{"href":114,"rel":115},"https:\u002F\u002Fkyverno.io\u002Fdocs\u002Fpolicy-types\u002Fcluster-policy\u002Fverify-images\u002Foverview\u002F",[37],"Kyverno 公式ドキュメント",[16,118,119,120,125,126,73],{},"さらに一歩進んだ基準として、SLSA（Supply-chain Levels for Software Artifacts）フレームワークがあります。Linux FoundationとOpenSSFが運営するこの基準は、ビルド環境の分離やプロベナンスの署名といった要件を段階的なレベルで定義しており、「どこまでサプライチェーンを堅牢にするか」を組織が共通言語で議論するための物差しになります（",[33,121,124],{"href":122,"rel":123},"https:\u002F\u002Fslsa.dev\u002F",[37],"SLSA 公式サイト","）。実際に、ArgoCDはソース・ビルド・プロベナンスの全項目でSLSAレベル3を達成した事例が報告されています（",[33,127,38],{"href":35,"rel":128},[37],[16,130,131],{},"これらを組み合わせることで、「未署名イメージ、あるいは検証に失敗したイメージはPodとして起動させない」という防御層をクラスタの入口に築くことができます。",[16,133,134,135,140],{},"CI\u002FCDパイプラインをゼロからこの構成で組むには、鍵管理・ポリシー設計・検証キャッシュのチューニングなど、相応の運用ノウハウが必要です。",[33,136,139],{"href":137,"rel":138},"https:\u002F\u002Fkubo.hexabase.io\u002F",[37],"Kubo"," のようなマネージドK3sサービスであれば、こうしたセキュリティレイヤーを含めた運用基盤を土台から整えた状態でスタートできます。",[11,142,144],{"id":143},"k3sgitops運用にどう組み込むか","K3s\u002FGitOps運用にどう組み込むか",[16,146,147],{},[19,148],{"alt":149,"src":150},"GitOpsパイプラインにおけるCIとCDの責務分離プロセス","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-image-signing-sigstore-supply-chain\u002Fsection04.webp",[16,152,153,154,73],{},"コンテナイメージ署名の検証は、GitOpsのワークフローに組み込むと運用上の負担を抑えられます。GitOpsの考え方は、Gitリポジトリを望ましい状態の唯一の情報源とし、コントローラが実行中の状態とGit上の定義を継続的に比較・同期するというものです（",[33,155,158],{"href":156,"rel":157},"https:\u002F\u002Fargo-cd.readthedocs.io\u002Fen\u002Fstable\u002F",[37],"Argo CD 公式ドキュメント",[16,160,161,162,167],{},"軽量Kubernetesディストリビューションである K3s は、単一バイナリで動作しエッジやIoT環境でも本番運用できる設計が特徴です（",[33,163,166],{"href":164,"rel":165},"https:\u002F\u002Fk3s.io\u002F",[37],"K3s 公式サイト","）。この軽量性を活かしつつ、CI側でイメージをビルド・署名し、CD側（ArgoCDやFlux）がKyvernoの検証ポリシーと組み合わせてデプロイを実行する、という責務分離が現実的な着地点になります。",[16,169,170,171,176],{},"イメージの更新自体を自動化したい場合は、レジストリを監視して新しいイメージが公開されるとGitへの変更コミットやアプリケーション定義の更新を行うツールも存在します（",[33,172,175],{"href":173,"rel":174},"https:\u002F\u002Fgithub.com\u002Fargoproj-labs\u002Fargocd-image-updater",[37],"argocd-image-updater","）。この手のツールを導入する際も、「新しいイメージが来たら即デプロイ」ではなく「署名検証を通過したイメージだけを自動更新の対象にする」という設計にしておくことが、サプライチェーンの安全性を保つ鍵になります。",[16,178,179,182],{},[33,180,139],{"href":137,"rel":181},[37]," はArgoCD\u002FFluxとの統合を標準搭載しており、GitOpsパイプラインの中に署名検証ポリシーを組み込む構成もすぐに始められます。K3sベースでEKS\u002FAKS比で月額コストを4割以上抑えられるコスト効率を保ちながら、こうしたセキュリティレイヤーを後回しにせず設計段階から組み込めるのは、マネージドサービスならではの利点です。",[11,184,185],{"id":185},"まとめ",[16,187,188],{},"「コードがテストに通ったから安全」という感覚は、コンテナイメージという単位に置き換わった瞬間に、実は多くの検証ステップを素通りしています。タグは書き換えられ、ダイジェスト固定は改ざん検知にしかならず、来歴を証明するには署名とその検証という別のレイヤーが必要です。",[16,190,191],{},"Sigstore（Cosign）による署名、Kyvernoによる Admission Controller での検証、そしてSLSAという段階的な基準。これらを組み合わせることで、「動くから安全」ではなく「検証できるから安全」という運用に切り替えることができます。",[16,193,194,195,198,199,204],{},"EKS\u002FAKSの高コスト・複雑さ・ベンダーロックインに悩む必要はもうありません。K3sベースの",[33,196,139],{"href":137,"rel":197},[37],"なら、本格的なKubernetesの機能に加えて、こうしたサプライチェーンセキュリティの防御層まで含めたGitOps運用を、コスト効率よく実現できます。自社のCI\u002FCDパイプラインにコンテナイメージ署名の検証を組み込みたいと考えているなら、まずは",[33,200,203],{"href":201,"rel":202},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[37],"お問い合わせ","から運用設計の相談を始めてみてください。",{"title":206,"searchDepth":207,"depth":207,"links":208},"",2,[209,210,211,212,213],{"id":13,"depth":207,"text":14},{"id":42,"depth":207,"text":43},{"id":79,"depth":207,"text":80},{"id":143,"depth":207,"text":144},{"id":185,"depth":207,"text":185},"2026-08-06","コンテナイメージ署名の仕組みを解説。イメージタグは誰でも書き換え可能で、CI\u002FCDのテストを通過した保証にはならない。SigstoreとKyvernoを組み合わせ、Kubernetes\u002FK3s上で未署名イメージの起動を拒否する防御層を構築する方法を、GitOps運用との統合も含めて紹介する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-image-signing-sigstore-supply-chain\u002Feyecatch.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fkubernetes-image-signing-sigstore-supply-chain",{"title":5,"description":215},"blog\u002Fja\u002Fkubernetes-image-signing-sigstore-supply-chain",[225,226,227,228,229],"k3s","kubernetes","ci-cd","gitops","security","b_Gj3LC_Ri62fTmP3G3rUOnQXZtIWo8ou9vS-TLog8A",[232,240,249,257,265,273],{"path":233,"title":234,"description":235,"date":236,"tags":237},"\u002Fblog\u002Fja\u002Fcanary-release-kubernetes-auto-rollback-gitops","全員が同じCI\u002FCDにたどり着けない理由。カナリアリリース×自動ロールバックで作る『壊れても安全』なKubernetesデプロイ設計","本番障害の多くは「一気にデプロイする」ことが原因で起きる。カナリアリリース・自動ロールバック・監視をKubernetes上でどう設計するか、Argo RolloutsとGitOpsを軸に、中小チームでも運用し続けられる実践手順を具体的に解説する。","2026-07-15",[226,225,227,238,228,239],"canary-release","argo-rollouts",{"path":241,"title":242,"description":243,"date":244,"tags":245},"\u002Fblog\u002Fja\u002Fgitlab-auto-devops-k3s-admission-controller-gate","GitLab Auto DevOpsの『とりあえず動くCI』が、本番K3sクラスタへの一番近い脅威になる理由","GitLab Auto DevOpsは有効化するだけでSAST\u002FDASTが自動的に動く。しかしスキャンが『動いている』ことと、脆弱性を含んだイメージが本番K3sクラスタに届かないことはまったく別の話だ。CI\u002FCDとクラスタの間に監査ゲートを作る設計を解説する。","2026-08-17",[225,226,246,227,247,248],"gitlab","devsecops","admission-controller",{"path":250,"title":251,"description":252,"date":253,"tags":254},"\u002Fblog\u002Fja\u002Fkubernetes-gitops-branch-antipattern-fleet-scaling","そのdev\u002Fstaging\u002Fprodブランチ、実は時限爆弾。KubernetesのGitOpsが壊れる本当の理由","dev\u002Fstaging\u002FproductionをGitブランチで分けるGitOps運用は、実はKubernetesの宣言的インフラの前提を壊すアンチパターンだ。ドリフトが起きる理由とディレクトリ構成・トランクベース運用への移行手順、フリート規模での崩壊を防ぐ設計を解説する。","2026-08-10",[225,226,228,255,256],"argocd","devops",{"path":258,"title":259,"description":260,"date":261,"tags":262},"\u002Fblog\u002Fja\u002Fkubernetes-certificate-management-cert-manager-process-debt","証明書の更新、1行のコードより2ヶ月の会議が長かった。Kubernetesの証明書管理が『技術』ではなく『手続き』の問題である理由","Kubernetesの証明書管理は技術的には数日で終わる。だが実際に時間がかかるのは合意形成という『手続き』だ。cert-managerによる自動化と、組織的負債をなくす設計を解説する。","2026-08-09",[225,226,263,264,229],"cert-manager","tls",{"path":266,"title":267,"description":268,"date":269,"tags":270},"\u002Fblog\u002Fja\u002Fai-agent-sandbox-kata-containers-kubernetes","AIエージェントのコードは「信頼できる製品」じゃない。Kubernetesサンドボックス設計の答え","AIエージェントが生成・実行するコードはもう「信頼できる製品」ではない。KubernetesでAIエージェント向けサンドボックスを設計する際、コンテナ分離の限界とKata Containersによるマイクロ VM分離がなぜ必要になるのかを解説する。","2026-08-08",[225,226,271,272,229],"kata-containers","ai-agent",{"path":274,"title":275,"description":276,"date":277,"tags":278},"\u002Fblog\u002Fja\u002Fk3s-edge-fleet-declarative-management","1台のトラブルシューティングは笑い話で済む。それが1000台なら経営リスクになる。K3sエッジ運用を属人化から救うRancher Fleetという選択肢","K3sエッジ運用のフリート管理は、1台ずつの手作業トラブルシューティングでは破綻する。宣言的管理とRancher Fleetの仕組みから、属人化しないエッジ運用の設計を解説する。","2026-08-03",[225,226,279,228,280],"edge-computing","fleet-management",1787649512936]