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

Kubernetesにおけるマイクロセグメンテーション：NetworkPolicyによる「最小権限」の徹底実装

サイバー攻撃の最前線で幾度となく死線を潜り抜けてきた者として、我々が日々直面しているのは、単なる脆弱性情報の羅列ではない。それは、人間心理の隙、プロトコルの設計思想の甘さ、そして何よりも、システムという名の「生き物」が持つ、予期せぬ「病巣」だ。Kubernetesの世界も例外ではない。その俊敏性と柔軟性の裏側で、攻撃者は常に新たな侵入口を探し求めている。

今回は、KubernetesにおけるPod間通信のマイクロセグメンテーション、特にNetworkPolicyを用いた「最小権限」の徹底実装に焦点を当てる。これは、単なるセキュリティベストプラクティスを超え、攻撃者が一旦ネットワークの境界を突破したとしても、その被害を局所化し、システム全体の崩壊を防ぐための「最後の砦」となり得る技術だ。

なぜマイクロセグメンテーションが重要なのか？

従来のネットワークセキュリティは、しばしば「城壁と堀」モデルに例えられる。外部からの侵入を防ぐための強力な境界防御は不可欠だが、一度その境界が破られた場合、内部では比較的自由な移動が許されてしまう。これを「ラテラルムーブメント」と呼ぶ。攻撃者は、侵害したホストから他のホストへと横移動を繰り返し、最終的に機密情報やシステムの中核へと到達しようとする。

Kubernetes環境では、Podというコンテナ化されたアプリケーションが動的に生成・削除され、そのIPアドレスも頻繁に変動する。従来のIPアドレスベースのファイアウォールでは、この動的な環境に対応することは困難だ。ここで登場するのがNetworkPolicyだ。

NetworkPolicyは、Podのラベルセレクターを介して通信を制御する、Kubernetesネイティブのネットワークポリシーリソースだ。これにより、IPアドレスの変動に左右されることなく、Podの論理的なグループに基づいて通信を定義できる。まさに、攻撃者のラテラルムーブメントを阻止するための、精緻な「内部の境界線」を引く技術と言えるだろう。

NetworkPolicyの基本：ホワイトリスト方式による「許可」の原則

NetworkPolicyの肝は、その「ホワイトリスト」方式にある。デフォルトでは、Kubernetesクラスター内のPod間の通信は原則としてすべて許可されている。しかし、NetworkPolicyを適用することで、明示的に許可された通信のみが有効となる。これは、セキュリティの基本原則である「最小権限の原則」をネットワークレベルで具現化するものだ。

NetworkPolicyリソースは、以下の要素で構成される。

  • podSelector: このポリシーが適用されるPodを指定するラベルセレクター。
  • policyTypes: このポリシーが適用される通信の種類（Ingress: 受信、Egress: 送信）。
  • ingress: 許可される受信トラフィックのルール。
  • egress: 許可される送信トラフィックのルール。

ingressとegressのルールでは、さらに以下の要素を定義する。

  • from / to: 通信元/通信先として許可されるPod（ラベルセレクター）、名前空間、IPブロック。
  • ports: 許可されるTCP/UDPポート。

実践的なNetworkPolicyの例

ここでは、具体的なシナリオを想定してNetworkPolicyを作成してみよう。

シナリオ:
Webアプリケーション（app=frontendラベル）は、バックエンドAPI（app=backendラベル）とのみ通信を許可する。バックエンドAPIは、データベース（app=databaseラベル）とのみ通信を許可する。それ以外の通信はすべて拒否する。

1. Frontend PodへのIngress（受信）ポリシー

このポリシーは、外部からのWebトラフィック（通常はIngress Controller経由）をfrontend Podに許可する。frontend Pod自身は、他のPodからの受信通信を一切許可しない（デフォルトで拒否）。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: frontend-ingress
  namespace: default # ポリシーを適用する名前空間を指定
spec:
  podSelector:
    matchLabels:
      app: frontend # このポリシーが適用されるPod (frontendラベルを持つPod)
  policyTypes:
    - Ingress # 受信トラフィックのみを制御
  ingress:
    - {} # 空のリストは、デフォルトですべてのIngressを拒否することを意味しない。
         # しかし、policyTypesにIngressのみを指定しているため、
         # Egressはデフォルトで許可される。
         # 外部からのIngressを明示的に許可するには、
         # Ingress ControllerなどのIPアドレス範囲を指定する必要がある。
         # ここでは、例として、特定のNamespaceからのIngressを許可する。
    - from:
        - namespaceSelector:
            matchLabels:
              name: ingress-controller # Ingress Controllerが配置されているNamespaceのラベル

