Kubernetesセキュリティ解説：ビルドから実行時までのクラスター保護

2018年、テスラが自社のKubernetesクラスター内で攻撃者による暗号通貨マイニング活動を確認した際、その根本原因は驚くほど単純だった：パスワード設定のない公開ダッシュボードである。数年後も、同様の設定ミスが大規模組織を悩ませ続けている。 過去12ヶ月間で90％の組織が少なくとも1件のKubernetesセキュリティインシデントを経験している（Red Hat 2024年調査）。また新規クラスターはデプロイから18分以内に最初の攻撃試行に直面する（Wiz 2025年調査）。 コンテナおよびKubernetesセキュリティ市場は2024年の17億ドルから2030-2033年には80-90億ドルへ成長すると予測されており、これらの環境を保護する緊急性はかつてないほど高まっています。本ガイドでは、基礎的なモデルやライフサイクルのベストプラクティスから、今日の高度な攻撃に対処する振る舞い 検知やクラウドセキュリティ戦略まで、Kubernetesセキュリティの全領域を網羅します。

Kubernetesのセキュリティとは何ですか？

Kubernetesセキュリティとは、イメージ構築からデプロイ、実行時運用に至るアプリケーションライフサイクル全体において、コンテナ化されたワークロードとそのオーケストレーション基盤を保護するための一連の実践手法、ツール、ポリシーを指します。これには、制御プレーン、ワーカーノード、コンテナイメージ、ネットワークトラフィック、構成レイヤー全体にわたる、構成の強化、アクセス制御（RBAC）、ネットワークセグメンテーション、シークレット管理、実行時脅威検知、コンプライアンス監視が含まれます。

なぜこれが重要なのか？Kubernetesはデフォルトでは安全ではない。このプラットフォームは、デフォルト設定において堅牢なセキュリティよりも柔軟性と開発者の作業速度を優先する。組織はクラスターを本番環境対応にする前に、ロールベースのアクセス制御（RBAC）、ネットワークポリシー、シークレットの暗号化、Podセキュリティ基準、監査ログを積極的に設定しなければならない。Kubernetesセキュリティ概念のドキュメントによれば、共有責任モデルはセキュリティ設定の負担を明確にオペレーターに課している。

これを誤った場合のビジネスへの影響は深刻である。67％の組織がKubernetesのセキュリティ懸念により導入を遅延または減速させ、46％が収益または顧客の損失を経験し、30％が罰金を科された（Red Hat 2024）。Kubernetesクラスターの拡大する攻撃対象領域は、APIサーバー、etcdデータストア、kubelet、コンテナランタイム、ネットワークオーバーレイ、そしてその内部で実行されるすべてのワークロードに及ぶ。

Kubernetesのセキュリティとコンテナセキュリティの違い

コンテナセキュリティは、個々のコンテナイメージ、ランタイム、および分離メカニズムに焦点を当てます。Kubernetesセキュリティは、単一のコンテナを超えたオーケストレーション層の懸念事項を追加します。これには、APIサーバーへのアクセス制御、クラスター全体で誰が何を実行できるかを規定するRBACポリシー、ネットワークポリシーによって管理されるポッド間およびネームスペース間の通信、シークレット管理と保存時の暗号化、デプロイ前にワークロードを検証するアドミッションコントローラー、監査ログやPod Security Standardsなどのクラスター全体の設定が含まれます。

設定ミスのあるクラスターにデプロイされた強化されたコンテナイメージは、依然として脆弱な状態です。Kubernetesのセキュリティは、それらのコンテナを取り囲み、接続し、オーケストレーションする基盤インフラストラクチャに対処します。

Kubernetesの脅威の現状

設定ミスがKubernetes侵害の大半を占めるが、ラテラルムーブメントと 権限昇格を利用した標的型攻撃が急増している。 Red Hatの2024年レポートでは、回答者の50%以上がKubernetesセキュリティインシデントの主因として設定ミスを挙げています。主要なセキュリティ懸念の内訳は明確な傾向を示しています：脆弱性（33%）、設定ミスと情報漏洩（27%）、アクティブな攻撃（24%）、コンプライアンス監査の不合格（16%）。

