NetworkPolicy（ネットワークポリシー）

2025年11月6日

NetworkPolicy（ネットワークポリシー）

英語表記: NetworkPolicy

概要

NetworkPolicyは、Kubernetesクラスタ（オーケストレーション環境）内で動作するアプリケーション群であるPod間の通信を制御するために使用されるセキュリティリソースです。これは、従来のネットワークファイアウォールが持つ機能宣言的にクラスタ内部に持ち込み、どのPodがどのPodと通信できるかを厳密に定義します。NetworkPolicyを適切に設定することで、クラスタセキュリティ（Minor Category）を大幅に強化し、不正なアクセスや内部での横方向の移動（Lateral Movement）を防ぐ重要な役割を果たします。

詳細解説

NetworkPolicyは、コンテナ化されたマイクロサービス環境において、セキュリティとガバナンス（Middle Category）を担保するために不可欠な要素です。Kubernetesの設計思想に基づき、NetworkPolicyは「ゼロトラスト」の原則、つまり「何も信頼しない」という考え方に基づいて運用されます。

目的と動作原理

NetworkPolicyの最大の目的は、Pod間のトラフィックフローを最小限に必要なものだけに制限することです。通常、Kubernetesクラスタ内では、特に設定を行わない限り、すべてのPodが互いに通信可能です。しかし、この自由な状態は、万が一アプリケーションの一部が侵害された場合に、攻撃者がクラスタ全体に容易に拡散してしまうリスクを伴います。

NetworkPolicyは、このデフォルトの「すべて許可」の状態を変更し、セキュリティポリシーを宣言的に適用します。具体的には、ユーザーがYAMLファイルで「このPodグループ（ラベルで識別）は、このPodグループからの、このポートへの通信のみを許可する」といったルールを記述します。

主要な構成要素

NetworkPolicyを定義する上で理解すべき主要な構成要素は以下の通りです。

Podセレクター (podSelector):
どのPodに対してこのポリシーを適用するかを指定します。ポリシーは、このセレクターに一致するPodにのみ影響を与えます。
ポリシータイプ (policyTypes):
このポリシーがインバウンド（Ingress：外から中へ）の通信を制御するのか、アウトバウンド（Egress：中から外へ）の通信を制御するのかを指定します。両方を指定することも一般的です。
ルール定義 (ingress/egress rules):
Ingressルールでは、どこからのトラフィックを許可するか（from）を定義します。Egressルールでは、どこへのトラフィックを許可するか（to）を定義します。許可の対象は、他のPod、ネームスペース、またはCIDRブロック（IPアドレス範囲）によって指定されます。

オーケストレーション環境での重要性

NetworkPolicy自体は、単なる設定ファイル（宣言）であり、実際のトラフィックのフィルタリング処理は、CNI（Container Network Interface）プラグイン（例：Calico、Cilium、Flannelなど）によって実行されます。

この「宣言と実行の分離」こそが、オーケストレーション（Major Category）におけるセキュリティの鍵です。KubernetesはPodが起動・停止するたびに動的にIPアドレスが変わる環境ですが、NetworkPolicyはIPアドレスではなく「ラベル」に基づいて設定されるため、Podのライフサイクルに依存せず、常に正しいセキュリティルールが適用され続けます。これは、手動でサーバーのファイアウォールを設定する伝統的な方法よりも遥かに効率的で安全なアプローチだと言えます。

具体例・活用シーン

NetworkPolicyは、機密性の高いデータを扱うPodを保護する際に、非常に有効な手段となります。

実例：データベースPodの保護

あるKubernetesクラスタに、以下の3種類のPodが存在するとします。

web-frontend Pod (ラベル: app: web)
api-backend Pod (ラベル: app: api)
database Pod (ラベル: app: db)

セキュリティ要件として、「database Podへのアクセスは、api-backend Podからポート3306経由でのみ許可し、他のすべてのPodからのアクセスは拒否する」とします。

podSelector に app: db を指定します。
ingress ルールを設定し、許可する送信元として podSelector: {app: api} および port: 3306/TCP を定義します。

このポリシーが適用されると、web-frontend Podや、その他の監視ツールPodなどが誤ってデータベースに接続しようとしても、CNIによって通信がL3/L4レベルでブロックされます。

アナロジー：オフィスビルの入館証システム

NetworkPolicyの役割を理解するための良いメタファーは、「スマートなオフィスビルの入館証システム」です。

Kubernetesクラスタ全体を巨大なオフィスビルだと考えてください。このビルの中では、部署（ネームスペース）や役割（Pod）が混在しています。

NetworkPolicyがない状態は、すべての人が自由に、どの部屋にも、どのドア（ポート）からでも入れる状態です。これではセキュリティは成り立ちません。

NetworkPolicyを適用するということは、各部署（Pod）に「入館証のルール」を適用することに他なりません。

例えば、経理部の部屋（データベースPod）に入ることができるのは、「開発チーム」の入館証（特定のラベルを持つPod）を持つ人だけであり、かつ「正面玄関」（特定のポート）からのみ入室が許可されます。他の部署の入館証や、裏口からのアクセスはすべて自動的に拒否されます。

この入館証システム（NetworkPolicy）は、誰がどこにアクセスすべきかを明確にすることで、万が一誰かの入館証が盗まれた（Podが侵害された）としても、被害を最小限に抑える（クラスタセキュリティを担保する）働きをします。

資格試験向けチェックポイント

NetworkPolicyは、特に応用情報技術者試験や、Kubernetes技術者認定試験（CKA/CKAD）で重要視されるトピックです。

宣言的アプローチの理解（IT Passport / 基本情報）: NetworkPolicyは、手動で設定するのではなく、必要な状態を記述する「宣言的（Declarative）」なアプローチを取ります。この宣言的アプローチこそが、オーケストレーションシステムの特徴であることを理解しておきましょう。
デフォルト拒否の原則（基本情報 / 応用情報）: NetworkPolicyが設定されていないネームスペースでは、デフォルトで通信は許可されます。しかし、一度でもNetworkPolicyを適用すると、そのネームスペースでは、明示的に許可されていないすべての通信がデフォルトで拒否（Deny All）になるという動作特性は、試験で頻繁に問われる重要ポイントです。
レイヤーの識別（応用情報）: NetworkPolicyは、主にOSI参照モデルのL3（IPアドレス）およびL4（ポート番号）レベルでの通信を制御します。L7（アプリケーション層）の制御（例：HTTPパスやヘッダーによる制御）はできません。L7制御が必要な場合は、Istioなどのサービスメッシュ技術と対比して出題されることがあります。
CNIとの関係（応用情報）: NetworkPolicyの定義はKubernetesが行いますが、実際にそのルールをネットワークパケットに適用するのは、CiliumやCalicoといったCNI（Container Network Interface）プラグインの役割です。この分業体制を理解することが、クラスタセキュリティの仕組みを把握する上で重要です。