第3章 ネットワークポリシー
3.1. ネットワークポリシーについて リンクのコピーリンクがクリップボードにコピーされました!
ワークロード間のトラフィックを制限し、アプリケーションのセキュリティーを向上させるには、クラスターの NetworkPolicy オブジェクトを設定します。ネットワークポリシーは、選択された Pod に対して許可される Ingress および Egress の接続を定義し、namespace 内のアプリケーションを分離するために役立ちます。
開発者は、クラスター内の Pod へのトラフィックを制限するネットワークポリシーを定義できます。
3.1.1. ネットワークポリシーについて リンクのコピーリンクがクリップボードにコピーされました!
ワークロード間のトラフィックを制御し、ネットワークの分離を強化するには、プロジェクトの NetworkPolicy オブジェクトを設定します。ネットワークポリシーは、選択された Pod に対して許可される Ingress および Egress の接続を定義し、クラスター内のアプリケーションを保護するために役立ちます。
デフォルトで、プロジェクトのすべての Pod は他の Pod およびネットワークのエンドポイントからアクセスできます。プロジェクトで 1 つ以上の Pod を分離するには、そのプロジェクトで NetworkPolicy オブジェクトを作成し、許可する着信接続を指定します。プロジェクト管理者は独自のプロジェクト内で NetworkPolicy オブジェクトの作成および削除を実行できます。
Pod が 1 つ以上の NetworkPolicy オブジェクトのセレクターで一致する場合、Pod はそれらの 1 つ以上の NetworkPolicy オブジェクトで許可される接続のみを受け入れます。NetworkPolicy オブジェクトによって選択されていない Pod は完全にアクセス可能です。
ネットワークポリシーは、Transmission Control Protocol (TCP)、User Datagram Protocol (UDP)、Internet Control Message Protocol (ICMP)、および Stream Control Transmission Protocol (SCTP) プロトコルにのみ適用されます。他のプロトコルは影響を受けません。
- ネットワークポリシーは、ホストのネットワーク namespace には適用されません。ホストネットワークが有効にされている Pod はネットワークポリシールールによる影響を受けません。ただし、ホストネットワークを使用する Pod に接続する Pod は、ネットワークポリシールールの影響を受ける可能性があります。
-
podSelectorフィールドを{}に設定せずにnamespaceSelectorフィールドを使用すると、hostNetworkPod が含まれません。ネットワークポリシーの作成時にhostNetworkPod をターゲットにするには、namespaceSelectorフィールドでpodSelectorを{}に設定して使用する必要があります。 - ネットワークポリシーは、ローカルホストまたは常駐ノードからのトラフィックをブロックすることはできません。
ネットワークポリシーを作成する場合は、カスタムの namespace またはプロジェクトに
network.openshift.io/policy-group: ingressラベルを適用しないでください。このラベルは Operator によって管理されており、OpenShift Container Platform のネットワーク機能用に予約されています。システムによって作成された namespace でこのラベルを変更しないでください。このラベルを使用すると、断続的なネットワーク接続の切断、意図しないシステム
NetworkPoliciesリソースの適用、または Operator が状態をリコンサイルしようとする際に設定のドリフトが発生する可能性があります。カスタムのトラフィックグループを作成する場合は、以下の手順に示すように、必ず一意のユーザー定義ラベルを使用してください。
以下のサンプル NetworkPolicy オブジェクトは、複数の異なるシナリオをサポートすることを示しています。
すべてのトラフィックを拒否します。
プロジェクトに deny by default (デフォルトで拒否) を実行させるには、すべての Pod に一致するが、トラフィックを一切許可しない
NetworkPolicyオブジェクトを追加します。kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: deny-by-default spec: podSelector: {} ingress: []OpenShift Container Platform Ingress Controller からの接続のみを許可します。
プロジェクトで OpenShift Container Platform Ingress Controller からの接続のみを許可するには、以下の
NetworkPolicyオブジェクトを追加します。apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-openshift-ingress spec: ingress: - from: - namespaceSelector: matchLabels: policy-group.network.openshift.io/ingress: "" podSelector: {} policyTypes: - Ingressプロジェクト内の Pod からの接続のみを受け入れます。
重要同じ namespace 内の
hostNetworkPod からの Ingress 接続を許可するには、allow-from-hostnetworkポリシーとallow-same-namespaceポリシーを一緒に適用する必要があります。Pod が同じプロジェクト内の他の Pod からの接続を受け入れるが、他のプロジェクトの Pod からの接続を拒否するように設定するには、以下の
NetworkPolicyオブジェクトを追加します。kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-same-namespace spec: podSelector: {} ingress: - from: - podSelector: {}Pod ラベルに基づいて HTTP および HTTPS トラフィックのみを許可します。
特定のラベル (以下の例の
role=frontend) の付いた Pod への HTTP および HTTPS アクセスのみを有効にするには、以下と同様のNetworkPolicyオブジェクトを追加します。kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-http-and-https spec: podSelector: matchLabels: role: frontend ingress: - ports: - protocol: TCP port: 80 - protocol: TCP port: 443namespace および Pod セレクターの両方を使用して接続を受け入れます。
namespace と Pod セレクターを組み合わせてネットワークトラフィックのマッチングをするには、以下と同様の
NetworkPolicyオブジェクトを使用できます。kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-pod-and-namespace-both spec: podSelector: matchLabels: name: test-pods ingress: - from: - namespaceSelector: matchLabels: project: project_name podSelector: matchLabels: name: test-pods
NetworkPolicy オブジェクトは加算されるものです。つまり、複数の NetworkPolicy オブジェクトを組み合わせて複雑なネットワーク要件を満すことができます。
たとえば、先の例で定義された NetworkPolicy オブジェクトの場合、同じプロジェト内に allow-same-namespace と allow-http-and-https ポリシーの両方を定義することができます。これにより、ラベル role=frontend の付いた Pod は各ポリシーで許可されるすべての接続を受け入れます。つまり、同じ namespace の Pod からのすべてのポート、およびすべての namespace の Pod からのポート 80 および 443 での接続を受け入れます。
3.1.1.1. allow-from-router ネットワークポリシーの使用 リンクのコピーリンクがクリップボードにコピーされました!
次の NetworkPolicy を使用して、ルーターの設定に関係なく外部トラフィックを許可します。
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-from-router
spec:
ingress:
- from:
- namespaceSelector:
matchLabels:
policy-group.network.openshift.io/ingress: ""
podSelector: {}
policyTypes:
- Ingress
policy-group.network.openshift.io/ingress:"" ラベルは OVN-Kubernetes をサポートします。
3.1.1.2. allow-from-hostnetwork ネットワークポリシーの使用 リンクのコピーリンクがクリップボードにコピーされました!
次の allow-from-hostnetwork NetworkPolicy オブジェクトを追加して、ホストネットワーク Pod からのトラフィックを転送します。
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-from-hostnetwork
spec:
ingress:
- from:
- namespaceSelector:
matchLabels:
policy-group.network.openshift.io/host-network: ""
podSelector: {}
policyTypes:
- Ingress
3.1.2. OVN-Kubernetes ネットワークプラグインによるネットワークポリシーの最適化 リンクのコピーリンクがクリップボードにコピーされました!
OVN-Kubernetes のネットワークポリシーを最適化してフロー数を削減し、必要な場合に外部 IP トラフィックを許可する方法を説明します。
ネットワークポリシーを設計する場合は、以下のガイドラインを参照してください。
-
同じ
spec.podSelector仕様を持つネットワークポリシーの場合、ingressルールまたはegressルールを持つ複数のネットワークポリシーを使用するよりも、複数のingressルールまたはegressルールを持つ 1 つのネットワークポリシーを使用する方が効率的です。 podSelectorまたはnamespaceSelector仕様に基づくすべてのingressまたはegressルールは、number of pods selected by network policy + number of pods selected by ingress or egress ruleに比例する数の OVS フローを生成します。そのため、Pod ごとに個別のルールを作成するのではなく、1 つのルールで必要な数の Pod を選択できるpodSelectorまたはnamespaceSelector仕様を使用することが推奨されます。たとえば、以下のポリシーには 2 つのルールが含まれています。
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: test-network-policy spec: podSelector: {} ingress: - from: - podSelector: matchLabels: role: frontend - from: - podSelector: matchLabels: role: backend以下のポリシーは、上記と同じ 2 つのルールを 1 つのルールとして表現しています。
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: test-network-policy spec: podSelector: {} ingress: - from: - podSelector: matchExpressions: - {key: role, operator: In, values: [frontend, backend]}同じガイドラインが
spec.podSelector仕様に適用されます。異なるネットワークポリシーに同じingressルールまたはegressルールがある場合、共通のspec.podSelector仕様で 1 つのネットワークポリシーを作成する方が効率的な場合があります。たとえば、以下の 2 つのポリシーには異なるルールがあります。apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: policy1 spec: podSelector: matchLabels: role: db ingress: - from: - podSelector: matchLabels: role: frontend --- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: policy2 spec: podSelector: matchLabels: role: client ingress: - from: - podSelector: matchLabels: role: frontend以下のネットワークポリシーは、上記と同じ 2 つのルールを 1 つのルールとして表現しています。
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: policy3 spec: podSelector: matchExpressions: - {key: role, operator: In, values: [db, client]} ingress: - from: - podSelector: matchLabels: role: frontendこの最適化は、複数のセレクターを 1 つのセレクターとして表現する場合に限り適用できます。セレクターが異なるラベルに基づいている場合、この最適化は適用できない可能性があります。その場合は、ネットワークポリシーの最適化に特化して新規ラベルをいくつか適用することを検討してください。
3.1.2.1. OVN-Kubernetes の NetworkPolicy CR と外部 IP リンクのコピーリンクがクリップボードにコピーされました!
OVN-Kubernetes では、NetworkPolicy カスタムリソース (CR) によって厳密な分離ルールが適用されます。サービスが外部 IP を使用して公開されている場合、トラフィックを許可するように明示的に設定されていない限り、ネットワークポリシーによって他の namespace からのアクセスがブロックされる可能性があります。
namespace をまたいで外部 IP へのアクセスを許可するには、必要な namespace からの Ingress を明示的に許可し、指定されたサービスポートへのトラフィックが許可されるようにする NetworkPolicy CR を作成します。必要なポートへのトラフィックを許可しなければ、アクセスが制限される可能性があります。
出力例
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
annotations:
name: <policy_name>
namespace: openshift-ingress
spec:
ingress:
- ports:
- port: 80
protocol: TCP
- ports:
- port: 443
protocol: TCP
- from:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: <my_namespace>
podSelector: {}
policyTypes:
- Ingress
ここでは、以下のようになります。
<policy_name>- ポリシーの名前を指定します。
<my_namespace>- ポリシーがデプロイされる namespace の名前を指定します。
詳細は、「ネットワークポリシーについて」を参照してください。