EKSでCalicoとVPC CNIを使ったKubernetes NetworkPolicy設定手順

はじめに – 本記事の目的と対象読者

Kubernetes の NetworkPolicy を用いれば、Pod 同士や外部サービスへの通信を細かく制御できますが、対応した CNI プラグインが正しく導入されていなければポリシーは無効化されたままです。本ハンズオンでは、2026 年時点で AWS EKS が公式に推奨する Amazon VPC CNI（CNI アドオン） と Calico の両方をセットアップし、実際に NetworkPolicy を作成・適用・検証する手順を体験します。対象は本番環境で EKS を運用中の DevOps エンジニア・SRE です。

本記事を最後まで読めば、最小構成だけでなく外部 egress の制御やベストプラクティス も含めた実践的なネットワークセキュリティ設計ができるようになります。

前提条件と環境設定

このセクションでは、ハンズオンを安全に開始するために最低限必要な EKS バージョン・IAM 権限・CLI ツール を整理します。前もって準備しておくことで、途中で手戻りが発生しないようにします。

対象となる EKS クラスタのバージョン要件

2026 年 3 月時点の公式ドキュメントによれば、Amazon VPC CNI ポリシー と Calico v3.27 以降 は EKS v1.28 以上 のクラスターで安定動作が保証されています。バージョンが古い場合は、まず eksctl upgrade cluster で最新のマイナーバージョンへ更新してください。

必要な IAM 権限と CLI ツール

テストクラスター作成例

CNI プラグインの導入

NetworkPolicy が機能するためには、CNI プラグイン側が ポリシーコントローラー を提供している必要があります。本節では Calico と Amazon VPC CNI + Amazon VPC CNI ポリシー の 2 種類を導入し、それぞれのバージョン要件と設定ポイントを解説します。

Calico のインストールと基本設定

Calico はオープンソースのネットワークプラグインで、デフォルトで NetworkPolicy をサポートします。以下は公式マニフェスト（2026‑02 更新版）を利用した手順です。

1. 最新マニフェスト取得
   bash
curl -L -o calico.yaml https://raw.githubusercontent.com/projectcalico/calico/v3.27/manifests/calico.yaml
2. ConfigMap のカスタマイズ（インラインで networkPolicy を有効化）
   yaml
# 省略せずに貼り付ける例
apiVersion: v1
kind: ConfigMap
metadata:
name: calico-config
namespace: kube-system
data:
typha_service_name: "calico-typha"
cni_network_config: |
{
"name": "k8s-pod-network",
"cniVersion": "0.3.1",
"type": "calico",
"log_level": "info",
"datastore_type": "kubernetes",
"nodename": "__KUBERNETES_NODE_NAME__",
"ipam": {
"type": "host-local"
},
"policy": {
"type": "k8s"
}
}
3. マニフェスト適用
   bash
kubectl apply -f calico.yaml

ポイント：Calico が提供する calicoctl コマンドで IPIP トンネルや BGP の有無を確認できます。EKS の VPC CNI と併用したい場合は、IPIP を無効化し BGP 設定だけ残すのが一般的です。

Amazon VPC CNI + Amazon VPC CNI ポリシー（CNI アドオン）の有効化

AWS が提供する公式手順は変遷があります。2026 年 2 月時点で ENABLE_POD_ENI フラグは非推奨とされ、代わりに環境変数 AWS_VPC_K8S_CNI_ENABLE_POD_ENI=true を使用します。最新情報は必ず公式リファレンス（EKS CNI Add-on Docs）で確認してください。

1. CNI アドオン本体のインストール（v1.15 以降が必要）
   bash
eksctl utils install-aws-vpc-cni \
--cluster np-demo \
--region ap-northeast-1 \
--approve
2. Pod ENI 機能の有効化（非推奨フラグは使用しない）
   bash
kubectl set env daemonset/aws-node -n kube-system AWS_VPC_K8S_CNI_ENABLE_POD_ENI=true
3. NetworkPolicy 用 webhook のデプロイ（ポリシーコントローラー）
   bash
eksctl utils install-aws-vpc-cni-policy \
--cluster np-demo \
--region ap-northeast-1

バージョン要件：aws-node コンテナは v1.15.0 以上、amazon-vpc-cni-policy は v0.3.0 以上が必要です。kubectl get daemonset aws-node -n kube-system -o jsonpath='{.spec.template.spec.containers[0].image}' で実際のイメージタグを確認し、公式リリースノートと照らし合わせましょう。

最小構成の NetworkPolicy 作成・適用

このセクションでは デフォルト deny を前提に、特定ラベルを持つフロントエンド Pod だけがバックエンド Pod の HTTP（ポート 80）へアクセスできる最小構成を作ります。まずは YAML サンプルを確認し、その後デプロイ手順と検証方法を示します。

NetworkPolicy YAML のサンプル

以下のマニフェストは app=backend ラベルが付与された Pod を対象に、role=frontend ラベルを持つ Pod からの TCP/80 のみ許可し、それ以外の ingress とすべての egress（ただし CIDR 制限で例示）をブロックします。