さらに、EKSクラスターの81%が依然として廃止予定のCONFIG_MAP認証に依存しており（Wiz 2025）、攻撃者が積極的に悪用するレガシーリスクを生み出している。コンテナベースの横方向移動攻撃は2025年に34%増加（Tigera）し、機会主義的な設定ミス悪用から、意図的な侵害後の操作への移行を反映している。

現実世界のKubernetesセキュリティインシデント

これらの日付付きで出典明記された事例研究は、不十分なKubernetesセキュリティが招く結果と、各インシデントから得られる教訓を示している。

1. Tesla の暗号通貨マイニング侵害（2018 年） 攻撃者は、Tesla の Kubernetes ダッシュボードがパスワード保護なしでインターネットに公開されていることを発見しました。攻撃者は暗号通貨マイニングコンテナを展開し、検知を回避するためにリソース使用量を制限し、活動を隠蔽するために Cloudflare 経由でトラフィックをルーティングしました。教訓: Kubernetes ダッシュボードや API エンドポイントを認証なしで公開しないでください。デフォルト拒否のアクセスポリシーにより、最も一般的な初期アクセス経路を阻止します。(Aikido Security)
2. 金融機関のセキュリティ侵害（2019年7月）。ファイアウォールの設定ミスにより、金融機関のKubernetesクラスターが公衆インターネットに公開された。攻撃者は30GBのクレジット申請データを不正取得した。教訓：機密データを扱うクラスターには、特にPCI DSS要件下において、ネットワークセグメンテーションと厳格なファイアウォールルールを適用する必要がある。（CrowdStrike）
3. 350組織の大量公開（2023年8月）。セキュリティ研究者が、フォーチュン500企業を含む350以上の組織に属するKubernetesクラスターが、2つの一般的な設定ミスにより公開アクセス可能になっていることを発見。 教訓：kube-benchなどのツールによる自動スキャンで、攻撃者に発見される前に公開クラスターを検知できる。（CrowdStrike）
4. RBACバスター攻撃キャンペーン（2023-2024年）。攻撃者は、認証されていない匿名リクエストを受け入れる誤設定されたKubernetes APIサーバーを悪用した。悪意のあるRBACポリシーを実装し、永続的なバックドアを作成し、暗号通貨マイニングオペレーションを展開した。教訓：RBACポリシーを定期的に監査し、匿名APIアクセスを無効化し、アドミッションコントローラーを使用して過度に許可されたロール作成を防止すること。（Picus Security）
5. OpenMetadataの悪用（2024年4月）。脅威アクターはOpenMetadataの重大な脆弱性（SpELインジェクションと認証バイパスを組み合わせたもの）を悪用し、暗号通貨マイニング目的でKubernetesワークロードへの不正アクセスを獲得した。Microsoft Threat Intelligenceは活発な悪用を確認。教訓：パッチ管理はKubernetes自体だけでなく、Kubernetes上で動作する全てのワークロードを対象とすべき。クラスターにデプロイされたサードパーティ製アプリケーションが侵入経路となり得る。（CheckRed）
6. Dero暗号通貨マイニング攻撃キャンペーン（2024年）。攻撃者はインターネットに公開されたKubernetes APIサーバーへの匿名アクセスを悪用し、Docker HubからDero暗号通貨マイニング用の悪意あるコンテナイメージを展開した。教訓：匿名APIアクセスを無効化し、イメージソースを制限するアドミッションコントローラーを導入することで、不正なコンテナ展開を防止できる。
7. worm 2026年2月）。TeamPCPグループはKubernetes特化型ペイロード（kube.py）を展開し、ポッドとネームスペースを列挙、アクセス可能なワークロード全体でコマンドを実行、永続的なクラスター全体制御のための特権DaemonSetをインストールした。少なくとも185台のサーバーが侵害されたことが確認されている。このキャンペーンはAWSおよびAzure環境を標的とし、暗号通貨マイニング、データ窃取、ランサムウェア展開を目的としている。教訓：単一の侵害されたポッドがクラスター全体を分散型ボットネットに変える可能性がある。異常なデーモンセットのデプロイや東西方向トラフィックパターンの振る舞い 不可欠である。（The Hacker News,eSecurity Planet）

