**このページの改善にご協力ください** このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。 # Kubernetes ネットワークポリシーにより Pod トラフィックを制限する ## 概要 デフォルトでは、Kubernetes の IP アドレス、ポート、クラスター内の Pod 間の接続、またはポッドと他のネットワークのリソースの接続に制限はありません。Kubernetes *ネットワークポリシー*を使用して、自分の Pod 間で送受信されるネットワークトラフィックを制限できます。詳細については、Kubernetes ドキュメントの「[ネットワークポリシー](https://kubernetes.io/docs/concepts/services-networking/network-policies/)」を参照してください。 ## 標準のネットワークポリシー 標準の `NetworkPolicy` を使用すると、クラスター内のポッド間トラフィックをセグメント化できます。OSI ネットワークモデルのレイヤー 3 と 4 で動作するネットワークポリシーであり、Amazon EKS クラスター内の IP アドレスまたはポートレベルでトラフィックフローを制御できます。標準のネットワークポリシーは、範囲が名前空間レベルに限定されます。 ### ユースケース + ワークロード間でネットワークトラフィックをセグメント化すると、関連するアプリケーションのみが相互に通信できるようになります。 + ポリシーを使用して名前空間レベルでテナントを分離すると、ネットワークを分離できます。 ### 例 以下のポリシーでは、*sun* 名前空間の *webapp* ポッドからのエグレストラフィックが制限されています。 ``` apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: webapp-egress-policy namespace: sun spec: podSelector: matchLabels: role: webapp policyTypes: - Egress egress: - to: - namespaceSelector: matchLabels: name: moon podSelector: matchLabels: role: frontend ports: - protocol: TCP port: 8080 - to: - namespaceSelector: matchLabels: name: stars podSelector: matchLabels: role: frontend ports: - protocol: TCP port: 8080 ``` ポリシーは、`sun` 名前空間で `role: webapp` というラベルが付いたポッドに適用されます。 + 許可されるトラフィック: TCP ポート `8080` の `moon` 名前空間で `role: frontend` というラベルが付いたポッド。 + 許可されるトラフィック: TCP ポート `8080` の `stars` 名前空間で role: frontend というラベルが付いたポッド。 + ブロックされるトラフィック: `webapp` ポッドからの他のすべてのアウトバウンドトラフィックは暗黙的に拒否されます。 ## 管理者 (あるいはクラスター) ネットワークポリシー ![EKS でネットワークポリシーが評価される順序を示した図](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/evaluation-order.png) `ClusterNetworkPolicy` を使用すると、ネットワークセキュリティ標準をクラスター全体に適用できます。名前空間ごとにポリシーを繰り返し定義して維持するのではなく、単一のポリシーを使用して、名前空間に関係なく、クラスター内のさまざまなワークロードに対するネットワークアクセスコントロールを一元管理できます。 ### ユースケース + EKS クラスター内のすべての (または一部の) ワークロードに対するネットワークアクセスコントロールを一元管理します。 + クラスター全体にわたるデフォルトのネットワークセキュリティ体制を定義します。 + 組織のセキュリティ標準を運用効率の高い方法でクラスターの範囲へと拡張します。 ### 例 以下のポリシーでは、他の名前空間からのクラスタートラフィックを明示的にブロックして、機密性の高いワークロード名前空間へのネットワークアクセスを防ぐことができます。 ``` apiVersion: networking.k8s.aws/v1alpha1 kind: ClusterNetworkPolicy metadata: name: protect-sensitive-workload spec: tier: Admin priority: 10 subject: namespaces: matchLabels: kubernetes.io/metadata.name: earth ingress: - action: Deny from: - namespaces: matchLabels: {} # Match all namespaces. name: select-all-deny-all ``` ## 重要な注意事項 Amazon VPC CNI plugin for Kubernetes のネットワークポリシーは、以下に示した構成でサポートされています。 + 標準と管理者のどちらのネットワークポリシーでも、Amazon VPC CNI プラグインのバージョンが 1.21.0 (またはそれ以降) です。 + `IPv4` または `IPv6` アドレス用に設定されたクラスター。 + [ポッド用のセキュリティグループ](security-groups-for-pods.md)でネットワークポリシーを使用できます。ネットワークポリシーを使用すると、クラスター内の通信をすべて制御できます。Pod 用のセキュリティグループを使用すると、Pod 内のアプリケーションから AWS サービスへのアクセスを制御できます。 + *カスタムネットワーク*および*プレフィックス委任*でネットワークポリシーを使用できます。 ## 考慮事項 **アーキテクチャ** () + Amazon VPC CNI plugin for Kubernetes を含むクラスターに Amazon VPC CNI plugin for Kubernetes ネットワークポリシーを適用する場合、Amazon EC2 Linux ノードにのみポリシーを適用できます。Fargate または Windows ノードにはポリシーを適用できません。 + ネットワークポリシーは`IPv4` または `IPv6` アドレスのいずれかのみを適用しますが、両方は適用しません。`IPv4` クラスターではVPC CNI は `IPv4` アドレスをポッドに割り当て、`IPv4` ポリシーを適用します。`IPv6` クラスターではVPC CNI は `IPv6` アドレスをポッドに割り当て、`IPv6` ポリシーを適用します。`IPv6` クラスターに適用された `IPv4` ネットワークポリシールールは無視されます。`IPv4` クラスターに適用された `IPv6` ネットワークポリシールールは無視されます。 **ネットワークポリシー** + ネットワークポリシーはデプロイの一部である Pod にのみ適用されます。`metadata.ownerReferences` セットを持たないスタンドアロンの Pod ではネットワークポリシーを適用できません。 + 同じ Pod に複数のネットワークポリシーを適用できます。同じ Pod を選択するポリシーが 2 つ以上設定されている場合、すべてのポリシーが Pod に適用されます。 + ある IP アドレス範囲 (CIDR) に許可されるポートとプロトコルの組み合わせの最大数は、ネットワークポリシー全体で 24 です。`namespaceSelector` などのセレクターは、1 つ以上の CIDR に解決されます。複数のセレクターが 1 つの CIDR に解決される場合や、同一または異なるネットワークポリシーに同じ直接 CIDR を複数回指定した場合に、この制限が考慮されます。 + どの Kubernetes サービスでも、サービスポートはコンテナポートと同じでなければなりません。名前付きポートを使用している場合はサービス仕様でも同じ名前を使用してください。 **管理者ネットワークポリシー** 1. **管理者層ポリシー (最初に評価)**: 管理者階層のすべての ClusterNetworkPolicy が他のポリシーよりも先に評価されます。管理者階層内では、優先順位に従って (優先順位番号の最も小さいものから) ポリシーが処理されます。次にどうなるかは、アクションタイプによって決まります。 + **拒否アクション (最も高い優先順位)**: 拒否アクションを定義した管理者ポリシーがトラフィックと一致すると、そのトラフィックは他のポリシーとは関係なくすぐにブロックされます。ClusterNetworkPolicy や NetworkPolicy ルールはそれ以上処理されません。これにより、組織全体のセキュリティコントロールを名前空間レベルのポリシーで上書きできないようにしています。 + **許可アクション**: 拒否ルールが評価されると、許可アクションを定義した管理者ポリシーが優先順位に従って (優先順位番号の最も小さいものから) 処理されます。許可アクションに一致すると、トラフィックは受け入れられ、ポリシーはそれ以上評価されません。これらのポリシーは、ラベルセレクターに基づいて複数の名前空間に対するアクセスを許可して、特定のリソースにどのワークロードがアクセスできるかを一元的に制御できます。 + **パスアクション**: 管理階層ポリシーにパスアクションを定義すると、意思決定が下位の階層に委任されます。トラフィックがパスルールに一致すると、そのトラフィックの残りの管理者階層ルールの評価がスキップされ、NetworkPolicy 階層に直接進みます。これにより、管理者は特定のトラフィックパターンに対する制御をアプリケーションチームに明示的に委任できます。例えば、パスルールを使用すると、外部アクセスを厳密に制御しつつ、名前空間内のトラフィック管理を名前空間管理者に委任できます。 1. **ネットワークポリシー階層**: 拒否または許可に一致する管理者階層ポリシーがない場合や、パスアクションが一致した場合、次は名前空間範囲の NetworkPolicy リソースが評価されます。これらは個々の名前空間内できめ細かく制御できるポリシーで、アプリケーションチームによって管理されます。名前空間範囲のポリシーでは、管理者ポリシーよりも厳しく制限を課すことができます。管理者ポリシーによる拒否の判断を上書きすることはできませんが、管理者ポリシーによって許可またはパスされたトラフィックをさらに制限できます。 1. **ベースライン階層管理ポリシー**: トラフィックに一致する管理者ポリシーや名前空間範囲のポリシーがない場合、ベースライン階層の ClusterNetworkPolicy が評価されます。これにより、デフォルトのセキュリティ体制を名前空間範囲のポリシーで上書きできるため、管理者が組織全体のデフォルトを設定する一方で、チームが必要に応じて柔軟にカスタマイズできます。ベースラインポリシーは、優先順位に従って (優先順位番号の最も小さいものから) 評価されます。 1. **デフォルト拒否 (一致するポリシーがない場合)**: この deny-by-default 動作により、明示的に認められた接続のみが許可されるため、強力なセキュリティ体制を維持できます。 **移行** + クラスターが現在サードパーティーソリューションを使用して Kubernetes ネットワークポリシーを管理している場合、同じポリシーを Amazon VPC CNI plugin for Kubernetes で使用できます。ただし、同じポリシーを管理しないように、既存のソリューションを削除する必要があります。 **警告** ネットワークポリシーソリューションを削除したら、そのソリューションが適用されていたすべてのノードを置き換えることをお勧めします。ソリューションのポッドが突然終了した場合に、トラフィックルールが残ってしまう可能性があるためです。 **インストール**。 + ネットワークポリシー機能では`policyendpoints.networking.k8s.aws` と呼ばれる `PolicyEndpoint` カスタムリソース定義  (CRD が作成され、必要になります。カスタムリソースの `PolicyEndpoint` オブジェクトは Amazon EKS によって管理されます。これらのリソースを変更または削除しないでください。 + インスタンスロールの IAM 認証情報を使用するポッドを実行するか、EC2 IMDS に接続するポッドを実行する場合はEC2 IMDS へのアクセスをブロックするネットワークポリシーがないか慎重に確認してください。EC2 IMDS へのアクセスを許可するネットワークポリシーを追加する必要がある場合があります。詳細については「Amazon EC2 ユーザーガイド」の「[インスタンスメタデータとユーザーデータ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html)」を参照してください。 *サービスアカウントの IAM ロール*または *EKS Pod Identity* を使用するポッドはEC2 IMDS にアクセスしません。 + Amazon VPC CNI plugin for Kubernetes は、各ポッドの追加のネットワークインターフェイスにはネットワークポリシーを適用せず、各ポッドのプライマリインターフェイス (`eth0`) のみにネットワークポリシーを適用します。これは以下のアーキテクチャに影響します： + `ENABLE_V4_EGRESS` 変数が `true` に設定された `IPv6` ポッド。この変数により、`IPv4` エグレス機能が IPv6 ポッドをクラスター外のエンドポイントなどの `IPv4` エンドポイントに接続できるようになります。`IPv4` エグレス機能は、ローカルループバック IPv4 アドレスを持つ追加のネットワークインターフェースを作成することで機能します。 + Multus などのチェーンネットワークプラグインを使用する場合。これらのプラグインは各ポッドにネットワークインターフェースを追加するため、ネットワークポリシーはチェーンネットワークプラグインには適用されません。