ポイント：policyTypes に Ingress と Egress の両方を明示することで、意図しない egress がデフォルトで許可されることを防ぎます。実運用では外部サービス（例: S3）だけに絞った CIDR を指定してください。

デプロイ手順と確認コマンド

1. ファイル保存
   bash
cat > allow-frontend-to-backend.yaml <<'EOF'
（上記 YAML を貼り付け）
EOF
2. 適用
   bash
kubectl apply -f allow-frontend-to-backend.yaml
3. 作成結果の検証
   bash
# ネームスペースと名前を指定して詳細表示
kubectl get networkpolicy allow-frontend-to-backend -n default -o yaml

# ポリシーが対象 Pod に正しくマッチしているか確認
kubectl describe networkpolicy allow-frontend-to-backend -n default


典型的なユースケースとベストプラクティス

最小構成だけでなく、実務でよく求められる 外部サービスへの egress 制御 や 名前空間単位の分離 を例示します。これにより、ポリシー設計の全体像が把握できるようになります。

ユースケース 1：外部 S3 バケットへの限定的 egress

ベストプラクティス：外部への egress は「最小 CIDR」かつ「HTTPS のみ」に絞り、不要なポートはすべて遮断します。定期的に AWS IP 範囲リスト（https://ip-ranges.amazonaws.com/ip-ranges.json）を取得し、CI パイプラインで自動更新することが推奨されます。

ユースケース 2：名前空間ごとの完全分離

ポイント：podSelector: {} は「すべての Pod」を意味します。上記ポリシーは dev 名前空間以外からのアクセスを完全に遮断し、同一名前空間内部でのみ通信可能にします。

ベストプラクティス集

テスト手順と結果検証

実際に作成した NetworkPolicy が期待通りに機能しているか確認します。ここでは ラベルがポリシーと一致する Pod と 不一致の Pod を用意し、curl と nc（netcat）で通信成功/失敗を判定します。

テスト用 Pod のデプロイ（ラベル整合性に注意）

重要：frontend-pod のラベル role=frontend がポリシーの from.podSelector.matchLabels.role=frontend と完全に一致している必要があります。以前の記事で role: front と記載した場合は動作しません。

通信テストコマンド

期待結果の表形式まとめ

トラブルシューティングとベストプラクティス

NetworkPolicy が期待通りに動作しないケースは多く、原因の切り分けが重要です。ここでは代表的な問題シナリオと具体的なデバッグ手順を示します。

CNI が NetworkPolicy をサポートしていない場合

1. CNI バージョン確認
   bash
kubectl get daemonset -n kube-system aws-node -o jsonpath='{.spec.template.spec.containers[0].image}'
# 例: amazon/k8s-cni:v1.15.2
2. 公式対応表のチェック（AWS Docs → “CNI version compatibility”)
3. 未対応の場合は、以下いずれかを実施：
   ・Calico へ切り替える
   ・aws-node のイメージを最新 (v1.16 以上) にアップグレード

ポリシーがマッチしない典型的な原因

ログ取得例

ヒント：NetworkPolicy webhook not ready と表示されたら、DaemonSet のロールアウトが完了していない可能性があります。kubectl rollout status daemonset/aws-node -n kube-system で進捗を確認してください。

ベストプラクティス再掲

• 最小権限の IAM：上記 JSON ポリシーをベースに、使用するリソースだけ許可範囲を絞る。
• バージョンロック：eksctl utils install-aws-vpc-cni の際は --version フラグで明示的にイメージタグを指定し、予期せぬ自動アップデートを防止する。
• CI でのポリシー検証：conftest と OPA ポリシーで「必ず policyTypes に Egress が含まれる」等の社内ルールをコード化し、プルリクエスト時に自動チェック。
• 監査と可視化：Amazon VPC Flow Logs + CloudWatch Logs Insights で “DENIED” イベントを検索し、ポリシー違反が頻出する領域を特定して改善策を検討。

まとめと次のステップ

この記事では以下のことを実践できました。

1. EKS クラスタに Calico と Amazon VPC CNI + ポリシーアドオン を導入し、NetworkPolicy が有効になる基盤を構築。
2. 最小構成の NetworkPolicy（デフォルト deny＋特定ラベル許可）を作成・適用し、kubectl exec と curl/netcat で通信テストを実施。
3. 外部 egress 制御や名前空間分離 といった典型的ユースケースと、IAM 最小権限・CNI バージョン要件 を明示したベストプラクティスを提示。
4. トラブルシューティング手順（ログ取得、バージョン確認、ラベル整合性）と CI/CD でのポリシー検証 の流れを整理。

次に挑戦すべきこと

これらを順次導入すれば、Kubernetes クラスターのネットワークレイヤーは 最小権限・可観測性・自動テスト が整った堅牢な状態になります。ぜひ本ハンズオンで得た知見を実際のプロダクション環境に展開し、継続的な改善サイクルへとつなげてください。