MITRE ATT&CK マトリックス マッピング

MITRE ATT&CK 、Kubernetesの脅威をセキュリティ対策にマッピングするための共通言語を提供します。以下の表は、MITRE ATT&CK 主要な戦術を、特定のKubernetesセキュリティ対策にマッピングしたものです。

表1: Kubernetesセキュリティ制御に対応したMITRE ATT&CK マトリックス

Kubernetesセキュリティの4つのC

4Csモデルは、各セキュリティ層が下位層の完全性に依存する階層型防御フレームワークを提供する。業界で広く採用されているこのモデルは、Kubernetesセキュリティを4つの入れ子構造の層に整理する。

1. クラウド— インフラストラクチャレベルの制御（ネットワークファイアウォール、IAMポリシー、転送中の暗号化、およびAWS、Azure、GCP向けのプロバイダー固有の強化策を含む）
2. クラスター— APIサーバーの強化、最小権限によるRBAC、アドミッションコントローラー（OPA/Gatekeeper、Kyverno）、etcdの保存時暗号化、監査ログ、ネットワークセキュリティポリシー
3. コンテナ— TrivyまたはGrypeによるイメージスキャン、ベースイメージの強化、ルートレスコンテナ、セキュリティコンテキスト、Pod Security Standardsの適用
4. コード— 依存関係スキャン、コード内シークレット検知、SAST/DAST統合、およびcosign/Sigstoreによるサプライチェーンセキュリティ検証

各レイヤーは下層のレイヤーを基盤として構築される。完全に硬化されたコンテナイメージであっても、それが稼働するクラスターが匿名APIアクセスを許可している場合、その保護効果は限定的である。同様に、厳格なクラウドセキュリティ設定も、コンテナ内で実行されるコードにハードコードされたシークレットや脆弱な依存関係が含まれている場合、その価値を失う。

ライフサイクル段階別のKubernetesセキュリティベストプラクティス

Kubernetesのセキュリティを効果的に実現するには、ライフサイクルの各フェーズでの制御が不可欠です。ランタイム検知は、ビルド時のスキャンでは対応できないギャップを埋める役割を果たします。以下のプラクティスは、ビルド、デプロイ、ランタイムの各フェーズに分かれており、OWASP Kubernetesセキュリティチートシートに準拠した包括的なKubernetesセキュリティチェックリストとなっています。

ビルドフェーズ

1. CI/CDパイプラインでTrivyまたはGrypeを用いてコンテナイメージを継続的にスキャンする
2. 既知の重大なCVEを持つブロックのデプロイをアドミッションコントローラーでブロックする
3. 最小限の、強化されたベースイメージを使用する（Dockerは現在、Apache 2.0ライセンスのもとで1,000以上の無料強化イメージを提供している）
4. サプライチェーンのセキュリティのために、cosign/Sigstoreで画像に署名し検証する
5. 実行環境向けのソフトウェア部品表（SBOM）を生成する

デプロイフェーズ

1. 最小権限によるRBACを有効化してください。RBAC（ロールベースのアクセス制御）は、割り当てられたロールに基づいてKubernetesリソースへのアクセスを規制します。デフォルトのサービスアカウントにcluster-adminを使用しないでください。
2. 保存中のシークレットは、etcdの暗号化機能またはHashiCorp VaultやAWS Secrets Managerなどの外部シークレット管理ツールを使用して暗号化してください。Kubernetesのetcdはシークレットや設定を含むすべてのクラスターデータを格納するため、その暗号化は極めて重要です。
3. アドミッションコントローラーを実装する。アドミッションコントローラーはオブジェクトが永続化される前にAPIリクエストをインターセプトし、ワークロード構成の検証と変更を可能にする。OPA/GatekeeperとKyvernoが主要なポリシーエンジンである。
4. 本番環境ネームスペース向けに「制限付き」プロファイルでPodセキュリティ基準を適用し、Kubernetes v1.25で廃止されたPodセキュリティポリシーに代わるものとする。
5. 入出力トラフィックの両方にデフォルト拒否のネットワークポリシーを適用し、ネットワーク層でzero trust 原則を徹底する。
6. Kubernetesを最新の状態に保つ。現在、クラスターの54%がサポート対象のKubernetesバージョンを実行しており、これは42%から増加した数値である（Wiz 2025）。

