Kubernetes ネットワークポリシーのクラスターを構成する
デフォルトでは、Kubernetes の IP アドレス、ポート、クラスター内の Pods 間の接続、または Pods と他のネットワークのリソースの接続に制限はありません。Kubernetes ネットワークポリシーを使用して、お客様の Pods 間で送受信されるネットワークトラフィックを制限できます。詳細については、「Kubernetes のドキュメント」の「ネットワークポリシー
クラスターの Amazon VPC CNI plugin for Kubernetes のバージョンが 1.13
以前の場合、Kubernetes ネットワークポリシーをクラスターに適用するには、サードパーティーソリューションを実装する必要があります。バージョン 1.14
以降のプラグインでは、ネットワークポリシーを実装できるため、サードパーティソリューションを使用する必要はありません。このトピックでは、サードパーティのアドオンを使用せずにクラスターの Kubernetes ネットワークポリシーを使用するようにクラスターを構成する方法を説明します。
Amazon VPC CNI plugin for Kubernetes のネットワークポリシーは、次の設定でサポートされています。
-
バージョン
1.25
以降の Amazon EKS クラスター。 -
クラスターのバージョン 1.14 以降の Amazon VPC CNI plugin for Kubernetes。
-
IPv4
またはIPv6
アドレス用に設定されたクラスター。 -
Pods 用のセキュリティグループでネットワークポリシーを使用できます。ネットワークポリシーを使用すると、クラスター内の通信をすべて制御できます。Pods 用のセキュリティグループを使用すると、Pod 内のアプリケーションから AWS のサービスへのアクセスを制御できます。
-
カスタムネットワークおよびプレフィクス委任でネットワークポリシーを使用できます。
考慮事項
-
Amazon VPC CNI plugin for Kubernetes を含むクラスターに Amazon VPC CNI plugin for Kubernetes ネットワークポリシーを適用する場合、Amazon EC2 Linux ノードにのみポリシーを適用できます。Fargate または Windows ノードにはポリシーを適用できません。
-
クラスターが現在サードパーティーソリューションを使用して Kubernetes ネットワークポリシーを管理している場合、同じポリシーを Amazon VPC CNI plugin for Kubernetes で使用できます。ただし、同じポリシーを管理しないように、既存のソリューションを削除する必要があります。
-
同じPodに複数のネットワークポリシーを適用できます。同じPodを選択するポリシーが 2 つ以上設定されている場合、すべてのポリシーがPodに適用されます。
-
ネットワークポリシーの各
ingress:
またはegress:
セレクターの各プロトコルにおけるポートの一意の組み合わせの最大数は 24 です。 -
どの Kubernetes サービスでも、サービスポートはコンテナポートと同じでなければなりません。名前付きポートを使用している場合は、サービス仕様でも同じ名前を使用してください。
-
Pod 起動時のポリシーの適用
Amazon VPC CNI plugin for Kubernetes はポッドのプロビジョニングと並行して、ポッドのネットワークポリシーを設定します。新しいポッドにすべてのポリシーが設定されるまで、新しいポッドのコンテナはデフォルトの許可ポリシーで起動します。これは標準モードと呼ばれます。デフォルトの許可ポリシーは、すべての ingress トラフィックと egress トラフィックが新しいポッドとの間で許可されることを意味します。
このデフォルトのネットワークポリシーを変更するには、VPC CNI
aws-node
のstrict
コンテナで環境変数NETWORK_POLICY_ENFORCING_MODE
をDaemonSet
に設定します。env: - name: NETWORK_POLICY_ENFORCING_MODE value: "strict"
変数
NETWORK_POLICY_ENFORCING_MODE
をstrict
に設定すると、VPC CNI を使用するポッドはデフォルトの拒否ポリシーで起動し、その後ポリシーが設定されます。これは Strict モードと呼ばれます。Strict モードでは、ポッドがクラスター内でアクセスする必要があるすべてのエンドポイントにネットワークポリシーが必要です。この要件は、CoreDNS ポッドに適用されることに注意してください。デフォルトの拒否ポリシーは、ホストネットワークを使用するポッドには設定されていません。 -
ネットワークポリシー機能では、
policyendpoints.networking.k8s.aws
と呼ばれるPolicyEndpoint
カスタムリソース定義 (CRD) が作成され、必要になります。カスタムリソースのPolicyEndpoint
オブジェクトは Amazon EKS によって管理されます。これらのリソースを変更または削除しないでください。 -
インスタンスロールの IAM 認証情報を使用するポッドを実行するか、EC2 IMDS に接続するポッドを実行する場合は、EC2 IMDS へのアクセスをブロックするネットワークポリシーがないか慎重に確認してください。EC2 IMDS へのアクセスを許可するネットワークポリシーを追加する必要がある場合があります。詳細については、「Linux インスタンス用 Amazon EC2 ユーザーガイド」の「インスタンスメタデータとユーザーデータ」を参照してください。
サービスアカウントの IAM ロールを使用するポッドが、EC2 IMDS にアクセスすることはありません。
-
Amazon VPC CNI plugin for Kubernetes は、各ポッドの追加のネットワークインターフェイスにはネットワークポリシーを適用せず、各ポッドのプライマリインターフェイス (
eth0
) のみにネットワークポリシーを適用します。これは以下のアーキテクチャに影響します。-
ENABLE_V4_EGRESS
変数がtrue
に設定されたIPv6
ポッド。この変数により、IPv4
エグレス機能が IPv6 ポッドをクラスター外のエンドポイントなどのIPv4
エンドポイントに接続できるようになります。IPv4
エグレス機能は、ローカルループバック IPv4 アドレスを持つ追加のネットワークインターフェースを作成することで機能します。 -
Multus などのチェーンネットワークプラグインを使用する場合。これらのプラグインは各ポッドにネットワークインターフェースを追加するため、ネットワークポリシーはチェーンネットワークプラグインには適用されません。
-
-
ネットワークポリシー機能は、デフォルトでノード上のポート
8162
をメトリクスに使用します。また、この機能はヘルスプローブにポート8163
を使用していました。そのノード上、またはこれらのポートを使用する必要があるポッド内で他のアプリケーションを実行すると、そのアプリは実行できません。VPC CNI バージョンv1.14.1
以降では、これらのポートを次の場所で変更できます。
前提条件
-
最小クラスターバージョン
既存の Amazon EKS クラスター。デプロイするには、「Amazon EKS の使用開始」を参照してください。クラスターは Kubernetes バージョン
1.25
以降である必要があります。クラスターは、次の表に示す Kubernetes バージョンとプラットフォームバージョンのいずれかを実行している必要があります。一覧にあるバージョンより後の Kubernetes とプラットフォームのバージョンもサポートされることにご注意ください。現在の Kubernetes バージョンを確認するには、次のコマンドのmy-cluster
をクラスターの名前に置き換えて、変更したコマンドを実行します。aws eks describe-cluster --name
my-cluster
--query cluster.version --output textKubernetes バージョン
プラットフォームバージョン
1.27.4
eks.5
1.26.7
eks.6
1.25.12
eks.7
-
最小 VPC CNI バージョン
クラスターのバージョン
1.14
以降の Amazon VPC CNI plugin for Kubernetes。現在のバージョンは、次のコマンドで確認できます。kubectl describe daemonset aws-node --namespace kube-system | grep amazon-k8s-cni: | cut -d : -f 3
バージョンが
1.14
より前の場合は、Amazon EKS アドオンの更新 を確認してバージョン1.14
以降にアップグレードしてください。 -
最小 Linux カーネルバージョン
ノードにはバージョン
5.10
以降の Linux カーネルが必要です。カーネルのバージョンは、uname -r
で確認できます。Amazon EKS の最適化された Amazon Linux AMI と Bottlerocket AMI の最新バージョンを使用している場合、既に必要なカーネルバージョンがインストールされています。Amazon EKS 最適化高速 Amazon Linux AMI
v20231116
バージョン以降には、カーネルバージョン5.10
があります。
Kubernetes ネットワークポリシーを使用するようにクラスターを設定する
-
BPF ファイルシステムのマウント
注記
クラスターがバージョン
1.27
以降の場合、Amazon EKS 最適化された1.27
以降の Amazon Linux AMI と Bottlerocket AMI にはすべてこの機能が既に実装されているため、このステップをスキップできます。その他のすべてのクラスターバージョンでは、Amazon EKS 最適化された Amazon Linux をバージョン
v20230703
以降にアップグレードした場合、または Bottlerocket AMI をバージョンv1.0.2
にアップグレードした場合に。このステップをスキップできます。-
バークレーパケットフィルタ (BPF) ファイルシステムを各ノードにマウントします。
sudo mount -t bpf bpffs /sys/fs/bpf
-
次に、Amazon EC2 Auto Scaling グループの起動テンプレートのユーザーデータに同じコマンドを追加します。
-
-
VPC CNI でネットワークポリシーを有効にします。
-
クラスターにインストールされているアドオンのタイプを確認します。クラスターを作成するために使用したツールによっては、現在クラスターに Amazon EKS アドオンタイプがインストールされていない場合があります。
my-cluster
の部分は、自分のクラスター名に置き換えます。aws eks describe-addon --cluster-name
my-cluster
--addon-name vpc-cni --query addon.addonVersion --output textバージョン番号が返された場合、Amazon EKS タイプのアドオンがクラスターにインストールされているため、このステップの残りのステップを完了する必要はありません。エラーが返された場合、クラスターに Amazon EKS タイプのアドオンがインストールされていません。
-
-
Amazon EKS アドオン
-
セルフマネージド型アドオン
-
-
-
aws-node
ポッドがクラスター上で実行されていることを確認してください。kubectl get pods -n kube-system | grep 'aws-node\|amazon'
出力例は次のとおりです。
aws-node-
gmqp7
2/2 Running 1 (24h ago) 24h aws-node-prnsh
2/2 Running 1 (24h ago) 24hネットワークポリシーが有効になっている場合、
aws-node
ポッドには 2 つのコンテナがあります。以前のバージョンでは、ネットワークポリシーが無効になっている場合、aws-node
ポッドにコンテナは 1 つしか存在しません。これで、Kubernetes ネットワークポリシーをクラスターにデプロイできます。詳細については、「Kubernetes ネットワークポリシー」を参照してください。
ネットワークポリシーの Stars デモ
このデモでは、Amazon EKS クラスターにフロントエンド、バックエンド、およびクライアントサービスを作成します。また、このデモでは、各サービス間で利用可能な入力および出力のパスを示す管理グラフィカルユーザーインターフェースが作成されます。実稼働ワークロードを実行しないクラスターでデモを完了することをお勧めします。
ネットワークポリシーを作成する前に、サービスはすべて、双方向に通信できます。ネットワークポリシーを適用すると、クライアントはフロントエンドサービスとのみ通信でき、バックエンドはフロントエンドからのみトラフィックを受け付けます。
Stars Policy デモを実行するには
-
フロントエンド、バックエンド、クライアント、および管理ユーザーインターフェイスサービスを適用します。
kubectl apply -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/namespace.yaml kubectl apply -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/management-ui.yaml kubectl apply -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/backend.yaml kubectl apply -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/frontend.yaml kubectl apply -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/client.yaml
-
クラスター上のすべての Pods を表示します。
kubectl get pods -A
出力例は次のとおりです。
出力では、次の出力に示す名前空間にポッドが表示されます。
READY
列内のポッドのNAMES
とポッド数は、次の出力とは異なります。似たような名前のポッドが見えて、それらがすべてSTATUS
列内にRunning
を持つまで続けないでください。NAMESPACE NAME READY STATUS RESTARTS AGE [...] client client-
xlffc
1/1
Running 05m19s
[...] management-ui management-ui-qrb2g
1/1
Running 05m24s
stars backend-sz87q
1/1
Running 05m23s
stars frontend-cscnf
1/1
Running 05m21s
[...] -
管理ユーザーインターフェイスに接続するには、クラスターで実行されているサービスの
EXTERNAL-IP
に接続します。kubectl get service/management-ui -n management-ui
-
ブラウザーを開いて、前のステップの場所に移動します。管理ユーザーインターフェイスが表示されます。[C] ノードはクライアントサービス、[F] ノードはフロントエンドサービス、[B] ノードはバックエンドサービスを表します。各ノードには、太字の色付きの行で示されるように、他のすべてのノードへの完全な通信アクセスが含まれます。
-
相互にサービスを分離するには、次のネットワークポリシーを
stars
およびclient
の名前空間の両方に適用します。kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: default-deny spec: podSelector: matchLabels: {}
次のコマンドを使用して、ポリシーを両方の名前空間に適用できます。
kubectl apply -n stars -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/default-deny.yaml kubectl apply -n client -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/default-deny.yaml
-
ブラウザを更新します。管理ユーザーインターフェイスはノードに到達できなくなるため、ユーザーインターフェイスに表示されないことがわかります。
-
管理ユーザーインターフェイスがサービスにアクセスできるように、次の別のネットワークポリシーを適用します。このポリシーを適用して UI を許可します。
kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: namespace: stars name: allow-ui spec: podSelector: matchLabels: {} ingress: - from: - namespaceSelector: matchLabels: role: management-ui
このポリシーを適用してクライアントを許可します。
kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: namespace: client name: allow-ui spec: podSelector: matchLabels: {} ingress: - from: - namespaceSelector: matchLabels: role: management-ui
次のコマンドを使用して両方のポリシーを適用できます。
kubectl apply -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/allow-ui.yaml kubectl apply -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/allow-ui-client.yaml
-
ブラウザを更新します。管理ユーザーインターフェイスは再びノードにアクセスできますが、ノードは相互に通信できないことがわかります。
-
フロントエンドサービスからバックエンドサービスへのトラフィックを許可するには、次のネットワークポリシーを適用します。
kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: namespace: stars name: backend-policy spec: podSelector: matchLabels: role: backend ingress: - from: - podSelector: matchLabels: role: frontend ports: - protocol: TCP port: 6379
-
ブラウザを更新します。フロントエンドがバックエンドと通信できることがわかります。
-
クライアントからフロントエンドサービスへのトラフィックを許可するには、次のネットワークポリシーを適用します。
kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: namespace: stars name: frontend-policy spec: podSelector: matchLabels: role: frontend ingress: - from: - namespaceSelector: matchLabels: role: client ports: - protocol: TCP port: 80
-
ブラウザを更新します。クライアントがフロントエンドサービスと通信できることがわかります。フロントエンドサービスは、バックエンドサービスと引き続き通信できます。
-
(オプション) デモが完了したら、そのリソースを削除することができます。
kubectl delete -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/client.yaml kubectl delete -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/frontend.yaml kubectl delete -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/backend.yaml kubectl delete -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/management-ui.yaml kubectl delete -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/namespace.yaml
リソースを削除した後でも、ノード上にネットワークポリシーエンドポイントが残っている場合があり、それがクラスター内のネットワークを予期しない方法で妨げることがあります。これらのルールを削除する唯一の確実な方法は、ノードを再起動するか、すべてのノードを終了して、リサイクルすることです。すべてのノードを終了するには、Auto Scaling グループの必要数を 0 に設定してから目的数にバックアップするか、単にノードを終了します。
ネットワークポリシーのトラブルシューティング
ネットワークポリシーのログ を読み、eBPF SDK のツールを実行することにより、ネットワークポリシーを使用するネットワーク接続をトラブルシューティングおよび調査できます。
ネットワークポリシーのログ
ネットワークポリシーによって接続が許可されているか拒否されているかは、フローログに記録されています。各ノードのネットワークポリシーログには、ネットワークポリシーが設定されているすべてのポッドのフローログが含まれます。ネットワークポリシーログは /var/log/aws-routed-eni/network-policy-agent.log
に保存されます。次の例は network-policy-agent.log
ファイルからのものです。
{"level":"info","timestamp":"2023-05-30T16:05:32.573Z","logger":"ebpf-client","msg":"Flow Info: ","Src
IP":"192.168.87.155","Src Port":38971,"Dest IP":"64.6.160","Dest
Port":53,"Proto":"UDP","Verdict":"ACCEPT"}
ネットワークポリシーログはデフォルトで無効になっています。ネットワークポリシーログを有効にするには、次の手順に従います。
注記
ネットワークポリシーログには、VPC CNI aws-node
デーモンセットマニフェストの aws-network-policy-agent
コンテナ用に 1 つの vCPU を追加する必要があります。
Amazon EKS アドオン
セルフマネージド型アドオン
ネットワークポリシーログを Amazon CloudWatch Logs に送信する
Amazon CloudWatch Logs などのサービスを使用して、ネットワークポリシーログをモニタリングできます。次の方法を使用して、ネットワークポリシーログを CloudWatch Logs に送信できます。
EKS クラスターの場合、ポリシーログは /aws/eks/
に配置され、セルフマネージド型 K8S クラスターの場合、ログは cluster-name
/cluster//aws/k8s-cluster/cluster
/ に配置されます。
ネットワークポリシーログを Amazon VPC CNI plugin for Kubernetes で送信する
ネットワークポリシーを有効にすると、2 つ目のコンテナがノードエージェントの aws-node
ポッドに追加されます。このノードエージェントは、ネットワークポリシーログを CloudWatch Logs に送信できます。
注記
ノードエージェントはネットワークポリシーログのみを送信します。VPC CNI によって作成された他のログは含まれません。
前提条件
-
VPC CNI に使用している IAM ロールに、次の権限をスタンザまたは個別のポリシーとして追加します。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "logs:DescribeLogGroups", "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": "*" } ] }
Amazon EKS アドオン
セルフマネージド型アドオン
ネットワークポリシーログを Fluent Bit デーモンセットで送信する
ノードからログを送信するためにデーモンセットの Fluent Bit を使用している場合、ネットワークポリシーのネットワークポリシーログを含めるように設定を追加できます。次の設定例を使用できます。
[INPUT] Name tail Tag eksnp.* Path /var/log/aws-routed-eni/network-policy-agent*.log Parser json DB /var/log/aws-routed-eni/flb_npagent.db Mem_Buf_Limit 5MB Skip_Long_Lines On Refresh_Interval 10
eBPF SDK を含む
Amazon VPC CNI plugin for Kubernetes は、ノードに eBPF SDK ツールのコレクションをインストールします。eBPF SDK ツールを使用して、ネットワークポリシーの問題を特定できます。例えば、次のコマンドはノードで実行されているプログラムを一覧表示します。
sudo /opt/cni/bin/aws-eks-na-cli ebpf progs
このコマンドを実行するために、任意の方法を使用してノードに接続できます。
Kubernetes ネットワークポリシー
Kubernetes ネットワークポリシーを実装するには、Kubernetes NetworkPolicy
オブジェクトを作成して、クラスターにデプロイします。NetworkPolicy
オブジェクトは名前空間に限定されます。ラベルセレクター、名前空間、および IP アドレス範囲に基づいて、Pods 間のトラフィックを許可または拒否するポリシーを実装します。NetworkPolicy
オブジェクトの作成の詳細については、Kubernetes ドキュメントの「ネットワークポリシー」
Kubernetes NetworkPolicy
オブジェクトの実施は、Extended Berkeley Packet Filter (eBPF) を使用して実装されます。iptables
をベースにした実装に関連して、CPU 使用率の低下やシーケンシャルルックアップの回避など、低レイテンシーを実現し、パフォーマンス特性を発揮します。さらに、eBPF プローブは、複雑なカーネルレベルの問題のデバッグやオブザーバビリティの向上に役立つ、コンテキスト豊富なデータへのアクセスを提供します。Amazon EKS は、プローブを利用して各ノードのポリシー結果をログに記録し、そのデータを外部のログコレクターにエクスポートしてデバッグに役立てる eBPF ベースのエクスポーターをサポートしています。詳細については、eBPF ドキュメント