6.2. 管理ネットワークポリシー
6.2.1. OVN-Kubernetes AdminNetworkPolicy リンクのコピーリンクがクリップボードにコピーされました!
6.2.1.1. AdminNetworkPolicy リンクのコピーリンクがクリップボードにコピーされました!
AdminNetworkPolicy
(ANP) は、クラスタースコープのカスタムリソース定義 (CRD) です。OpenShift Container Platform 管理者は、namespace を作成する前にネットワークポリシーを作成することで、ANP を使用してネットワークを保護できます。さらに、NetworkPolicy
オブジェクトによってオーバーライドできないネットワークポリシーをクラスタースコープのレベルで作成できます。
AdminNetworkPolicy
オブジェクトと NetworkPolicy
オブジェクトの主な違いは、前者は管理者用でクラスタースコープであるのに対し、後者はテナント所有者用で namespace スコープであることです。
ANP を使用すると、管理者は以下を指定できます。
-
評価の順序を決定する
priority
値。値が小さいほど優先度が高くなります。 - ポリシーが適用される namespace のセットまたは namespace で構成される Pod のセット。
-
subject
へのすべての Ingress トラフィックに適用される Ingress ルールのリスト。 -
subject
からのすべての Egress トラフィックに適用される Egress ルールのリスト。
AdminNetworkPolicy の例
例6.1 ANP の YAML ファイルの例
- 1
- ANP の名前を指定します。
- 2
spec.priority
フィールドは、0 - 99
の値を受け入れ、クラスター内で最大 100 個の ANP をサポートします。範囲は最低値から最高値の順に読み取られるため、値が低いほど優先度が高くなります。同じ優先度で ANP を作成すると、どのポリシーが優先されるか保証されません。そのため、優先順位が意図したものになるように、異なる優先度で ANP を設定してください。- 3
- ANP リソースを適用する namespace を指定します。
- 4
- ANP には Ingress ルールと Egress ルールの両方があります。
spec.ingress
フィールドの ANP ルールは、action
フィールドのPass
、Deny
、およびAllow
の値を受け入れます。 - 5
ingress.name
の名前を指定します。- 6
namespaceSelector.matchLabels
によって選択された namespace 内の Pod を Ingress ピアとして選択するには、podSelector.matchLabels
を指定します。- 7
- ANP には、Ingress と Egress ルールの両方があります。
spec.egress
フィールドの ANP ルールは、action
フィールドのPass
、Deny
、およびAllow
の値を受け入れます。
6.2.1.1.1. ルールの AdminNetworkPolicy アクション リンクのコピーリンクがクリップボードにコピーされました!
管理者は、AdminNetworkPolicy
ルールの action
フィールドに Allow
、Deny
、または Pass
を設定できます。OVN-Kubernetes は階層型 ACL を使用してネットワークトラフィックルールを評価するため、ANP を使用すると、非常に強力なポリシールールを設定できます。このポリシールールを変更するには、管理者がルールを変更、削除するか、より高い優先度のルールを設定してオーバーライドする必要があります。
AdminNetworkPolicy の Allow の例
優先度 9 で定義されている次の ANP は、monitoring
namespace からクラスター内の任意のテナント (他のすべての namespace) への Ingress トラフィックをすべて許可します。
例6.2 強力な Allow
ANP の YAML ファイルの例
これは、関係者全員がオーバーライドできない強力な Allow
ANP の例です。テナントは、NetworkPolicy
オブジェクトを使用してテナント自体の監視をブロックすることはできません。また、監視を実行するテナントが監視の対象を決定することもできません。
AdminNetworkPolicy の Deny の例
優先度 5 で定義されている次の ANP は、monitoring
namespace から制限付きテナント (security: restricted
ラベルを持つ namespace) への Ingress トラフィックをすべてブロックします。
例6.3 強力な Deny
ANP の YAML ファイルの例
これは、関係者全員がオーバーライドできない強力な Deny
ANP です。制限付きテナントの所有者は、トラフィックの監視を許可する権限を自分自身に付与できません。また、インフラストラクチャーの監視サービスは、これらの機密性の高い namespace から何も収集できません。
強力な Allow
の例と組み合わせると、block-monitoring
ANP の優先度の値よりも Allow の優先度の値のほうが高いため、制限付きテナントが監視されなくなります。
AdminNetworkPolicy の Pass の例
優先度 7 で定義されている次の ANP は、monitoring
namespace から内部インフラストラクチャーテナント (security: internal
ラベルを持つ namespace) への Ingress トラフィックをすべて ACL の階層 2 に渡し、トラフィックが namespace の NetworkPolicy
オブジェクトによって評価されるようにします。
例6.4 強力な Pass
ANP の YAML ファイルの例
この例は、テナント所有者によって定義された NetworkPolicy
オブジェクトに決定を委譲する強力な Pass
アクション ANP です。この pass-monitoring
ANP により、internal
セキュリティーレベルでグループ化されたすべてのテナント所有者は、インフラストラクチャーの監視サービスによって namespace スコープの NetworkPolicy
オブジェクトを使用してメトリクスを収集する必要があるかどうかを選択できます。
6.2.2. OVN-Kubernetes BaselineAdminNetworkPolicy リンクのコピーリンクがクリップボードにコピーされました!
6.2.2.1. BaselineAdminNetworkPolicy リンクのコピーリンクがクリップボードにコピーされました!
BaselineAdminNetworkPolicy
(BANP) は、クラスタースコープのカスタムリソース定義 (CRD) です。OpenShift Container Platform 管理者は、BANP を使用すると、NetworkPolicy
オブジェクトを使用してユーザーが必要に応じてオーバーライドできるオプションのベースラインネットワークポリシールールを設定および適用できます。BANP のルールアクションは、allow
または deny
です。
BaselineAdminNetworkPolicy
リソースは、クラスターのシングルトンオブジェクトであり、渡されたトラフィックポリシーがクラスター内のどの NetworkPolicy
オブジェクトにも一致しない場合にガードレールポリシーとして使用できます。BANP は、クラスター内トラフィックをデフォルトでブロックするガードレールを提供するデフォルトのセキュリティーモデルとしても使用できます。その場合、ユーザーが NetworkPolicy
オブジェクトを使用して既知のトラフィックを許可する必要があります。BANP リソースを作成するときは、名前として default
を使用する必要があります。
BANP を使用すると、管理者は以下を指定できます。
-
一連の namespace または namespace で構成される
subject
。 -
subject
へのすべての Ingress トラフィックに適用される Ingress ルールのリスト。 -
subject
からのすべての Egress トラフィックに適用される Egress ルールのリスト。
BaselineAdminNetworkPolicy の例
例6.5 BANP の YAML ファイルの例
- 1
- BANP はシングルトンオブジェクトであるため、ポリシー名は
default
にする必要があります。 - 2
- ANP を適用する namespace を指定します。
- 3
- BANP には Ingress ルールと Egress ルールの両方があります。
spec.ingress
フィールドとspec.egress
フィールドの BANP ルールは、action
フィールドのDeny
とAllow
の値を受け入れます。 - 4
ingress.name
の名前を指定します。- 5
- BANP リソースを適用する Pod の選択元の namespace を指定します。
- 6
- BANP リソースを適用する Pod の
podSelector.matchLabels
名を指定します。
BaselineAdminNetworkPolicy の Deny の例
次の BANP シングルトンは、internal
セキュリティーレベルのテナントに着信するすべての Ingress 監視トラフィックに対してデフォルトの拒否ポリシーを設定します。「AdminNetworkPolicy の Pass の例」と組み合わせると、この拒否ポリシーは、ANP pass-monitoring
ポリシーによって渡されるすべての Ingress トラフィックに対するガードレールポリシーとして機能します。
例6.6 Deny
ガードレールルールの YAML ファイルの例
action
フィールドに Pass
値を指定した AdminNetworkPolicy
リソースを BaselineAdminNetworkPolicy
リソースと組み合わせて使用すると、マルチテナントポリシーを作成できます。このマルチテナントポリシーを使用すると、あるテナントのアプリケーションの監視データを収集しながら、別のテナントのデータを収集しないことが可能になります。
管理者が「AdminNetworkPolicy の Pass
アクションの例」と「BaselineAdminNetwork Policy の Deny
の例」の両方を適用すると、BANP の前に評価される NetworkPolicy
リソースを作成するかどうかをテナントが選択できるようになります。
たとえば、テナント 1 が Ingress トラフィックを監視する次の NetworkPolicy
リソースを設定したとします。
例6.7 NetworkPolicy
の例
この場合、テナント 1 のポリシーは、「AdminNetworkPolicy の Pass
アクションの例」の後、security
レベルが internal
のテナントに着信する Ingress 監視トラフィックをすべて拒否する「BaselineAdminNetworkPolicy の Deny
の例」の前に評価されます。テナント 1 の NetworkPolicy
オブジェクトを設定すると、テナント 1 はアプリケーションのデータを収集できるようになります。一方、NetworkPolicy
オブジェクトが設定されていないテナント 2 は、データを収集できません。管理者はデフォルトでは内部のテナントを監視していませんでした。その代わりに BANP を作成し、テナントが NetworkPolicy
オブジェクトを使用して BANP のデフォルト動作をオーバーライドできるようにしました。
6.2.3. ANP と BANP の監視 リンクのコピーリンクがクリップボードにコピーされました!
AdminNetworkPolicy
および BaselineAdminNetworkPolicy
リソースには、ポリシーの監視と管理に使用できるメトリクスがあります。メトリクスの詳細は、以下の表を参照してください。
6.2.3.1. AdminNetworkPolicy のメトリクス リンクのコピーリンクがクリップボードにコピーされました!
名前 | 説明 | 詳細 |
---|---|---|
| 該当なし |
クラスター内の |
| 該当なし |
クラスター内の |
|
|
|
|
|
|
|
|
|
|
|
|
6.2.4. AdminNetworkPolicy の Egress ノードとネットワークピア リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、nodes
と networks
のピアを説明します。管理者は、このセクションの例を使用して、クラスター内のノースバウンドトラフィックを制御するための AdminNetworkPolicy
と BaselineAdminNetworkPolicy
を設計できます。
6.2.4.1. AdminNetworkPolicy および BaselineAdminNetworkPolicy のノースバウンドトラフィック制御 リンクのコピーリンクがクリップボードにコピーされました!
ANP と BANP では、East-West トラフィック制御のサポートに加えて、管理者がクラスターから出るノースバウンドトラフィックや、ノードからクラスター内の他のノードに向かうトラフィックを制御することもできます。エンドユーザーは次のことができます。
-
nodes
Egress ピアを使用してクラスターノードへの Egress トラフィック制御を実装する -
nodes
またはnetworks
の Egress ピアを使用して Kubernetes API サーバーへの Egress トラフィック制御を実装する -
networks
ピアを使用してクラスター外の外部宛先への Egress トラフィック制御を実装する
ANP および BANP の場合、nodes
と networks
のピアは Egress ルールに対してのみ指定できます。
6.2.4.1.1. ノードピアを使用してクラスターノードへの Egress トラフィックを制御する リンクのコピーリンクがクリップボードにコピーされました!
nodes
ピアを使用すると、管理者は Pod からクラスター内のノードへの Egress トラフィックを制御できます。この利点は、クラスターにノードを追加したり、クラスターからノードを削除したりするときにポリシーを変更する必要がないことです。
次の例では、ノードセレクターピアを使用して、restricted
、confidential
、または internal
レベルのセキュリティーを持つ任意の namespace によるポート 6443
上の Kubernetes API サーバーへの Egress トラフィックを許可します。また、セキュリティーレベルが restricted
、confidential
、または internal
のいずれかである namespace からクラスター内のすべてのワーカーノードへのトラフィックも拒否します。
例6.8 nodes
ピアを使用した ANP Allow
Egress の例
6.2.4.1.2. ネットワークピアを使用して外部の宛先への Egress トラフィックを制御する リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、networks
ピアで CIDR 範囲を使用し、Pod から networks
フィールドで指定された CIDR 範囲内の IP アドレスで設定された宛先に送信される Egress トラフィックを制御するポリシーを適用できます。
以下の例では、networks
ピアを使用し、ANP ポリシーと BANP ポリシーを組み合わせて出力トラフィックを制限します。
ANP および BANP の namespace
フィールドで空のセレクター ({}) を使用する場合は注意が必要です。空のセレクターを使用する場合は、OpenShift namespace も選択します。
ANP または BANP Deny
ルールで 0.0.0.0/0
の値を使用する場合は、Deny
を 0.0.0.0/0
に設定する前に、必要な宛先に優先度の高い ANP Allow
ルールを設定する必要があります。
例6.9 networks
ピアを使用した ANP と BANP の例
network-as-egress-peer
ANP と、networks
ピアを使用する networks
の BANP を組み合わせると、次の Egress ポリシーが適用されます。
- すべての Pod が、リストされた IP アドレスの外部 DNS サーバーと通信できない。
- すべての Pod が、会社のイントラネットの残りの部分と通信できる。
- すべての Pod が、他の Pod、ノード、およびサービスと通信できる。
-
どの Pod もインターネットと通信できない。最後の ANP
Pass
ルールと強力な BANPDeny
ルールを組み合わせることで、クラスター内のトラフィックを保護するガードレールポリシーが作成されます。
6.2.4.1.3. ノードピアとネットワークピアを一緒に使用する リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、ANP および BANP ポリシーで nodes
と networks
ピアを組み合わせることができます。
例6.10 nodes
と networks
ピアの例
6.2.5. AdminNetworkPolicy のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
6.2.5.1. ANP の作成の確認 リンクのコピーリンクがクリップボードにコピーされました!
AdminNetworkPolicy
(ANP) と BaselineAdminNetworkPolicy
(BANP) が正しく作成されていることを確認するには、oc describe anp
または oc describe banp
のコマンドのステータス出力を確認します。
ステータスが良好な場合は、OVN DB plumbing was successful
および SetupSucceeded
と表示されます。
例6.11 正常なステータスの ANP の例
設定が失敗した場合、それぞれのゾーンコントローラーからエラーが報告されます。
例6.12 不正なステータスとエラーメッセージを含む ANP の例
失敗したポリシーのトラブルシューティングに役立つ nbctl
コマンドについては、次のセクションを参照してください。
6.2.5.1.1. ANP および BANP への nbctl コマンドの使用 リンクのコピーリンクがクリップボードにコピーされました!
失敗したセットアップのトラブルシューティングを行うには、まず ACL
、AdressSet
、Port_Group
などの OVN Northbound データベース (nbdb) オブジェクトを確認します。nbdb を表示するには、そのノードの Pod 内にいて、そのノードのデータベース内のオブジェクトを表示する必要があります。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 -
OpenShift CLI (
oc
) がインストールされている。
クラスターで ovn nbctl
コマンドを実行するには、関連するノード上の `nbdb` にリモートシェルを起動する必要があります。
出力を生成するために次のポリシーが使用されました。
例6.13 出力の生成に使用される AdminNetworkPolicy
手順
次のコマンドを実行して、ノード情報を含む Pod をリスト表示します。
oc get pods -n openshift-ovn-kubernetes -owide
$ oc get pods -n openshift-ovn-kubernetes -owide
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、Pod に移動してノースバウンドデータベースを確認します。
oc rsh -c nbdb -n openshift-ovn-kubernetes ovnkube-node-524dt
$ oc rsh -c nbdb -n openshift-ovn-kubernetes ovnkube-node-524dt
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ACL nbdb を確認するには、次のコマンドを実行します。
ovn-nbctl find ACL 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,"k8s.ovn.org/name"=cluster-control}'
$ ovn-nbctl find ACL 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,"k8s.ovn.org/name"=cluster-control}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 詳細は以下のようになります。, cluster-control
-
トラブルシューティングする
AdminNetworkPolicy
の名前を指定します。 - AdminNetworkPolicy
-
AdminNetworkPolicy
またはBaselineAdminNetworkPolicy
のタイプを指定します。
例6.14 ACL の出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記Ingress および Egress の出力には、ACL のポリシーのロジックが表示されます。たとえば、パケットが指定された
match
と一致するたびにaction
が実行されます。次のコマンドを実行して、ルールの特定の ACL を調べます。
ovn-nbctl find ACL 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,direction=Ingress,"k8s.ovn.org/name"=cluster-control,gress-index="1"}'
$ ovn-nbctl find ACL 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,direction=Ingress,"k8s.ovn.org/name"=cluster-control,gress-index="1"}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 詳細は以下のようになります。,
cluster-control
-
ANP の
名前
を指定します。 Ingress
-
トラフィックの
方向
をIngress
またはEgress
のいずれかのタイプで指定します。 1
- 確認するルールを指定します。
priority
34
のcluster-control
という名前の ANP の例では、Ingress
rule
1 の出力例は次のとおりです。例6.15 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 詳細は以下のようになります。,
nbdb 内のアドレスセットを確認するには、次のコマンドを実行します。
ovn-nbctl find Address_Set 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,"k8s.ovn.org/name"=cluster-control}'
$ ovn-nbctl find Address_Set 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,"k8s.ovn.org/name"=cluster-control}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例6.16
Address_Set
の出力例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、ルールの特定のアドレスセットを調べます。
ovn-nbctl find Address_Set 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,direction=Egress,"k8s.ovn.org/name"=cluster-control,gress-index="5"}'
$ ovn-nbctl find Address_Set 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,direction=Egress,"k8s.ovn.org/name"=cluster-control,gress-index="5"}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例6.17
Address_Set
の出力例_uuid : 8fd3b977-6e1c-47aa-82b7-e3e3136c4a72 addresses : ["0.0.0.0/0"] external_ids : {direction=Egress, gress-index="5", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:5:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy} name : a11452480169090787059
_uuid : 8fd3b977-6e1c-47aa-82b7-e3e3136c4a72 addresses : ["0.0.0.0/0"] external_ids : {direction=Egress, gress-index="5", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:5:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy} name : a11452480169090787059
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のコマンドを実行して、nbdb 内のポートグループを確認します。
ovn-nbctl find Port_Group 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,"k8s.ovn.org/name"=cluster-control}'
$ ovn-nbctl find Port_Group 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,"k8s.ovn.org/name"=cluster-control}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例6.18
Port_Group
の出力例_uuid : f50acf71-7488-4b9a-b7b8-c8a024e99d21 acls : [04f20275-c410-405c-a923-0e677f767889, 0d5e4722-b608-4bb1-b625-23c323cc9926, 1a27d30e-3f96-4915-8ddd-ade7f22c117b, 1a68a5ed-e7f9-47d0-b55c-89184d97e81a, 4b5d836a-e0a3-4088-825e-f9f0ca58e538, 5a6e5bb4-36eb-4209-b8bc-c611983d4624, 5d09957d-d2cc-4f5a-9ddd-b97d9d772023, aa1a224d-7960-4952-bdfb-35246bafbac8, b23a087f-08f8-4225-8c27-4a9a9ee0c407, b7be6472-df67-439c-8c9c-f55929f0a6e0, d14ed5cf-2e06-496e-8cae-6b76d5dd5ccd] external_ids : {"k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy} name : a14645450421485494999 ports : [5e75f289-8273-4f8a-8798-8c10f7318833, de7e1b71-6184-445d-93e7-b20acadf41ea]
_uuid : f50acf71-7488-4b9a-b7b8-c8a024e99d21 acls : [04f20275-c410-405c-a923-0e677f767889, 0d5e4722-b608-4bb1-b625-23c323cc9926, 1a27d30e-3f96-4915-8ddd-ade7f22c117b, 1a68a5ed-e7f9-47d0-b55c-89184d97e81a, 4b5d836a-e0a3-4088-825e-f9f0ca58e538, 5a6e5bb4-36eb-4209-b8bc-c611983d4624, 5d09957d-d2cc-4f5a-9ddd-b97d9d772023, aa1a224d-7960-4952-bdfb-35246bafbac8, b23a087f-08f8-4225-8c27-4a9a9ee0c407, b7be6472-df67-439c-8c9c-f55929f0a6e0, d14ed5cf-2e06-496e-8cae-6b76d5dd5ccd] external_ids : {"k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy} name : a14645450421485494999 ports : [5e75f289-8273-4f8a-8798-8c10f7318833, de7e1b71-6184-445d-93e7-b20acadf41ea]
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.2.6. AdminNetworkPolicy のベストプラクティス リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、AdminNetworkPolicy
および BaselineAdminNetworkPolicy
リソースのベストプラクティスを説明します。
6.2.6.1. AdminNetworkPolicy の設計 リンクのコピーリンクがクリップボードにコピーされました!
AdminNetworkPolicy
(ANP) リソースを構築する場合は、ポリシーを作成するときに次の点を考慮する必要があります。
- 同じ優先度を持つ ANP を作成できます。同じ優先度で 2 つの ANP を作成する場合は、重複するルールが同じトラフィックに適用されないようにしてください。値ごとに 1 つのルールのみが適用されます。同じ優先度の値が複数ある場合は、どのルールが適用されるか保証されません。重複する ANP を作成すると、どのポリシーが優先されるか保証されません。そのため、優先順位が明確に定義されるように、異なる優先度で ANP を設定してください。
- 管理者は、システム namespace ではなくユーザー namespace に適用される ANP を作成する必要があります。
ANP および BaselineAdminNetworkPolicy
(BANP) をシステム namespace (default
、kube-system
、名前が openshift-
で始まる namespace など) に適用することはサポートされていないため、クラスターが応答しなくなり、機能しない状態になる可能性があります。
-
サポートされている優先度の範囲は
0 - 100
であるため、30 - 70
のような中間の範囲を使用するように ANP を設計することもできます。これにより、前後の優先順位のためのプレースホルダーが残ります。中間の範囲でも、インフラストラクチャーの要件が時間の経過とともに進化するにつれて、適切な優先度レベルで必要なときに新しい ANP を挿入できるように、ギャップを残しておくことを推奨します。ANP をパックすると、将来の変更に対応するために、それらをすべて再作成しないといけない場合があります。 -
0.0.0.0/0
または::/0
を使用して強力なDeny
ポリシーを作成する場合は、重要なトラフィックに対して優先度の高いAllow
またはPass
ルールがあることを確認してください。 -
どのような場合でも接続が許可されるようにしたい場合は、
action
フィールドとしてAllow
を使用します。ANP のAllow
ルールは、接続が常に許可され、NetworkPolicy
が無視されることを意味します。 -
接続を許可または拒否するポリシー決定を
NetworkPolicy
レイヤーに委任するには、action
フィールドにPass
を使用します。 - 複数のルールにわたるセレクターが重複しないようにして、同じ IP が複数のポリシーに表示されないようにします。これにより、パフォーマンスとスケールの制限が発生する可能性があります。
-
namedPorts
をPortNumber
およびPortRange
と組み合わせて使用することは避けてください。これにより 6 つの ACL が作成され、クラスターの効率が低下します。
6.2.6.1.1. BaselineAdminNetworkPolicy の使用に関する考慮事項 リンクのコピーリンクがクリップボードにコピーされました!
クラスター内で定義できる
BaselineAdminNetworkPolicy
(BANP) リソースは 1 つだけです。以下は、管理者が BANP を設計する際に考慮する可能性がある、BANP でサポートされている用途です。-
ユーザー namespace 内のクラスターローカル Ingress に対してデフォルトの拒否ポリシーを設定できます。この BANP により、開発者は許可したい Ingress トラフィックを許可するために
NetworkPolicy
オブジェクトを追加する必要があり、Ingress 用のネットワークポリシーを追加しないとトラフィックが拒否されます。 -
ユーザー namespace のクラスターローカル Egress に対してデフォルトの拒否ポリシーを設定できます。この BANP により、開発者は許可する Egress トラフィックを許可するために
NetworkPolicy
オブジェクトを追加する必要があり、ネットワークポリシーを追加しないとトラフィックが拒否されます。 -
クラスター内 DNS サービスへの Egress に対してデフォルトの許可ポリシーを設定できます。このような BANP により、namespace のユーザーは、クラスター内 DNS サービスへの許可 Egress
NetworkPolicy
を設定する必要がなくなります。 -
すべての Pod への内部 Egress トラフィックを許可し、すべての外部エンドポイント (つまり
0.0.0.0/0
および::/0
) へのアクセスを拒否する Egress ポリシーを設定できます。この BANP により、ユーザーワークロードは他のクラスター内エンドポイントにトラフィックを送信できますが、デフォルトでは外部エンドポイントには送信できません。開発者はNetworkPolicy
を使用して、アプリケーションが明示的な外部サービスセットにトラフィックを送信できるようにすることができます。
-
ユーザー namespace 内のクラスターローカル Ingress に対してデフォルトの拒否ポリシーを設定できます。この BANP により、開発者は許可したい Ingress トラフィックを許可するために
-
BANP のスコープを設定し、システム namespace ではなくユーザー namespace へのトラフィックのみを拒否するようにしてください。これは、システム namespace に BANP をオーバーライドする
NetworkPolicy
オブジェクトがないためです。
6.2.6.1.2. AdminNetworkPolicy と NetworkPolicy の考慮すべき相違点 リンクのコピーリンクがクリップボードにコピーされました!
-
NetworkPolicy
オブジェクトとは異なり、誤ってトラフィックが選択されることを避けるために、空の ({}
) キャッチオールセレクターを使用するのではなく、明示的なラベルを使用して ANP および BANP 内のワークロードを参照する必要があります。
インフラストラクチャー namespace に空の namespace セレクターを適用すると、クラスターが応答しなくなり、機能しない状態になる可能性があります。
-
ANP の API セマンティクスでは、暗黙的な拒否を持つ
NetworkPolicy
オブジェクトとは異なり、ポリシーを作成するときに許可または拒否のルールを明示的に定義する必要があります。 -
NetworkPolicy
オブジェクトとは異なり、AdminNetworkPolicy
オブジェクトの Ingress ルールはクラスター内の Pod と namespace に制限されているため、ホストネットワークからの Ingress のルールを設定することはできず、また設定する必要もありません。