Kubernetesのセキュリティコンテキストは、ポッドまたはコンテナの権限とアクセス制御設定を定義します。これらの設定には、非rootユーザーとしての実行、Linux機能の削除、読み取り専用ルートファイルシステムの設定、seccompプロファイルの定義が含まれます。すべてのワークロードにセキュリティコンテキストを一貫して適用することで、多くの一般的な権限昇格経路を防ぐことができます。

実行時フェーズ

1. 監査ログを有効化し、異常検知のためにSIEMへログをストリーミングする
2. 振る舞い のためのeBPFベースのランタイムセキュリティ（Falco、Tetragon）を展開する
3. APIサーバーを保護するには、匿名認証を無効化し、ネットワークアクセスを制限し、TLSを有効にしてください。
4. 東西方向のトラフィックを監視し、横方向移動の指標を確認する
5. 暗号通貨マイニングなどのリソースハイジャックを防ぐため、リソース制限を実施する

Kubernetesにおけるランタイムセキュリティとは、ワークロードのデプロイ後に監視と保護を行う手法です。デプロイ前に既知の脆弱性を検知するビルド時スキャンとは異なり、ランタイムセキュリティは稼働中のクラスターにおけるアクティブな脅威、異常な動作、ゼロデイ攻撃を検知します。高度なDevSecOpsイニシアチブを導入している組織（回答者の42%）は、ビルド時の防御に加えてランタイム検知も行っています（Red Hat 2024）。

主要なKubernetesセキュリティツールと技術

eBPFベースのセキュリティスタック（Falco、Tetragon、Cilium）は、パフォーマンスへの影響を最小限に抑えつつ、Kubernetesランタイム検知の標準となりつつある。以下のツールは、スキャン、ポリシー適用、ランタイム検知の各カテゴリにおいて、主要なオープンソースオプションを代表するものである。

オープンソースツール

表2: Kubernetesセキュリティツール比較

KubescapeはCNCFインキュベーションステータスを獲得し、10万以上のクラウド環境において25,000社以上で利用されています（CNCF 2025）。これにより、CNCFに採用された初のKubernetesセキュリティスキャナーとなりました。

eBPFベースのランタイムセキュリティ

拡張バークレーパケットフィルタ（eBPF）は、1%未満のCPUオーバーヘッド（Tetragon）でカーネルレベルの可観測性と強制を実現し、組織のKubernetesランタイムセキュリティへの取り組みを変革します。主要なeBPFベースのツールには以下が含まれます：

• Tetragon (Ciliumプロジェクト)は、カーネルレベルでのセキュリティ可観測性と実行時強制を提供します
• CiliumはeBPFを活用し、ネットワークポリシーの適用、マイクロセグメンテーション、サービスメッシュ機能を提供します
• Falco（eBPFドライバー付き）は、ランタイム脅威検知のためのシステムコール監視を実行します

Kubescape、Falco、Trivy、Ciliumからなる推奨オープンソーススタックは、1～2.5%の総CPUオーバーヘッドで包括的なKubernetesセキュリティスキャンと検知を実現します。この効率性により、パフォーマンス予算が制約される本番ワークロードにおいてもeBPFベースのセキュリティが実用可能となります。既存ツールの評価を検討する組織においては、NDRツールや侵入検知・防止システムがネットワークレベルの可視性をもってeBPFベースの検知を補完します。

Kubernetesの脅威の検知とレスポンス

振る舞い脅威検知とネットワークレベルの可視性は、予防のみを目的としたツールとKubernetesクラスターを標的とするアクティブな脅威との間の重大なギャップを埋めます。構成スキャンとポリシー適用は必要ですが不十分です。これらは既知の悪意ある構成を防ぎますが、予防制御を回避した検知 攻撃者を検知 できません。

