Contents
NetworkPolicy の基本概念とデフォルトの非分離状態
Kubernetes において NetworkPolicy は Pod 同士や外部への通信を宣言的に制御できる重要な機能です。
本セクションでは、NetworkPolicy が提供する主な要素と、何も設定しない場合に全 Pod が相互にフリーに通信できてしまうリスクを解説します。
NetworkPolicy が提供する主要機能
NetworkPolicy で定義できる項目は次の通りです。以下の表は各フィールドの概要と利用シーンを示しています。
| フィールド | 用途 | 設定例 |
|---|---|---|
| podSelector | ポリシー適用対象の Pod をラベルで絞り込む | matchLabels: { app: frontend } |
| namespaceSelector | 別 Namespace の Pod へのアクセスを制御 | matchNames: [prod] |
| ingress / egress | 許可する受信・送信トラフィックを詳細に指定 | IPBlock, ポート番号など |
| policyTypes | 適用対象 (Ingress、Egress、または両方) を明示 | ["Ingress","Egress"] |
これらを組み合わせることで、マイクロサービス間の最小権限通信が実現します。
デフォルトで全 Pod が相互に通信できるリスク
Kubernetes のデフォルト状態は non‑isolated です。
つまり NetworkPolicy が存在しない限り、同一クラスター内のすべての Pod が自由に通信できます。このままでは次のような問題が発生しやすくなります。
- 不要な内部トラフィックが増えてネットワーク帯域を圧迫
- 脆弱なコンテナから他サービスへ攻撃が拡大し、被害範囲が広がる
- 法規制や社内セキュリティ基準で求められる「最小権限」の原則に違反
要点：NetworkPolicy を導入しない限り、クラスターは全通信開放状態です。公式ドキュメントでも同様の注意が記載されています（Kubernetes ネットワークポリシー）。
CNI プラグインの選定基準と導入要件
NetworkPolicy を有効にするには、対応した CNI (Container Network Interface) プラグイン が必須です。
本章では 2026 年時点で EKS でも公式サポートされている主要プラグインの概要と、導入前に確認すべきチェックポイントをまとめます。
現行プラグインと推奨バージョン
以下は 2026‑05‑17 時点で安定版として広く採用されているプラグインです。最新リリース情報は各公式 GitHub の Release ページをご参照ください。
| プラグイン | 推奨バージョン (執筆時) | 必要な K8s バージョン | 主なカーネル機能 |
|---|---|---|---|
| Calico | v1.30 以降 | 1.27 以上 | iptables / eBPF (選択可) |
| Cilium | v1.15 以降 | 1.26 以上 | BPF, XDP |
| AWS VPC CNI | v1.14 以降 | 1.25 以上 | ENI 管理権限（IAM） |
バージョン管理方針
プラグインは Helm またはkubectl apply -fによるマニフェストで導入し、Chart.yamlやkustomization.yamlにバージョンを固定化します。
定期的（例：四半期ごと）に公式リポジトリの Release ノートを確認し、セキュリティパッチや機能追加があればアップグレードを計画してください。
* 最新情報は下記リンクから取得できます。
- Calico: https://github.com/projectcalico/calico/releases
- Cilium: https://github.com/cilium/cilium/releases
- AWS VPC CNI: https://github.com/aws/amazon-vpc-cni-k8s/releases
導入前チェックリスト
| 項目 | 確認ポイント |
|---|---|
| Kubernetes バージョン | クラスタがプラグインの最低要件を満たしているか |
| ノード OS とカーネル機能 | iptables、BPF、XDP が有効化されているか（sysctl -a | grep net.ipv4.conf.all.forwarding などで確認） |
| IAM 権限 | ENI 操作が必要な場合はノードロールに AmazonEKS_CNI_Policy を付与。具体例は下記「必要な IAM ポリシー」参照 |
| VPC 設定 | サブネットの IP アドレス枯渇を防ぐため、各 AZ に十分な CIDR が割り当てられているか |
| 既存アドオンとの競合 | Service Mesh（例：Istio）や他の CNI と重複しないことを確認 |
必要な IAM ポリシー（AWS VPC CNI の例）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:AssignPrivateIpAddresses", "ec2:UnassignPrivateIpAddresses", "ec2:CreateNetworkInterface", "ec2:DeleteNetworkInterface", "ec2:DescribeNetworkInterfaces", "ec2:ModifyNetworkInterfaceAttribute" ], "Resource": "*" } ] } |
このポリシーはノードインスタンスロール（例：eks-nodegroup-role）にアタッチしてください。
EKS で NetworkPolicy を有効化する手順
EKS クラスタではデフォルトで NetworkPolicy が無効 です。
既存クラスタに対して安全かつ確実に有効化する方法を、eksctl と AWS コンソールの二通りで解説します。
eksctl による有効化（既存クラスター向け）
eksctl utils update-cluster コマンドでフラグを付与すると、EKS が自動的に Calico ベースの NetworkPolicy アドオンをデプロイします。
|
1 2 3 4 5 6 |
# 例: ap-northeast-1 の prod-cluster に対して有効化 eksctl utils update-cluster \ --region ap-northeast-1 \ --name prod-cluster \ --enable-network-policy |
上記コマンド実行後、以下が自動で適用されます。
- Calico Operator が
kube-system名前空間にデプロイ - 必要な IAM ロール（
AmazonEKS_CNI_Policy）がノードロールに付与済みか検証
ポイント：
eksctl create cluster … --enable-network-policyは新規作成時のみ有効です。既存クラスタの場合はutils update-clusterを使用してください。
AWS コンソールからの設定手順
- AWS Management Console の Amazon EKS → クラスタ 画面へ移動
- 対象クラスタを選択し、左側メニューの 「ネットワーク」 タブを開く
- 「Network Policy」セクションで 「有効化」 スイッチをオンにする
- 保存 をクリックするとバックエンドで Calico がデプロイされ、数分以内に
kubectl get pods -n kube-systemでcalico-operatorとcalico-nodeが Running 状態になることを確認
どちらの方法でも、NetworkPolicy の適用は数分で完了し、その後すぐにポリシー定義が利用可能になります。
ハンズオン：CNI インストールと NetworkPolicy の検証
実際に Calico と Cilium をインストールし、サンプルポリシーを適用して通信が制御されることを確認します。
以下の手順はローカルの Kind クラスタでも、EKS でも同様に機能します。
Calico のインストール例（Helm 使用）
まず Helm リポジトリを追加し、tigera-operator を kube-system にデプロイします。
|
1 2 3 4 5 |
helm repo add projectcalico https://docs.projectcalico.org/charts helm install calico projectcalico/tigera-operator \ --namespace kube-system \ --set installation.calicoNetwork.ipPools[0].cidr="192.168.0.0/16" |
インストール後は kubectl get pods -n kube-system -l k8s-app=tigera-operator で Operator が Running か確認してください。
Cilium のインストール例（マニフェスト適用）
Cilium は公式のクイックインストール YAML を直接適用します。
|
1 2 3 4 5 |
# バージョンが v1.15 以上であることを事前に確認 cilium version # → v1.15.x 以上 kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/v1.15/install/kubernetes/quick-install.yaml |
デプロイ完了は kubectl -n kube-system get pods -l k8s-app=cilium で確認できます。
サンプル NetworkPolicy YAML の構造
以下は「バックエンド Pod のみが DB に接続可能」とするシンプルなポリシーです。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-db-from-backend namespace: prod spec: podSelector: matchLabels: app: database # DB Pod を対象にする policyTypes: - Ingress # 受信のみ制御 ingress: - from: - podSelector: matchLabels: tier: backend # バックエンド Pod のみ許可 ports: - protocol: TCP port: 5432 # PostgreSQL のデフォルトポート |
この YAML を適用すると、app=database ラベルが付いた Pod は isolated 状態になり、tier=backend 以外からの接続は遮断されます。
通信テスト手順
- テスト用クライアント Pod を起動（busybox）
bash
kubectl run busybox --image=busybox -i --rm --restart=Never -- sh - DB へ接続が成功することを確認（バックエンドから実行）
sh
nc -zv database.prod.svc.cluster.local 5432
# => Connection succeeded - フロントエンド外 の Pod から同じコマンドを実行し、接続が失敗することを確認
bash
kubectl run curlpod --image=curlimages/curl -i --rm --restart=Never -- sh
nc -zv database.prod.svc.cluster.local 5432
# => Connection refused / timed out
テストが期待通りに動作すれば、NetworkPolicy が正しく適用されていることが確認できます。
トラブルシューティングとベストプラクティス
NetworkPolicy を本番環境で運用する際によく遭遇する問題と、その対策をまとめます。
ここでは「原因の切り分け手順」と「実装上のベストプラクティス」を提示します。
Pod が isolated になるタイミング
- ポイント：対象 Pod に最初の
NetworkPolicyが作成された瞬間に、CNI は自動的にその Pod を isolated とみなします。 - 確認方法：
kubectl logs -n kube-system calico-node-xxxxで「policy added」や「policy updated」のログエントリを探すと、適用タイミングが分かります。
ベストプラクティス：ポリシー適用直後は必ず通信テストを実施し、意図した通りにトラフィックが制御されていることを検証してください。
よくある落とし穴と対策
| 落とし穴 | 主な原因 | 推奨対策 |
|---|---|---|
| CNI がポリシーを無視する | NetworkPolicy が有効化されていない、またはプラグインが正しくデプロイされていない |
kubectl get daemonset -n kube-system calico-node で --policy-mode=calico フラグが付与されているか確認 |
| 複数ポリシーの競合 | 同一 Pod に対して許可と拒否が混在し、期待外れの通信が許可される | ポリシーは union になることを意識し、最小限のルールに絞る |
| デフォルト deny が機能しない | policyTypes に Egress が抜けている、または podSelector: {} が誤って記述されている |
Ingress と Egress の両方を明示的に指定し、全 Pod を対象にする {} セレクタを使用 |
デフォルト deny ポリシーの設定例
以下のポリシーは Namespace 全体で すべての通信を遮断 します。以降、許可したいトラフィックだけを個別に定義してください。
|
1 2 3 4 5 6 7 8 9 10 11 |
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-all namespace: prod spec: podSelector: {} # 全 Pod に適用 policyTypes: - Ingress - Egress |
デプロイ後は kubectl get networkpolicy -n prod でポリシーが表示され、calico-node のログに「default deny」メッセージが出ていることを確認します。
まとめと次のステップ
本稿では、Kubernetes の NetworkPolicy の基本概念から EKS クラスタへの有効化手順、主要 CNI プラグインの選定ポイント、実装・検証までのフローを網羅的に解説しました。
- NetworkPolicy の必要性 を認識し、非分離状態が抱えるリスクを把握する
- プラグイン選定（Calico / Cilium / AWS VPC CNI）と IAM/VPC 前提条件 を確実に満たす
- 既存 EKS クラスタでは
eksctl utils update-cluster --enable-network-policyまたはコンソールで有効化し、Calico がデプロイされることを確認 - サンプルポリシーで isolated 動作を検証し、テスト結果を踏まえて本番へ展開
追加リソース（常に最新情報が取得できるリンク）
| 項目 | URL |
|---|---|
| Calico 公式リリース | https://github.com/projectcalico/calico/releases |
| Cilium 公式リリース | https://github.com/cilium/cilium/releases |
| AWS VPC CNI 公式リリース | https://github.com/aws/amazon-vpc-cni-k8s/releases |
| EKS ネットワークポリシーのベストプラクティス | https://docs.aws.amazon.com/eks/latest/userguide/network-policies.html |
これらを定期的にチェックし、セキュリティパッチや機能追加があれば速やかに適用してください。
安全でスケーラブルなマイクロサービス運用の基盤として、NetworkPolicy の活用は不可欠です。ぜひ本ハンズオンを起点に、貴社環境へ導入をご検討ください。