[{"data":1,"prerenderedAt":268},["ShallowReactive",2],{"blog-ja-k3s-container-image-security-supply-chain-checklist":3,"blog-related-ja-k3s-container-image-security-supply-chain-checklist":214,"blog-ja-k3s-container-image-security-supply-chain-checklist-alt":202},{"id":4,"title":5,"author":6,"body":7,"date":196,"description":197,"extension":198,"image":199,"locale":200,"meta":201,"navigation":202,"path":203,"seo":204,"stem":205,"tags":206,"__hash__":213},"blog\u002Fblog\u002Fja\u002Fk3s-container-image-security-supply-chain-checklist.md","「スキャン済み」は本番投入の許可証にならない。K3sコンテナイメージセキュリティ、署名からアドミッション制御まで","Kubo Team",{"type":8,"value":9,"toc":187},"minimark",[10,15,19,26,43,52,55,59,62,68,82,85,89,92,98,107,122,126,129,135,143,158,165,169,172],[11,12,14],"h2",{"id":13},"_1-スキャン済みで思考停止していないか","1. 「スキャン済み」で思考停止していないか",[16,17,18],"p",{},"コンテナ セキュリティ ガイドラインを社内で整備しようとすると、多くの現場が「イメージスキャンツールを導入した」の一文で満足してしまう。だが、スキャンを導入することと、スキャン結果に基づいて実際にデプロイを止めることは、まったく別の話だ。",[16,20,21],{},[22,23],"img",{"alt":24,"src":25},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fk3s-container-image-security-supply-chain-checklist\u002Fsection01.webp",[16,27,28,29,36,37,42],{},"latestタグでの運用、root権限でのコンテナ実行、CI上でスキャンは走っているがアラートを誰も見ていない、そして署名検証なしでイメージをそのままクラスタにrunする——。これらが1つでも当てはまれば、",[30,31,35],"a",{"href":32,"rel":33},"https:\u002F\u002Fwww.nist.gov\u002Fpublications\u002Fapplication-container-security-guide",[34],"nofollow","NISTのApplication Container Security Guide","が指摘するような既知の脆弱性が、確認プロセスを経ないまま本番環境に持ち込まれるリスクがある。K3sのような軽量Kubernetesディストリビューション（",[30,38,41],{"href":39,"rel":40},"https:\u002F\u002Fdocs.k3s.io\u002F",[34],"K3s公式ドキュメント","）は導入の手軽さが魅力だが、その手軽さがそのままセキュリティ工程の省略につながってはならない。",[16,44,45,46,51],{},"余談だが、これらの工程をすべて自前で構築・運用する余力がないという声もよく聞く。",[30,47,50],{"href":48,"rel":49},"https:\u002F\u002Fkubo.hexabase.io\u002F",[34],"Kubo","のようなマネージドK3s環境を土台に据えれば、その分の工数をセキュリティ設計そのものに振り向けやすくなる。",[16,53,54],{},"本記事では、コンテナイメージが本番投入されるまでに通すべき4つの関門——ベースイメージの最小化、脆弱性スキャン、署名、アドミッション制御——を、実務でそのまま使えるチェックリストとして整理する。",[11,56,58],{"id":57},"_2-ビルド時点で絞る-最小ベースイメージとroot排除","2. ビルド時点で絞る — 最小ベースイメージとroot排除",[16,60,61],{},"コンテナ セキュリティの土台は、イメージに何を「含めないか」で決まる。攻撃対象領域（アタックサーフェス）は、イメージの中に存在するファイルやバイナリの数に比例して広がる。",[16,63,64],{},[22,65],{"alt":66,"src":67},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fk3s-container-image-security-supply-chain-checklist\u002Fsection02.webp",[16,69,70,71,76,77,81],{},"Googleが公開している",[30,72,75],{"href":73,"rel":74},"https:\u002F\u002Fgithub.com\u002FGoogleContainerTools\u002Fdistroless",[34],"distrolessプロジェクト","は、シェルやパッケージマネージャを含まない最小構成のベースイメージを提供しており、Kubernetes本体もv1.15以降でこの方式を採用している。マルチステージビルドを使えば、ビルドに必要なコンパイラやツールチェーンを最終イメージから完全に排除できる。加えて、Dockerfileで",[78,79,80],"code",{},"USER","を明示し非root実行をデフォルトにすることも、権限昇格リスクを下げる基本策として欠かせない。",[16,83,84],{},"これらはK3sクラスタでも通常のKubernetesと同じ考え方が通用する。むしろエッジやオンプレミスなど、パッチ適用のサイクルが長くなりがちな環境ほど、ビルド時点でリスクを削り込んでおく効果は大きい。",[11,86,88],{"id":87},"_3-プッシュ前に落とす-脆弱性スキャンとsbom生成","3. プッシュ前に落とす — 脆弱性スキャンとSBOM生成",[16,90,91],{},"ベースイメージを絞り込んでも、アプリケーション自体の依存ライブラリに既知のCVEが含まれるケースは避けられない。ここで必要になるのが、レジストリへプッシュする前のスキャンをCIパイプラインのゲートとして機能させることだ。",[16,93,94],{},[22,95],{"alt":96,"src":97},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fk3s-container-image-security-supply-chain-checklist\u002Fsection03.webp",[16,99,100,101,106],{},"オープンソースの",[30,102,105],{"href":103,"rel":104},"https:\u002F\u002Ftrivy.dev\u002F",[34],"Trivy","は、コンテナイメージ・IaC設定・Kubernetesマニフェストを横断してCVEや設定ミスを検出できるスキャナで、CI組み込みが容易なことから広く使われている。重要なのは「スキャンする」だけでなく、Critical\u002FHigh相当の脆弱性が見つかった場合にビルド自体を失敗させる設計にすることだ。これがなければ、スキャン結果はただのログで終わってしまう。",[16,108,109,110,115,116,121],{},"同時に、イメージごとのSBOM（Software Bill of Materials）を生成しておくことも欠かせない。SBOMの標準規格には",[30,111,114],{"href":112,"rel":113},"https:\u002F\u002Fcyclonedx.org\u002F",[34],"CycloneDX","と",[30,117,120],{"href":118,"rel":119},"https:\u002F\u002Fspdx.dev\u002F",[34],"SPDX","があり、いずれも国際的な仕様として整備されている。SBOMを残しておけば、後日新たなCVEが公開された際に「そのライブラリを含むイメージがどれか」を即座に特定でき、監査対応や脆弱性のトリアージが大幅に速くなる。",[11,123,125],{"id":124},"_4-デプロイ前に検証する-署名とアドミッション制御","4. デプロイ前に検証する — 署名とアドミッション制御",[16,127,128],{},"脆弱性スキャンとSBOM生成まで済んでも、そのイメージが本当にCIを通過した正規のものかをクラスタ側が確認できなければ、途中で改ざんされたイメージや、スキャンを経由していないイメージが紛れ込む余地が残る。ここで必要になるのが、署名とアドミッション制御の組み合わせだ。",[16,130,131],{},[22,132],{"alt":133,"src":134},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fk3s-container-image-security-supply-chain-checklist\u002Fsection04.webp",[16,136,137,142],{},[30,138,141],{"href":139,"rel":140},"https:\u002F\u002Fgithub.com\u002Fsigstore\u002Fcosign",[34],"Cosign","は、CIパイプラインでビルドしたイメージに電子署名を付与するツールで、鍵管理を必要としないキーレス署名にも対応している。署名を付けるだけでは意味がなく、クラスタ側で「署名のないイメージは拒否する」というポリシーを機械的に強制する仕組みが対になって初めて効果を持つ。",[16,144,145,146,151,152,157],{},"この役割を担うのが",[30,147,150],{"href":148,"rel":149},"https:\u002F\u002Fkyverno.io\u002Fdocs\u002Fpolicy-types\u002Fcluster-policy\u002Fverify-images\u002Foverview\u002F",[34],"Kyverno","や",[30,153,156],{"href":154,"rel":155},"https:\u002F\u002Fkubernetes.io\u002Fblog\u002F2019\u002F08\u002F06\u002Fopa-gatekeeper-policy-and-governance-for-kubernetes\u002F",[34],"OPA Gatekeeper","といったアドミッションコントローラだ。KubernetesのAPIレイヤーでポリシーを評価し、条件を満たさないPodの作成要求そのものを拒否する。CI側の担当者の善意やチェック漏れに依存せず、クラスタ側で機械的にゲートすることで、「スキャンをすり抜けたイメージがうっかり本番に入る」事故を構造的に防げる。",[16,159,160,161,164],{},"署名検証やアドミッションポリシーの継続的なメンテナンスには相応の運用工数がかかる。",[30,162,50],{"href":48,"rel":163},[34],"のK3sベースの環境では、cert-managerによる証明書自動管理やPrometheus\u002FGrafanaによるモニタリングが標準搭載されており、こうした周辺運用に取られる工数を減らし、ポリシー設計そのものに集中しやすくなる。",[11,166,168],{"id":167},"_5-まとめ-4つの関門をk3s運用にどう落とし込むか","5. まとめ — 4つの関門をK3s運用にどう落とし込むか",[16,170,171],{},"ここまで見てきた4つの関門——ベースイメージの最小化、脆弱性スキャンとSBOM生成、署名、アドミッション制御によるポリシー強制——は、いずれも単体では不十分で、パイプラインとして連続させて初めて機能する。なお、コンテナが起動した後の異常検知（ランタイムセキュリティ）は本記事のスコープ外としたが、これは供給チェーンの防御線とは別レイヤーの話であり、別途扱うべきテーマだ。",[16,173,174,175,180,181,186],{},"この一連の仕組みをゼロから構築・維持するには、CI設定・スキャンツールの運用・証明書や鍵の管理・アドミッションコントローラのポリシー保守と、決して小さくない工数がかかる。金融機関や医療機関のように、コンプライアンス要件からイメージの供給チェーン管理を自社で完結させたい組織には、",[30,176,179],{"href":177,"rel":178},"https:\u002F\u002Fwww.hexabase.com\u002Fproduct\u002Fkubo\u002Fon-premise",[34],"Kubo On-Premise","のAir-Gapped対応も選択肢になる。自社のコンテナ セキュリティ運用が「スキャンしてるから大丈夫」で止まっていないか、一度この4つの関門に照らして棚卸ししてみてほしい。導入の相談は",[30,182,185],{"href":183,"rel":184},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[34],"お問い合わせ","から受け付けている。",{"title":188,"searchDepth":189,"depth":189,"links":190},"",2,[191,192,193,194,195],{"id":13,"depth":189,"text":14},{"id":57,"depth":189,"text":58},{"id":87,"depth":189,"text":88},{"id":124,"depth":189,"text":125},{"id":167,"depth":189,"text":168},"2026-08-24","コンテナ セキュリティ ガイドラインというと『スキャンしてるから大丈夫』で止まりがちだ。K3s環境でベースイメージの最小化から脆弱性スキャン、SBOM生成、署名、アドミッション制御まで、本番投入前に通すべき工程を実務チェックリストとして具体的に解説する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fk3s-container-image-security-supply-chain-checklist\u002Feyecatch.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fk3s-container-image-security-supply-chain-checklist",{"title":5,"description":197},"blog\u002Fja\u002Fk3s-container-image-security-supply-chain-checklist",[207,208,209,210,211,212],"k3s","kubernetes","container-security","image-scanning","sbom","supply-chain-security","4Q8LmZN5N4xTiuZ3qmf8VT-lOdxxuzS5elGdHAuq6IY",[215,224,234,242,251,258],{"path":216,"title":217,"description":218,"date":219,"tags":220},"\u002Fblog\u002Fja\u002Fk3s-harbor-private-registry-docker-hub-rate-limit","Docker Hubの無料枠が凍りついた朝、K3sクラスタは静かに詰む。Harborを自前で持つべきタイミング","Docker Hubのpull rate limitで本番K3sクラスタのイメージ取得が止まるリスクが現実味を増している。CNCF卒業プロジェクトHarborを自前運用する設計判断と隠れたコストを解説する。","2026-08-23",[207,208,221,222,223],"harbor","container-registry","cncf",{"path":225,"title":226,"description":227,"date":228,"tags":229},"\u002Fblog\u002Fja\u002Fkubernetes-cost-management-eks-aks-billing-visibility","EKSの請求書は月末にならないと読めない。Kubernetesのコストが『後から分かる』構造的な理由","EKS\u002FAKSのKubernetesコストはなぜ想定外に膨らむのか。オートスケールとクロスAZ課金がコストを見えなくする構造を分解し、K3sベースのマネージドインフラで固定費化する方法を解説します。","2026-08-22",[207,208,230,231,232,233],"cost-optimization","managed-kubernetes","aks","finops",{"path":235,"title":236,"description":237,"date":238,"tags":239},"\u002Fblog\u002Fja\u002Fkubernetes-operations-specialization-managed-k3s-hiring","eBPFもcert-managerもService Meshも。Kubernetes運用がひとりのエンジニアの手に負えなくなった理由","Kubernetes運用の求人がなぜ埋まらないのか。原因はツール知識の不足ではなく、専門分野が広がりすぎたことにある。採用で埋めるのではなく基盤に吸収させる、マネージドK3sという解決策を解説する。","2026-08-21",[207,208,231,240,241],"devops","platform-engineering",{"path":243,"title":244,"description":245,"date":246,"tags":247},"\u002Fblog\u002Fja\u002Fk3s-opentelemetry-observability-correlation","3つのダッシュボードを往復する障害対応はもう終わり。K3sの可観測性をOpenTelemetryで『相関』させる設計","PrometheusとLokiとJaegerを個別に確認して原因究明に時間を溶かしていないか。K3sクラスタの可観測性をOpenTelemetryで相関させ、障害調査時間を短縮する設計とOpenTelemetry Collectorの導入パターンを、K3s\u002FKubernetes運用の現場目線で解説する。","2026-08-20",[207,208,248,249,250],"opentelemetry","observability","distributed-tracing",{"path":252,"title":253,"description":254,"date":255,"tags":256},"\u002Fblog\u002Fja\u002Fcncf-project-maturity-graduation-criteria-production","GitHubスター1万は『卒業証書』にならない。KubernetesでCNCFプロジェクトを選ぶ基準はコミット数ではなく成熟度ステージ","Kubernetesの技術選定でCNCFプロジェクトを採用する際、GitHubスター数や知名度だけで判断していないか。Sandbox\u002FIncubating\u002FGraduatedという成熟度基準とHarborの事例から、本番導入前に確認すべき基準を解説する。","2026-08-19",[207,208,223,257,222],"oss-governance",{"path":259,"title":260,"description":261,"date":262,"tags":263},"\u002Fblog\u002Fja\u002Fai-agent-authentication-kubernetes-keycloak-spiffe","AIエージェントに鍵を持たせるな。KubernetesでMCPサーバーを『キーレス』に認証する設計","AIエージェントに静的なAPIキーを持たせる運用は、いずれ破綻する。KubernetesでMCPサーバーを運用する現場で起きている静的シークレット問題の構造的な限界と、KeycloakとSPIFFE\u002FSPIREを組み合わせて鍵を配らずに認証する『キーレス』設計思想を解説する。","2026-08-18",[207,208,264,265,266,267],"ai-agent","mcp","keycloak","zero-trust",1787649511891]