CI/CDの「密封された箱」神話 — テストに通ったのは"そのイメージ"なのか
コンテナイメージは「一度ビルドすれば、どこに持っていっても同じように動く」という前提のもとで信頼されています。テストをパスしたコードがイメージにパッケージ化され、そのままレジストリを経由してKubernetesクラスタへ届く。この一連の流れがCI/CDパイプラインの基本形です。
しかし、多くの現場が見落としている問いがあります。「クラスタが実行しているイメージは、本当にCIがテストしたビルド成果物と同一なのか」という点です。コンテナイメージ署名を検証する仕組みがなければ、この問いに答えることはできません。
CNCFのソフトウェアサプライチェーンセキュリティに関する取り組みでも、オープンソースコンポーネント・コンテナイメージ・Helmチャート・サードパーティのCI/CDアクションが積み重なることで依存関係の表面積が拡大し、SBOM・アーティファクト署名・来歴（Provenance）追跡・脆弱性スキャンの必要性が高まっていると指摘されています（CNCF Blog）。テストの安全網は、その先にあるイメージの正当性を保証するものではないのです。
イメージタグは誰でも書き換えられる。digest固定だけでは守れない理由
:latest のようなタグはもちろん、v1.2.3 のようなバージョンタグであっても、レジストリへの書き込み権限さえあれば上書きが可能です。つまりタグは「参照」に過ぎず、中身の同一性を保証しません。
この問題への対策としてよく語られるのが、イメージダイジェスト（sha256:...）による固定です。ダイジェストはイメージの内容そのものから算出されるハッシュ値のため、中身が変われば値も変わり、改ざんを検知できます。Sigstoreの公式ドキュメントでも、Cosignによる署名はローカルの鍵ペアやクラウドKMSで管理された鍵を使ってコンテナイメージに紐づけられ、OCI 1.1のリファラー仕様でレジストリに保存される仕組みが説明されています（Sigstore Docs）。
ただし、ダイジェスト固定だけでは「そのイメージを誰がビルドしたのか」「どのCIパイプラインを経由したのか」という来歴までは証明できません。改ざん検知（integrity）と来歴証明（provenance）は別の問題であり、後者を解決するのが署名とその検証の仕組みです。
Sigstore（cosign）とKyvernoで「未署名イメージは弾く」を実装する
コンテナイメージ署名を実際にクラスタで強制する仕組みとして中心的な役割を果たすのが、SigstoreのCosignとKyvernoの組み合わせです。
Cosignは鍵ペアによる署名に加え、OpenID Connectのアイデンティティに短命な証明書を紐づける「キーレス署名」に対応しています。署名イベントは透明性ログ（Rekor）に記録され、後から誰が・いつ署名したかを検証可能な形で追跡できます。
署名されたイメージをクラスタ側で強制するには、Kubernetesの Admission Controller の仕組みを使います。Kubernetes公式ドキュメントでは、Podが実行される前に外部Webhookでイメージを検証する ImagePolicyWebhook が用意されており、クラスタ管理者が承認したイメージのみ実行を許可する構成が可能だと説明されています（Kubernetes 公式ドキュメント）。
実務ではより柔軟な選択肢として、ポリシーエンジンのKyvernoを使うケースが増えています。Kyvernoの公式ドキュメントによれば、verifyImages ルールでSigstoreやNotaryの署名を検証でき、対象イメージのパターン指定やレジストリ認証情報の管理、検証結果のTTLベースキャッシュにも対応しています（Kyverno 公式ドキュメント）。
さらに一歩進んだ基準として、SLSA（Supply-chain Levels for Software Artifacts）フレームワークがあります。Linux FoundationとOpenSSFが運営するこの基準は、ビルド環境の分離やプロベナンスの署名といった要件を段階的なレベルで定義しており、「どこまでサプライチェーンを堅牢にするか」を組織が共通言語で議論するための物差しになります（SLSA 公式サイト）。実際に、ArgoCDはソース・ビルド・プロベナンスの全項目でSLSAレベル3を達成した事例が報告されています（CNCF Blog）。
これらを組み合わせることで、「未署名イメージ、あるいは検証に失敗したイメージはPodとして起動させない」という防御層をクラスタの入口に築くことができます。
CI/CDパイプラインをゼロからこの構成で組むには、鍵管理・ポリシー設計・検証キャッシュのチューニングなど、相応の運用ノウハウが必要です。Kubo のようなマネージドK3sサービスであれば、こうしたセキュリティレイヤーを含めた運用基盤を土台から整えた状態でスタートできます。
K3s/GitOps運用にどう組み込むか
コンテナイメージ署名の検証は、GitOpsのワークフローに組み込むと運用上の負担を抑えられます。GitOpsの考え方は、Gitリポジトリを望ましい状態の唯一の情報源とし、コントローラが実行中の状態とGit上の定義を継続的に比較・同期するというものです（Argo CD 公式ドキュメント）。
軽量Kubernetesディストリビューションである K3s は、単一バイナリで動作しエッジやIoT環境でも本番運用できる設計が特徴です（K3s 公式サイト）。この軽量性を活かしつつ、CI側でイメージをビルド・署名し、CD側（ArgoCDやFlux）がKyvernoの検証ポリシーと組み合わせてデプロイを実行する、という責務分離が現実的な着地点になります。
イメージの更新自体を自動化したい場合は、レジストリを監視して新しいイメージが公開されるとGitへの変更コミットやアプリケーション定義の更新を行うツールも存在します（argocd-image-updater）。この手のツールを導入する際も、「新しいイメージが来たら即デプロイ」ではなく「署名検証を通過したイメージだけを自動更新の対象にする」という設計にしておくことが、サプライチェーンの安全性を保つ鍵になります。
Kubo はArgoCD/Fluxとの統合を標準搭載しており、GitOpsパイプラインの中に署名検証ポリシーを組み込む構成もすぐに始められます。K3sベースでEKS/AKS比で月額コストを4割以上抑えられるコスト効率を保ちながら、こうしたセキュリティレイヤーを後回しにせず設計段階から組み込めるのは、マネージドサービスならではの利点です。
まとめ
「コードがテストに通ったから安全」という感覚は、コンテナイメージという単位に置き換わった瞬間に、実は多くの検証ステップを素通りしています。タグは書き換えられ、ダイジェスト固定は改ざん検知にしかならず、来歴を証明するには署名とその検証という別のレイヤーが必要です。
Sigstore（Cosign）による署名、Kyvernoによる Admission Controller での検証、そしてSLSAという段階的な基準。これらを組み合わせることで、「動くから安全」ではなく「検証できるから安全」という運用に切り替えることができます。
EKS/AKSの高コスト・複雑さ・ベンダーロックインに悩む必要はもうありません。K3sベースのKuboなら、本格的なKubernetesの機能に加えて、こうしたサプライチェーンセキュリティの防御層まで含めたGitOps運用を、コスト効率よく実現できます。自社のCI/CDパイプラインにコンテナイメージ署名の検証を組み込みたいと考えているなら、まずはお問い合わせから運用設計の相談を始めてみてください。