1. 「スキャン済み」で思考停止していないか
コンテナ セキュリティ ガイドラインを社内で整備しようとすると、多くの現場が「イメージスキャンツールを導入した」の一文で満足してしまう。だが、スキャンを導入することと、スキャン結果に基づいて実際にデプロイを止めることは、まったく別の話だ。
latestタグでの運用、root権限でのコンテナ実行、CI上でスキャンは走っているがアラートを誰も見ていない、そして署名検証なしでイメージをそのままクラスタにrunする——。これらが1つでも当てはまれば、NISTのApplication Container Security Guideが指摘するような既知の脆弱性が、確認プロセスを経ないまま本番環境に持ち込まれるリスクがある。K3sのような軽量Kubernetesディストリビューション（K3s公式ドキュメント）は導入の手軽さが魅力だが、その手軽さがそのままセキュリティ工程の省略につながってはならない。
余談だが、これらの工程をすべて自前で構築・運用する余力がないという声もよく聞く。KuboのようなマネージドK3s環境を土台に据えれば、その分の工数をセキュリティ設計そのものに振り向けやすくなる。
本記事では、コンテナイメージが本番投入されるまでに通すべき4つの関門——ベースイメージの最小化、脆弱性スキャン、署名、アドミッション制御——を、実務でそのまま使えるチェックリストとして整理する。
2. ビルド時点で絞る — 最小ベースイメージとroot排除
コンテナ セキュリティの土台は、イメージに何を「含めないか」で決まる。攻撃対象領域（アタックサーフェス）は、イメージの中に存在するファイルやバイナリの数に比例して広がる。
Googleが公開しているdistrolessプロジェクトは、シェルやパッケージマネージャを含まない最小構成のベースイメージを提供しており、Kubernetes本体もv1.15以降でこの方式を採用している。マルチステージビルドを使えば、ビルドに必要なコンパイラやツールチェーンを最終イメージから完全に排除できる。加えて、DockerfileでUSERを明示し非root実行をデフォルトにすることも、権限昇格リスクを下げる基本策として欠かせない。
これらはK3sクラスタでも通常のKubernetesと同じ考え方が通用する。むしろエッジやオンプレミスなど、パッチ適用のサイクルが長くなりがちな環境ほど、ビルド時点でリスクを削り込んでおく効果は大きい。
3. プッシュ前に落とす — 脆弱性スキャンとSBOM生成
ベースイメージを絞り込んでも、アプリケーション自体の依存ライブラリに既知のCVEが含まれるケースは避けられない。ここで必要になるのが、レジストリへプッシュする前のスキャンをCIパイプラインのゲートとして機能させることだ。
オープンソースのTrivyは、コンテナイメージ・IaC設定・Kubernetesマニフェストを横断してCVEや設定ミスを検出できるスキャナで、CI組み込みが容易なことから広く使われている。重要なのは「スキャンする」だけでなく、Critical/High相当の脆弱性が見つかった場合にビルド自体を失敗させる設計にすることだ。これがなければ、スキャン結果はただのログで終わってしまう。
同時に、イメージごとのSBOM（Software Bill of Materials）を生成しておくことも欠かせない。SBOMの標準規格にはCycloneDXとSPDXがあり、いずれも国際的な仕様として整備されている。SBOMを残しておけば、後日新たなCVEが公開された際に「そのライブラリを含むイメージがどれか」を即座に特定でき、監査対応や脆弱性のトリアージが大幅に速くなる。
4. デプロイ前に検証する — 署名とアドミッション制御
脆弱性スキャンとSBOM生成まで済んでも、そのイメージが本当にCIを通過した正規のものかをクラスタ側が確認できなければ、途中で改ざんされたイメージや、スキャンを経由していないイメージが紛れ込む余地が残る。ここで必要になるのが、署名とアドミッション制御の組み合わせだ。
Cosignは、CIパイプラインでビルドしたイメージに電子署名を付与するツールで、鍵管理を必要としないキーレス署名にも対応している。署名を付けるだけでは意味がなく、クラスタ側で「署名のないイメージは拒否する」というポリシーを機械的に強制する仕組みが対になって初めて効果を持つ。
この役割を担うのがKyvernoやOPA Gatekeeperといったアドミッションコントローラだ。KubernetesのAPIレイヤーでポリシーを評価し、条件を満たさないPodの作成要求そのものを拒否する。CI側の担当者の善意やチェック漏れに依存せず、クラスタ側で機械的にゲートすることで、「スキャンをすり抜けたイメージがうっかり本番に入る」事故を構造的に防げる。
署名検証やアドミッションポリシーの継続的なメンテナンスには相応の運用工数がかかる。KuboのK3sベースの環境では、cert-managerによる証明書自動管理やPrometheus/Grafanaによるモニタリングが標準搭載されており、こうした周辺運用に取られる工数を減らし、ポリシー設計そのものに集中しやすくなる。
5. まとめ — 4つの関門をK3s運用にどう落とし込むか
ここまで見てきた4つの関門——ベースイメージの最小化、脆弱性スキャンとSBOM生成、署名、アドミッション制御によるポリシー強制——は、いずれも単体では不十分で、パイプラインとして連続させて初めて機能する。なお、コンテナが起動した後の異常検知（ランタイムセキュリティ）は本記事のスコープ外としたが、これは供給チェーンの防御線とは別レイヤーの話であり、別途扱うべきテーマだ。
この一連の仕組みをゼロから構築・維持するには、CI設定・スキャンツールの運用・証明書や鍵の管理・アドミッションコントローラのポリシー保守と、決して小さくない工数がかかる。金融機関や医療機関のように、コンプライアンス要件からイメージの供給チェーン管理を自社で完結させたい組織には、Kubo On-PremiseのAir-Gapped対応も選択肢になる。自社のコンテナ セキュリティ運用が「スキャンしてるから大丈夫」で止まっていないか、一度この4つの関門に照らして棚卸ししてみてほしい。導入の相談はお問い合わせから受け付けている。