2.6. AdminNetworkPolicy のベストプラクティス
このセクションでは、AdminNetworkPolicy
および BaselineAdminNetworkPolicy
リソースのベストプラクティスを説明します。
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 が作成され、クラスターの効率が低下します。
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
オブジェクトがないためです。
2.6.1.2. AdminNetworkPolicy と NetworkPolicy の考慮すべき相違点 リンクのコピーリンクがクリップボードにコピーされました!
-
NetworkPolicy
オブジェクトとは異なり、誤ってトラフィックが選択されることを避けるために、空の ({}
) キャッチオールセレクターを使用するのではなく、明示的なラベルを使用して ANP および BANP 内のワークロードを参照する必要があります。
インフラストラクチャー namespace に空の namespace セレクターを適用すると、クラスターが応答しなくなり、機能しない状態になる可能性があります。
-
ANP の API セマンティクスでは、暗黙的な拒否を持つ
NetworkPolicy
オブジェクトとは異なり、ポリシーを作成するときに許可または拒否のルールを明示的に定義する必要があります。 -
NetworkPolicy
オブジェクトとは異なり、AdminNetworkPolicy
オブジェクトの Ingress ルールはクラスター内の Pod と namespace に制限されているため、ホストネットワークからの Ingress のルールを設定することはできず、また設定する必要もありません。