【テクニカル・上級編】 Kubernetes NetworkPolicyによるマイクロセグメンテーション – インフラ・ネットワーク & クラウドセキュリティ防御ガイド

Kubernetesの「性善説」を殺せ：Default Denyによるマイクロセグメンテーションの真髄

インフラエンジニアの多くがKubernetes（K8s）に抱く最大の幻想は、「クラスタ内なら安全だ」という甘美な勘違いだ。しかし、攻撃者の視点から見れば、K8sは「一度潜り込めば、フラットなネットワークを縦横無尽に徘徊できる夢のような狩場」に他ならない。

CVE-2024-21626のようなコンテナランタイムの脆弱性や、不適切なPodSecurityContextの隙を突いてホスト権限を奪取した攻撃者が、次に何をするか？答えは明白だ。ラテラルムーブメント（横方向への移動）である。

今回は、セキュリティアーキテクトが避けては通れない、Kubernetesにおける「Default Deny」とマイクロセグメンテーションの防衛論理を、泥臭い実戦の観点から解き明かす。

1. なぜ「ネットワークポリシーがない」のが致命的なのか

K8sのデフォルト状態では、全てのPodは全てのPodと通信可能だ。これは「利便性」という名のセキュリティホールである。

攻撃者がWebフロントエンドのPodへRCE（リモートコード実行）に成功した瞬間、彼らは即座にkubectlのバイナリを探す必要すらない。内部APIサーバーのトークンを盗み出し、あるいは単にTCPスキャンをかけるだけで、バックエンドのデータベースや、特権を持つ内部サービスへ直接アクセスを試みる。

この「境界防御」の概念が抜け落ちたアーキテクチャでは、侵入＝クラスタ全体の陥落を意味する。

2. Default Deny: ゼロトラストの第一歩

マイクロセグメンテーションの出発点は「全遮断」である。まずは、名前空間（Namespace）内の全通信を物理的に断ち切ることから始める。

以下のマニフェストは、特定の名前空間において「何者も通信できない」状態を作り出すための最強の防衛障壁だ。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production # 適用対象の名前空間
spec:
  podSelector: {} # セレクタを空にすることで、全てのPodに適用
  policyTypes:
  - Ingress
  - Egress

これを適用した瞬間、アプリケーションは死ぬ。しかし、これこそが「正しい設計」のスタートラインだ。ここから、「必要な通信だけをホワイトリストとして開けていく」という、セキュリティの基本原則に立ち戻る。

3. ラベルセレクタを用いた「最小権限」の強制

通信を許可する際は、IPアドレスベースのフィルタリングなどという前時代的な手法は捨てろ。K8sが提供する「ラベルセレクタ」こそが、可変的なインフラにおける唯一の正解だ。

例えば、app: frontend から app: backend への通信だけを許可する設定は以下のようになる。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
spec:
  podSelector:
    matchLabels:
      app: backend # 通信を受ける側のPod
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend # 通信元を厳密に指定
    ports:
    - protocol: TCP
      port: 8080 # 必要なポートのみを開放

ここで重要なのは、「何が通信できるか」ではなく「何を拒否すべきか」を常に意識する姿勢だ。不必要なEgress（外向き通信）も同様に遮断すべきだ。攻撃者が侵入した際、外部のC2サーバーへペイロードをダウンロードさせる通信路を断つだけで、攻撃の成功率は劇的に下がる。

4. プロトコル解析と隠れた脆弱性へのアプローチ

我々が守るべきはL3/L4レイヤだけではない。昨今、AIモデルを組み込んだアプリでは、プロンプトインジェクションによる「内部APIの不正利用」が深刻な脅威となっている。

たとえNetworkPolicyで通信経路を絞っても、アプリ層で認証なしに内部APIを叩けるなら意味がない。

ガードレイルの実装: Service Mesh（Istio等）を導入し、mTLSによる相互認証を強制せよ。
ペネトレーションテストの観点: tcpdumpでパケットをキャプチャし、期待しないペイロードが内部ネットワークを流れていないか、定期的な監査を実施せよ。

5. 結論：運用に「妥協」を持ち込むな

「Default Deny」を導入すると、開発チームから必ず反発が来る。しかし、セキュリティアーキテクトとしての矜持は、そこで折れないことだ。

1. CI/CDへの組み込み: ネットワークポリシーの適用をIaC（Infrastructure as Code）で管理し、自動テストで通信の疎通確認を行う。
2. 可観測性（Observability）の強化: Hubble（Cilium）などのツールを使い、どのPodがどこにアクセスしようとしているかを可視化せよ。許可されていない通信のログこそが、攻撃の予兆を教えてくれる最高のアラートだ。

Kubernetesの要塞化とは、魔法のような設定ファイルを一つ書くことではない。「何がどこへ繋がるべきか」というビジネス上のロジックを、コードレベルで厳密に定義し続ける執念のことだ。

この「泥臭い分離」こそが、高度な標的型攻撃を防ぐ最後の防波堤となる。アーキテクト諸君、まずは default-deny-all を適用することから始めよう。壊れたサービスを直す作業の中にこそ、真のセキュリティ改善のヒントが隠されている。