解説:

  • podSelector: app: frontendのラベルを持つPodに適用されます。
  • policyTypes: - Ingress: このポリシーは受信トラフィックのみを制御します。
  • ingress: - {}: このルールは、frontend Podへのすべての受信トラフィックを遮断します。ただし、後続のルールで明示的に許可された通信は通過します。
  • from: - namespaceSelector: ingress-controllerというラベルを持つNamespaceからの通信のみを許可します。

2. Frontend PodからのEgress（送信）ポリシー

frontend Podは、backend Podとのみ通信を許可する。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: frontend-egress
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: frontend
  policyTypes:
    - Egress # 送信トラフィックのみを制御
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: backend # backendラベルを持つPodへの通信のみ許可
      ports:
        - protocol: TCP
          port: 8080 # backend APIがリッスンしているポート

解説:

  • podSelector: app: frontendのラベルを持つPodに適用されます。
  • policyTypes: - Egress: このポリシーは送信トラフィックのみを制御します。
  • to: - podSelector: app: backendのラベルを持つPodへの通信のみを許可します。
  • ports: TCPポート8080への通信のみを許可します。

3. Backend PodへのIngress（受信）ポリシー

backend Podは、frontend Podからの通信のみを許可する。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-ingress
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend # frontendラベルを持つPodからの通信のみ許可
      ports:
        - protocol: TCP
          port: 8080 # frontendからの通信を受け付けるポート

解説:

  • podSelector: app: backendのラベルを持つPodに適用されます。
  • policyTypes: - Ingress: 受信トラフィックを制御します。
  • from: - podSelector: app: frontendのラベルを持つPodからの通信のみを許可します。
  • ports: TCPポート8080への通信のみを許可します。

4. Backend PodからのEgress（送信）ポリシー

backend Podは、database Podとのみ通信を許可する。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-egress
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
    - Egress
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: database # databaseラベルを持つPodへの通信のみ許可
      ports:
        - protocol: TCP
          port: 5432 # PostgreSQLなどのDBポート

解説:

  • podSelector: app: backendのラベルを持つPodに適用されます。
  • policyTypes: - Egress: 送信トラフィックを制御します。
  • to: - podSelector: app: databaseのラベルを持つPodへの通信のみを許可します。
  • ports: TCPポート5432への通信のみを許可します。

5. Database PodへのIngress（受信）ポリシー

database Podは、backend Podからの通信のみを許可する。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database-ingress
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: database
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: backend # backendラベルを持つPodからの通信のみ許可
      ports:
        - protocol: TCP
          port: 5432 # DBポート

解説:

  • podSelector: app: databaseのラベルを持つPodに適用されます。
  • policyTypes: - Ingress: 受信トラフィックを制御します。
  • from: - podSelector: app: backendのラベルを持つPodからの通信のみを許可します。
  • ports: TCPポート5432への通信のみを許可します。

これらのポリシーを適用することで、frontend → backend → databaseという、定義されたパス以外の通信はすべてブロックされます。これにより、仮にfrontend Podが侵害されたとしても、攻撃者はbackend Podやdatabase Podへと容易に横移動することはできなくなります。

低レイヤとプロトコル仕様の観点からの考察

NetworkPolicyはKubernetes APIレベルで定義されますが、その背後ではCNI（Container Network Interface）プラグイン（Calico, Cilium, Weave Netなど）が実働しています。これらのプラグインは、LinuxカーネルのNetfilter（iptablesやnftables）やeBPF（extended Berkeley Packet Filter）といった技術を利用して、実際のパケットフィルタリングを行います。

  • Netfilter/iptables: 伝統的なパケットフィルタリング機構であり、NetworkPolicyのルールをiptablesルールとしてクラスターノードに展開します。大量のPodや複雑なポリシーが適用されると、iptablesルールの数が増大し、パフォーマンスのボトルネックとなる可能性があります。パケットヘッダのフィールド（IPアドレス、ポート、プロトコル）を検査し、ルールにマッチするかどうかを判断します。
  • eBPF: より近代的で効率的なカーネル内プログラム実行環境です。eBPFを利用するCNIプラグイン（例: Cilium）は、パケットをカーネル空間で直接処理し、ユーザー空間へのコンテキストスイッチを最小限に抑えることで、優れたパフォーマンスとスケーラビリティを実現します。eBPFは、パケットのペイロードの一部を検査することも可能であり、より高度なL7（アプリケーション層）のポリシー適用も視野に入ります。

