Kubernetes

ネットワークポリシー ねっとわーくぽりしー

KubernetesPod間通信ファイアウォールCNIセキュリティマイクロサービス
ネットワークポリシーについて教えて

簡単に言うとこんな感じ!

Kubernetes の中で動くアプリ同士の「誰と話してよくて、誰とはダメか」を決めるルールブックだよ!オフィスの入退室カードみたいなもので、特定のアプリにしか通信できないよう制限できるんだ。


ネットワークポリシーとは

Kubernetes では、デフォルトの状態だとクラスター内のすべての Pod(アプリの最小実行単位)が互いに自由に通信できます。小規模なシステムならそれで問題ないですが、決済サービスや個人情報を扱うデータベースなど、アクセスを限定したいコンポーネントが出てくると話が変わります。

ネットワークポリシー(NetworkPolicy) とは、Kubernetes が提供するリソースの一種で、「どの Pod がどの Pod と通信できるか」をラベルベースで細かく制御する仕組みです。いわばクラスター内部のソフトウェア的なファイアウォールであり、L3(IPアドレス)〜L4(ポート番号)レベルで通信の許可・拒否を定義できます。

ネットワークポリシーを適切に設定することで、万が一クラスター内の一部が侵害されても、被害が横方向に広がる「ラテラルムーブメント」を防ぐことができます。マイクロサービスアーキテクチャにおけるゼロトラストセキュリティの実現に欠かせない機能です。


ネットワークポリシーの仕組みと構造

ネットワークポリシーは YAML で記述し、主に次の3つの要素で構成されます。

要素役割例え
podSelectorどの Pod にこのポリシーを適用するか「このルールを適用する対象者」
ingress(受信)その Pod への通信を誰に許可するか「誰が入ってきてよいか」
egress(送信)その Pod からの通信をどこに許可するか「どこへ出て行ってよいか」

覚え方:「in(入る)が ingress、out(出る)が egress」

ingress は「in(中に入る)」、egress は「exit(出口)の e」と覚えましょう。インバウンド・アウトバウンドと同じ感覚です。

ポリシー適用のルール

ポリシーが1つも適用されていない Pod
  → 全通信が許可(デフォルト)

ポリシーが1つでも適用された Pod
  → ポリシーに明示されていない通信はすべて拒否
  → 明示された通信のみ許可(ホワイトリスト方式)

この「1つでも適用されたら他は全拒否」という動作が重要です。ルールを書き忘れると通信が止まるので注意が必要です。


歴史と背景

  • 2015年: Kubernetes 1.0 リリース。この時点では Pod 間の通信制御は存在せず、全通信が自由に行えた
  • 2016年: Kubernetes 1.3 でネットワークポリシーAPIが試験的に導入される。ただし実装CNI プラグイン側に委ねられた
  • 2017年: Kubernetes 1.7 で NetworkPolicy が安定版(GA)に昇格。本番利用が本格化
  • 2018年〜: Calico・Cilium・Weave Net などの CNI(Container Network Interface) プラグインがネットワークポリシーの実装をサポートし、広く普及
  • 2020年代: ゼロトラストセキュリティの文脈で注目度が増し、Cilium の eBPF ベース実装など高機能なポリシー制御が登場

CNIプラグインとネットワークポリシーの関係

ネットワークポリシーは「ルールを定義する仕様」であり、実際に通信を制御するのは CNI プラグイン の役割です。Kubernetes 自体はポリシーを保存するだけで、施行(enforce)はしません。

ネットワークポリシーの施行フロー 利用者 NetworkPolicy YAML を apply Kubernetes API サーバー ポリシーを etcd に保存する CNI プラグイン(Calico / Cilium 等) ポリシーを読み取り、実際に通信を制御する Pod A 通信許可 (ポリシーに合致) Pod B 通信ブロック (ポリシーに非合致)

主要な CNI プラグインの比較

CNI プラグインNetworkPolicy サポート特徴
Calico✅ 対応(拡張ポリシーあり)本番環境で最も普及。BGP ルーティング対応
Cilium✅ 対応(L7まで制御可)eBPF ベースで高性能。HTTP/gRPC レベルの制御も可能
Weave Net✅ 対応セットアップが簡単。小〜中規模向け
Flannel❌ 非対応シンプルだがポリシー機能なし。別途 Calico との併用が必要

⚠️ 重要: CNI プラグインがネットワークポリシーに対応していない場合、YAML を apply してもポリシーは一切有効になりません。導入前に必ず確認しましょう。


YAMLの記述例

実際のネットワークポリシーがどう書かれるか、シンプルな例を見てみましょう。

# 「db」ラベルを持つ Pod への通信を
# 「app: backend」ラベルの Pod からのみ許可する例
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-backend-to-db
  namespace: production
spec:
  podSelector:
    matchLabels:
      role: db          # ← このポリシーの対象Pod
  policyTypes:
    - Ingress           # ← 受信方向を制御
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: backend  # ← backendラベルのPodからのみ許可
      ports:
        - protocol: TCP
          port: 5432        # ← PostgreSQLのポートのみ許可

関連する規格・RFC

規格・仕様内容
Kubernetes NetworkPolicy APInetworking.k8s.io/v1 で定義される公式リソース仕様
CNI(Container Network Interface)仕様CNI プラグインが実装すべきインターフェース仕様。CNCF が管理
CiliumNetworkPolicy / GlobalNetworkPolicyCalico・Cilium 独自の拡張ポリシーリソース(L7制御等)

関連用語

  • Pod — Kubernetes の最小デプロイ単位。ネットワークポリシーの適用対象
  • CNI(Container Network Interface) — コンテナのネットワーク設定を担うプラグイン規格。ポリシーの施行役
  • Namespace — Kubernetes のリソース分離単位。ポリシーはNamespace単位で適用
  • ラベル(Label) — Pod を識別・選択するためのキーバリュー。ポリシーの対象指定に使う
  • Ingress — クラスター外からの HTTP/HTTPS アクセスを制御するリソース(名前が似ているが別物)
  • ゼロトラストセキュリティ — 「何も信頼しない」前提でアクセスを制御するセキュリティ設計思想