ネットワークポリシー ねっとわーくぽりしー
簡単に言うとこんな感じ!
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)はしません。
主要な 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 API | networking.k8s.io/v1 で定義される公式リソース仕様 |
| CNI(Container Network Interface)仕様 | CNI プラグインが実装すべきインターフェース仕様。CNCF が管理 |
| CiliumNetworkPolicy / GlobalNetworkPolicy | Calico・Cilium 独自の拡張ポリシーリソース(L7制御等) |
関連用語
- Pod — Kubernetes の最小デプロイ単位。ネットワークポリシーの適用対象
- CNI(Container Network Interface) — コンテナのネットワーク設定を担うプラグイン規格。ポリシーの施行役
- Namespace — Kubernetes のリソース分離単位。ポリシーはNamespace単位で適用
- ラベル(Label) — Pod を識別・選択するためのキーバリュー。ポリシーの対象指定に使う
- Ingress — クラスター外からの HTTP/HTTPS アクセスを制御するリソース(名前が似ているが別物)
- ゼロトラストセキュリティ — 「何も信頼しない」前提でアクセスを制御するセキュリティ設計思想