脆弱性の根本原因としての低レイヤ:
NetworkPolicy自体が直接的なCVEを生み出すことは稀ですが、その基盤となるCNIプラグインやLinuxカーネルのネットワークスタックに脆弱性が存在する場合、NetworkPolicyで意図したセキュリティが実現できない可能性があります。例えば、パケット処理のバッファオーバーフローや、不正なパケットに対するロジックの誤りなどが、予期せぬ通信の許可やサービス拒否（DoS）につながることも考えられます。

プロトコル仕様の欠陥:
TCP/IPやHTTPなどの標準プロトコルには、設計上あるいは実装上の欠陥が存在する可能性があります。攻撃者はこれらの欠陥を突くことで、NetworkPolicyのフィルタリングを回避しようと試みます。例えば、フラグメント化されたパケットの再構築処理の不備、TCPオプションの悪用、あるいはHTTP/2のストリーム多重化における脆弱性などが考えられます。

NetworkPolicyを設計・運用する際には、これらの低レイヤの挙動やプロトコル仕様にも目を向ける必要があります。CNIプラグインの選定、バージョンアップ、そしてLinuxカーネルのセキュリティアップデートは、マイクロセグメンテーションの堅牢性を維持するために不可欠です。

耐量子暗号への移行と生成AIのプロンプトインジェクション防御

話は少し飛躍しますが、将来的な脅威として、耐量子暗号（Post-Quantum Cryptography, PQC）への移行は避けて通れません。量子コンピュータが実用化されれば、現在の公開鍵暗号（RSA, ECCなど）は容易に破られる可能性があります。Kubernetesクラスター内の通信暗号化（mTLSなど）や、etcdへのアクセス保護など、PQCへの対応は、長期的視点でのセキュリティ戦略において重要な要素となります。

また、生成AIの台頭により、新たな攻撃ベクトルも生まれています。プロンプトインジェクションは、AIモデルに意図しない指示を実行させる攻撃です。Kubernetes環境において、AIモデルがPodとしてデプロイされる場合、そのAIモデルへのアクセス制御、およびAIモデルから他のサービスへのアウトバウンド通信の制御は、NetworkPolicyで厳密に定義されるべきです。

例えば、AIモデルが機密データにアクセスしたり、他のシステムを操作したりする能力を持つ場合、その能力を必要最低限に制限することが極めて重要です。

生成AIガードレイルとしてのNetworkPolicy:

  • 入力制御: AIモデルへのリクエスト（プロンプト）は、信頼できるソース（例: 特定のWebフロントエンド）からのみ許可する。
  • 出力制御: AIモデルが外部APIを呼び出す場合、許可されたAPIエンドポイントとメソッドのみを許可する。
  • データアクセス制御: AIモデルがデータベースなどのデータストアにアクセスする場合、読み取り専用、あるいは特定のテーブルへのアクセスに限定する。

これは、NetworkPolicyのingressとegressルールを、AIアプリケーションの特性に合わせて細かく設定することで実現可能です。

監査と継続的な改善

NetworkPolicyは一度設定すれば終わりではありません。システムの変化、アプリケーションの追加・更新に伴い、ポリシーも継続的に見直し、更新していく必要があります。

  • 可視化と監視: NetworkPolicyの適用状況や、ブロックされている通信を可視化するツール（例: CiliumのHubble、Kiali）を活用し、意図しない通信がないか、あるいは必要な通信がブロックされていないかを確認します。
  • 定期的なレビュー: 定期的にNetworkPolicyの設定を見直し、不要な通信許可がないか、最小権限の原則に沿っているかを確認します。
  • 自動化: CI/CDパイプラインにNetworkPolicyの検証ステップを組み込み、ポリシーの変更がシステムに与える影響を事前に評価します。

結論

KubernetesにおけるNetworkPolicyを用いたマイクロセグメンテーションは、攻撃者のラテラルムーブメントを阻止し、システム全体のセキュリティ体制を強化するための強力な手段です。これは、単に通信を遮断するだけでなく、「最小権限の原則」をネットワークレベルで実践するためのアーキテクチャ設計そのものです。

我々セキュリティ専門家は、常に攻撃者の視点に立ち、システムの「病巣」を見つけ出し、それを塞ぐための精緻な防御策を講じ続けなければなりません。NetworkPolicyは、そのための重要なツールの一つであり、その実装と運用は、我々の日々の職務における「泥臭い」作業の一部なのです。

この技術を深く理解し、適切に実装・運用することで、Kubernetesクラスターのセキュリティレベルを一層高め、より安全なシステムを構築していきましょう。

スポンサーリンク

コメント

タイトルとURLをコピーしました