【テクニカル・上級編】コンテナのネットワーク分離(Network Policies) – インフラ・ネットワーク & クラウドセキュリティ防御ガイド

コンテナの「見えない穴」を塞ぐ：Network Policiesによるラテラルムーブメントの封じ込め

現場でインシデントレスポンスに当たっていると、侵入者の手口がいかに「地味で効率的」であるかに驚かされる。多くのエンジニアは、エッジのWAFや高価なEDRを導入して「外敵」との戦いに明け暮れるが、一度シェルを取られた後の世界――つまり、クラスター内部のネットワークが「フラット（やりたい放題）」であるという致命的な設計ミスに気づいていない。

Kubernetesのデフォルト設定は、いわば「鍵のかかっていないシェアハウス」だ。一度どこかの部屋に侵入すれば、家中のどの部屋にも自由にノックして歩ける。これがラテラルムーブメント（水平移動）の温床であり、攻撃者が特権昇格やデータ持ち出しを完遂するための高速道路となる。

本稿では、単なるガイドラインの羅列を超え、攻撃者がパケットレベルでどのような挙動を狙うのか、そしてそれに対してアーキテクトがどう「物理法則」を書き換えるべきかを説く。

1. パケット構造とプロトコルの盲点：なぜ「デフォルト拒否」が必要か

攻撃者は、侵害したPodから nmap や tcpdump を走らせ、ClusterIP をスキャンして内部サービス（redis, database, metadata-api）を探索する。TCPの3ウェイ・ハンドシェイクが確立できるということは、通信経路がオープンであることを意味する。

特に厄介なのは、Kubernetesの Service オブジェクトが提供する抽象化レイヤーだ。IPレベルでの制御をOSの iptables や IPVS に依存しているため、ネットワークポリシーを適用しないことは、カーネルのルーティングテーブルを全開放しているのと同義である。

ここでの防衛の基本は、「Default Deny (全拒否) してから、必要な道だけを掘る」ことだ。

2. 実装：L7を意識したネットワークポリシーの設計

以下は、あるWebアプリケーションのバックエンド（app: api）に対して、特定のフロントエンド（app: web）からのみ通信を許可する、堅牢なポリシーのサンプルだ。

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: api-restrict-ingress
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api # 対象はAPIサーバー
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: web # フロントエンドからの通信のみ許可
    ports:
    - protocol: TCP
      port: 8080 # 特定のポート以外は遮断される

なぜこれが「耐量子」や「プロンプトインジェクション」と繋がるのか？

一見、単純なACL設定に見えるが、このアーキテクチャの真価は「攻撃の爆発半径（Blast Radius）」を最小化することにある。

例えば、大規模言語モデル（LLM）のバックエンドに接続するAPIサーバーが、万が一プロンプトインジェクションによってリモートコード実行を許したとしよう。もしネットワークポリシーが適切に設定されていれば、攻撃者は「LLM APIへの接続」と「データベースへの接続」しかできず、メタデータサーバー（169.254.169.254）からIAMロールを盗み出すといった、クラウド環境特有の特権昇格ルートを封じることができる。

セキュリティとは、「脆弱性が存在することを前提に、その被害を線形的に封じ込めること」である。

3. チーフアーキテクトが意識すべき「監査の解像度」

ネットワークポリシーを記述するだけでは不十分だ。我々が真に恐れるのは、「設定が期待通りに動いているか」という不確実性である。

1. トラフィックの可視化: Cilium などの eBPF ベースのCNIを採用せよ。従来の iptables はルール数が増えるほどレイテンシが増大し、デバッグが困難になる。eBPF を使えば、カーネル空間でパケットを直接ドロップできるため、パフォーマンスを犠牲にせずに高度な可視化が可能だ。
2. ポリシーのテスト（Dry Run）: CI/CDパイプラインに、ポリシー適用後の通信疎通テストを組み込む。許可すべきでない通信が通った場合にビルドを落とすことが、最大の防衛となる。
3. メタデータ API へのアクセス制限: 169.254.169.254 への egress 通信は、特段の理由がない限り、全てのPodで明示的にブロックせよ。これは、SSRF（Server Side Request Forgery）攻撃を無力化するための「最後の砦」だ。

結論：ゼロトラストは「境界」を消すことではない

ネットワークポリシーを記述するという作業は、単なるインフラのメンテナンスではない。それは「どのコンポーネントが何のために存在し、誰と対話すべきか」というシステムの本質を定義する作業だ。

攻撃者は、あなたのクラスターの「暗黙の信頼」という隙を狙っている。その信頼を全て剥ぎ取り、明示的な許可だけを残したとき、初めてあなたのシステムは堅牢な要塞へと変貌する。

コードを書くとき、設定をYAMLに落とすとき、常に自問してほしい。「もし、このPodが今日、攻撃者の手に落ちたら、被害はどこで止まるか？」と。その問いに対する答えが、あなたが記述すべきネットワークポリシーの正体である。