Kubernetesにおける横方向の移動

Kubernetesはデフォルトでフラットネットワークを採用しており、任意のポッドが他のポッドと通信可能です。このため横方向の移動検知が極めて重要となります。攻撃者はこの特性を悪用し、ネームスペース内でポッド間を移動し、クラスター全体でネームスペース間をエスカレートし、侵害されたポッド内からクラウドメタデータサービスにアクセスします。

TeamPCPworm 2026年2月）はこのパターンを大規模に実証した。 単一のポッド足場を足掛かりに、同グループはクラスター全体の列挙、ワークロード横断的なコマンド実行、特権DaemonSetの展開を可能とし、クラスターを分散型ボットネットへと変貌させました。これにより少なくとも185台のサーバーが侵害されました（eSecurity Planet）。コンテナベースの横方向移動攻撃が2025年に34%増加する中、検知 東西方向トラフィックパターンの検知 もはや任意の対策ではありません。

振る舞い for Kubernetes

振る舞い 、既知のシグネチャとの照合ではなく、異常なパターンの特定に焦点を当てます。Kubernetes環境では、これらのパターンには異常なAPI呼び出し、予期しないポッド間通信、認証情報のアクセス異常、リソースハイジャックの兆候などが含まれます。

2026年1月に公表されたKubernetesテレメトリの脆弱性は、このアプローチが重要である理由を示している。 研究者らは、監視ツールに一般的に付与されるノード/プロキシのGET RBAC権限が、Kubelet APIを介してポッド内で任意のコマンドを実行するために悪用され得ることを発見した。Kubernetesはこれを「意図した動作」と分類し、パッチを発行しない方針だ。唯一の防御策は、監視サービスアカウントからの異常なexec操作を検知することである（The New Stack）—振る舞い 脅威ハンティングの典型的な適用事例と言える。

Kubernetesの脅威に対する検知方法には以下が含まれます：

• API呼び出しパターンとワークロード動作の振る舞い
• 異常なポッド間通信に対する東西方向トラフィック監視
• 不正なリソースアクセスに対する異常なAPI呼び出しの検知
• トークン窃取または不正使用のための認証情報アクセスパターンの分析
• リソースハイジャックの兆候（予期せぬCPUやメモリ使用量の急増など）

KubernetesにおけるNDRとネットワーク可視性

主要なKubernetesセキュリティガイドのいずれも、ネットワーク検知とレスポンス（NDR）がKubernetesセキュリティとどのように統合されるかを論じていない。これは重大な盲点である。なぜなら、ネットワークレベルの可視性は、設定ベースのツールが完全に見逃す脅威を検知するからだ。

NDRはKubernetesクラスター内の東西方向トラフィック可視化を提供し、予期せぬサービスに到達するポッド、ネームスペース間の異常なデータ量、横方向チャネルを通じたデータ漏洩の試みなど、異常な通信パターンを特定します。これにより、設定スキャンやポリシー適用をネットワークレベルでの能動的脅威検知で補完し、Kubernetesセキュリティのベストプラクティスを採用しているにもかかわらず90%の組織が依然としてインシデントを経験する原因となる検知のギャップに対処します。

Kubernetesのセキュリティ態勢管理とコンプライアンス

KSPMは継続的なコンプライアンス可視性を提供し、Kubernetesの制御を規制フレームワークにマッピングすることは、企業導入において今や不可欠です。Kubernetesセキュリティポスチャ管理（KSPM）は、セキュリティベースラインに対してクラスター構成を継続的に評価し、設定ミス、ポリシー違反、コンプライアンスのギャップをリアルタイムで特定します。

KSPMとは何ですか？

KSPMツール（Kubescape、Wiz、Prisma Cloud、Sysdigなど）は、CISベンチマーク、Podセキュリティ基準、カスタム組織ポリシーなどのセキュリティ基準に対して、Kubernetesクラスター構成の継続的評価を提供します。kube-benchによって評価されるCIS Kubernetes Benchmarkは、クラスター強化において最も広く採用されている基準です。OWASP Kubernetes Top 10は、優先順位付けされたリスクフレームワークを提供し、不安全なワークロード構成（K01）、サプライチェーン脆弱性（K02）、過度に寛容なRBAC（K03）、ポリシー適用ギャップ（K04）、不十分なロギング（K05）、脆弱なコンポーネント（K10）までを網羅しています。2025年版に向けた更新作業が現在進行中です。

