第3章 ネットワークポリシー
3.1. ネットワークポリシーについて
MicroShift でネットワークポリシーがどのように機能し、クラスター内の Pod へのネットワークトラフィックを制限または許可するかを説明します。
3.1.1. MicroShift でのネットワークポリシーの仕組み
MicroShift のデフォルトの OVN-Kubernetes Container Network Interface (CNI) プラグインを使用するクラスターでは、ネットワーク分離は、ホスト上で設定されている firewalld と MicroShift 内で作成された NetworkPolicy
オブジェクトの両方によって制御されます。firewalld と NetworkPolicy
の同時使用がサポートされています。
-
ネットワークポリシーは、OVN-Kubernetes によって制御されるトラフィックの境界内でのみ機能するため、
hostPort/hostNetwork
が有効な Pod を除くあらゆる状況に適用できます。 -
また、firewalld 設定は、
hostPort/hostNetwork
が有効な Pod には適用されません。
firewalld ルールは、NetworkPolicy
が適用される前に実行されます。
ネットワークポリシーは、ホストのネットワーク namespace には適用されません。ホストネットワークが有効にされている Pod はネットワークポリシールールによる影響を受けません。ただし、ホストネットワークの Pod に接続する Pod はネットワークポリシールールの影響を受ける可能性があります。
ネットワークポリシーではローカルホストからのトラフィックをブロックできません。
デフォルトでは、MicroShift ノード内のすべての Pod は、他の Pod およびネットワークエンドポイントからアクセスできます。クラスターで 1 つ以上の Pod を分離するには、許可される受信接続を示す NetworkPolicy
オブジェクトを作成してください。NetworkPolicy
オブジェクトを作成および削除できます。
Pod が 1 つ以上の NetworkPolicy
オブジェクトのセレクターと一致する場合、Pod はそれらの NetworkPolicy
オブジェクトの少なくとも 1 つにより許可された接続だけを使用できます。NetworkPolicy
オブジェクトによって選択されていない Pod は完全にアクセス可能です。
ネットワークポリシーは、TCP、UDP、ICMP、および SCTP プロトコルにのみ適用されます。他のプロトコルは影響を受けません。
以下のサンプル NetworkPolicy
オブジェクトは、複数の異なるシナリオをサポートすることを示しています。
すべてのトラフィックを拒否します。
プロジェクトに deny by default (デフォルトで拒否) を実行させるには、すべての Pod に一致するが、トラフィックを一切許可しない
NetworkPolicy
オブジェクトを追加します。kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: deny-by-default spec: podSelector: {} ingress: []
MicroShift の Ingress であるデフォルトルーターからの接続を許可します。
MicroShift デフォルトルーターからの接続を許可するには、次の
NetworkPolicy
オブジェクトを追加します。apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-openshift-ingress spec: ingress: - from: - namespaceSelector: matchLabels: ingresscontroller.operator.openshift.io/deployment-ingresscontroller: default podSelector: {} policyTypes: - Ingress
同じ namespace 内の Pod からの接続のみを受け入れます。
Pod が同じ namespace 内の他の Pod からの接続を受け入れるが、他の namespace 内の 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: 443
namespace および 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.2. OVN-Kubernetes ネットワークプラグインによるネットワークポリシーの最適化
ネットワークポリシーを設計する場合は、以下のガイドラインを参照してください。
-
同じ
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 つのセレクターとして表現する場合に限り適用できます。セレクターが異なるラベルに基づいている場合、この最適化は適用できない可能性があります。その場合は、ネットワークポリシーの最適化に特化して新規ラベルをいくつか適用することを検討してください。