規制対象業界向けコンプライアンスマッピング

NSA/CISA Kubernetes強化ガイドv1.2（2022年8月）は、サプライチェーンリスク、悪意のある脅威アクター、内部者脅威を網羅するKubernetesセキュリティに関する政府の権威ある参照資料であり続けている。コンプライアンス自動化は2026年に強化され、組織は定期的な手動評価ではなく自動化された証拠収集を通じて継続的なコンプライアンスを実証することが求められるようになる（Veeam）。

表3：主要な規制フレームワークに対応するKubernetesセキュリティ制御

SBOM要件は、OMB M-26-05が2026年1月にリスクベースアプローチへ移行したことで進化を遂げている。クラウドサービスプロバイダーは現在、要求に応じて稼働中の本番環境のSBOMを提供する必要があり、これによりKubernetes CI/CDパイプラインへのSBOM生成の統合が推進されている。

Kubernetesセキュリティへの現代的なアプローチ

Kubernetesセキュリティは、eBPFベースのツール群、プラットフォームの強化、そして予防のみから検知主導の防御戦略への移行により急速に成熟している。2025年から2026年にかけてのいくつかの進展が、組織がKubernetesセキュリティアーキテクチャにアプローチする方法を再構築している。

プラットフォームの強化が加速している。2025年中にKubernetes v1.32-v1.35において6つの主要セキュリティ機能が安定版ステータスに達した。これにはバウンドサービスアカウントトークンの改善、サイドカーコンテナ、再帰的読み取り専用マウント、セレクタベース認証、匿名リクエスト制限、順序付きネームスペース削除が含まれる。 さらに8つの機能が2026年に安定版となる見込みで、ユーザーネームスペース、mTLS用Pod証明書、イメージプル認証などが含まれる（CNCF 2025）。

重要インフラの移行には注意が必要です。Ingress-NGINXは2026年3月にサポート終了を迎え、以降は新機能リリース、バグ修正、セキュリティパッチの提供が一切行われません。Kubernetesセキュリティ対応委員会はGateway APIへの移行を推奨しています（Kubernetes Blog）。レガシーなIngress-NGINXコントローラーを維持する組織は、パッチ未適用の脆弱性に晒されるリスクがあります。

市場評価が史上最高水準に達している。GoogleによるWizの320億ドル買収はサイバーセキュリティ分野における史上最大の買収であり、クラウドネイティブセキュリティ市場の正当性を証明するとともに、業界最大手企業にとってKubernetesセキュリティツールとプラットフォームが戦略的優先事項であることを示している（The Register）。

DevSecOpsの導入が加速している。現在42％の組織が高度なDevSecOpsイニシアチブを実施中であり、48％が導入初期段階にある（Red Hat 2024）。セキュリティの追加的対応から統合的セキュリティ実践へのこの移行により、開発速度とセキュリティカバレッジの間のギャップが縮小している。

Vectra AIのKubernetesセキュリティへのアプローチ

Vectra AIKubernetesセキュリティへのアプローチは、振る舞い 検知と Attack Signal Intelligence。設定スキャンやポリシー適用だけに依存するのではなく、Vectra AI はハイブリッドクラウド環境全体（Kubernetesクラスター内の東西方向トラフィックを含む）のネットワークトラフィックパターンをVectra AI 、進行中の攻撃の振る舞い 検知 。 このアプローチは「侵害を前提とする」という考え方に基づいています。つまり、高度な攻撃者は最終的に防御策を回避するため、侵害後の行動（横方向の移動、権限昇格、データ窃取など）を検知することが実際のリスク低減につながります。設定ベースのツールを補完するネットワーク検知・対応機能を提供することで、組織は防御だけでは阻止できない脅威を特定するために必要な可視性を獲得します。

‍