24.4. OVN-Kubernetes ネットワークポリシー
AdminNetworkPolicy リソースはテクノロジープレビューのみの機能です。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
Kubernetes は、ネットワークセキュリティーの強化に使用できる 2 つの機能を提供します。機能の 1 つは、ユーザーによるネットワークポリシーの適用を可能にする NetworkPolicy API です。これは主にアプリケーション開発者と namespace テナント向けの機能で、namespace スコープのポリシーを作成して namespace を保護することを目的としています。詳細は、ネットワークポリシーについて を参照してください。
もう 1 つの機能は AdminNetworkPolicy です。これは、AdminNetworkPolicy (ANP) API と BaselineAdminNetworkPolicy (BANP) API の 2 つの API で構成されます。ANP と BANP は、クラスターおよびネットワーク管理者向けの機能で、クラスタースコープのポリシーを作成してクラスター全体を保護することを目的としています。クラスター管理者は、ANP を使用すると、NetworkPolicy オブジェクトよりも優先されるオーバーライド不可能なポリシーを適用できます。BANP を使用すると、NetworkPolicy オブジェクトを使用して必要に応じてユーザーがオーバーライドできるオプションのクラスタースコープのネットワークポリシールールを設定および適用できます。ANP と BANP を一緒に使用すると、クラスターの保護に使用できるマルチテナンシーポリシーを作成できます。
OpenShift Container Platform の OVN-Kubernetes CNI は、アクセス制御リスト (ACL) の階層を使用してこれらのネットワークポリシーを実装し、それらを評価して適用します。ACL は、階層 1 から階層 3 まで降順で評価されます。
階層 1 では AdminNetworkPolicy (ANP) オブジェクトを評価します。階層 2 では NetworkPolicy オブジェクトを評価します。階層 3 では BaselineAdminNetworkPolicy (BANP) オブジェクトを評価します。
図24.3 OVK-Kubernetes アクセス制御リスト (ACL)
トラフィックが ANP ルールに一致した場合、その ANP 内のルールが最初に評価されます。一致が ANP の allow または deny ルールの場合、クラスター内の既存の NetworkPolicies および BaselineAdminNetworkPolicy (BANP) が評価から意図的に省略されます。一致が ANP の pass ルールの場合、評価が ACL 階層 1 から階層 2 に進み、そこで NetworkPolicy ポリシーが評価されます。
24.4.1. AdminNetworkPolicy
AdminNetworkPolicy (ANP) は、クラスタースコープのカスタムリソース定義 (CRD) です。OpenShift Container Platform 管理者は、namespace を作成する前にネットワークポリシーを作成することで、ANP を使用してネットワークを保護できます。さらに、NetworkPolicy オブジェクトによってオーバーライドできないネットワークポリシーをクラスタースコープのレベルで作成できます。
AdminNetworkPolicy オブジェクトと NetworkPolicy オブジェクトの主な違いは、前者は管理者用でクラスタースコープであるのに対し、後者はテナント所有者用で namespace スコープであることです。
ANP を使用すると、管理者は以下を指定できます。
-
評価の順序を決定する
priority値。値が小さいほど優先度が高くなります。 -
一連の namespace または namespace で構成される
subject。 -
subjectへのすべての Ingress トラフィックに適用される Ingress ルールのリスト。 -
subjectからのすべての Egress トラフィックに適用される Egress ルールのリスト。
AdminNetworkPolicy リソースは、実稼働環境ではないテストクラスターで有効にできる TechnologyPreviewNoUpgrade 機能です。フィーチャーゲートと TechnologyPreviewNoUpgrade 機能の詳細には、このセクションの「関連情報」の「フィーチャーゲートの使用による各種機能の有効化」を参照してください。
AdminNetworkPolicy の例
例24.1 ANP の YAML ファイルの例
apiVersion: policy.networking.k8s.io/v1alpha1 kind: AdminNetworkPolicy metadata: name: sample-anp-deny-pass-rules 1 spec: priority: 50 2 subject: namespaces: matchLabels: kubernetes.io/metadata.name: example.name 3 ingress: 4 - name: "deny-all-ingress-tenant-1" 5 action: "Deny" from: - pods: namespaces: 6 namespaceSelector: matchLabels: custom-anp: tenant-1 podSelector: matchLabels: custom-anp: tenant-1 7 egress:8 - name: "pass-all-egress-to-tenant-1" action: "Pass" to: - pods: namespaces: namespaceSelector: matchLabels: custom-anp: tenant-1 podSelector: matchLabels: custom-anp: tenant-1
- 1
- ANP の名前を指定します。
- 2
spec.priorityフィールドは、0 から 99 までの値を受け入れ、クラスター内で最大 100 個の ANP をサポートします。値が小さいほど優先度が高くなります。同じ優先度のAdminNetworkPolicyを作成すると、非決定的な結果が生じます。- 3
- ANP リソースを適用する namespace を指定します。
- 4
- ANP には Ingress ルールと Egress ルールの両方があります。
spec.ingressフィールドの ANP ルールは、actionフィールドのPass、Deny、およびAllowの値を受け入れます。 - 5
ingress.nameの名前を指定します。- 6
- ANP リソースを適用する Pod の選択元の namespace を指定します。
- 7
- ANP リソースを適用する Pod の
podSelector.matchLabels名を指定します。 - 8
- ANP には Ingress ルールと Egress ルールの両方があります。
spec.egressフィールドの ANP ルールは、actionフィールドのPass、Deny、およびAllowの値を受け入れます。
24.4.1.1. ルールの AdminNetworkPolicy アクション
管理者は、AdminNetworkPolicy ルールの action フィールドに Allow、Deny、または Pass を設定できます。OVN-Kubernetes は階層型 ACL を使用してネットワークトラフィックルールを評価するため、ANP を使用すると、非常に強力なポリシールールを設定できます。このポリシールールを変更するには、管理者がルールを変更、削除するか、より高い優先度のルールを設定してオーバーライドする必要があります。
AdminNetworkPolicy の Allow の例
優先度 9 で定義されている次の ANP は、monitoring namespace からクラスター内の任意のテナント (他のすべての namespace) への Ingress トラフィックをすべて許可します。
例24.2 強力な Allow ANP の YAML ファイルの例
apiVersion: policy.networking.k8s.io/v1alpha1
kind: AdminNetworkPolicy
metadata:
name: allow-monitoring
spec:
priority: 9
subject:
namespaces: {}
ingress:
- name: "allow-ingress-from-monitoring"
action: "Allow"
from:
- namespaces:
namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: monitoring
# ...
これは、関係者全員がオーバーライドできない強力な Allow ANP の例です。テナントは、NetworkPolicy オブジェクトを使用してテナント自体の監視をブロックすることはできません。また、監視を実行するテナントが監視の対象を決定することもできません。
AdminNetworkPolicy の Deny の例
優先度 5 で定義されている次の ANP は、monitoring namespace から制限付きテナント (security: restricted ラベルを持つ namespace) への Ingress トラフィックをすべてブロックします。
例24.3 強力な Deny ANP の YAML ファイルの例
apiVersion: policy.networking.k8s.io/v1alpha1
kind: AdminNetworkPolicy
metadata:
name: block-monitoring
spec:
priority: 5
subject:
namespaces:
matchLabels:
security: restricted
ingress:
- name: "deny-ingress-from-monitoring"
action: "Deny"
from:
- namespaces:
namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: monitoring
# ...
これは、関係者全員がオーバーライドできない強力な Deny ANP です。制限付きテナントの所有者は、トラフィックの監視を許可する権限を自分自身に付与できません。また、インフラストラクチャーの監視サービスは、これらの機密性の高い namespace から何も収集できません。
強力な Allow の例と組み合わせると、block-monitoring ANP の優先度の値よりも Allow の優先度の値のほうが高いため、制限付きテナントが監視されなくなります。
AdminNetworkPolicy の Pass の例
優先度 7 で定義されている次の ANP は、monitoring namespace から内部インフラストラクチャーテナント (security: internal ラベルを持つ namespace) への Ingress トラフィックをすべて ACL の階層 2 に渡し、トラフィックが namespace の NetworkPolicy オブジェクトによって評価されるようにします。
例24.4 強力な Pass ANP の YAML ファイルの例
apiVersion: policy.networking.k8s.io/v1alpha1
kind: AdminNetworkPolicy
metadata:
name: pass-monitoring
spec:
priority: 7
subject:
namespaces:
matchLabels:
security: internal
ingress:
- name: "pass-ingress-from-monitoring"
action: "Pass"
from:
- namespaces:
namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: monitoring
# ...
この例は、テナント所有者によって定義された NetworkPolicy オブジェクトに決定を委譲する強力な Pass アクション ANP です。この pass-monitoring ANP により、internal セキュリティーレベルでグループ化されたすべてのテナント所有者は、インフラストラクチャーの監視サービスによって namespace スコープの NetworkPolicy オブジェクトを使用してメトリクスを収集する必要があるかどうかを選択できます。
24.4.2. 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 は、実稼働環境ではないテストクラスターで有効にできる TechnologyPreviewNoUpgrade 機能です。
BaselineAdminNetworkPolicy の例
例24.5 BANP の YAML ファイルの例
apiVersion: policy.networking.k8s.io/v1alpha1 kind: BaselineAdminNetworkPolicy metadata: name: default 1 spec: subject: namespaces: matchLabels: kubernetes.io/metadata.name: example.name 2 ingress: 3 - name: "deny-all-ingress-from-tenant-1" 4 action: "Deny" from: - pods: namespaces: namespaceSelector: matchLabels: custom-banp: tenant-1 5 podSelector: matchLabels: custom-banp: tenant-1 6 egress: - name: "allow-all-egress-to-tenant-1" action: "Allow" to: - pods: namespaces: namespaceSelector: matchLabels: custom-banp: tenant-1 podSelector: matchLabels: custom-banp: tenant-1
- 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 トラフィックに対するガードレールポリシーとして機能します。
例24.6 Deny ガードレールルールの YAML ファイルの例
apiVersion: policy.networking.k8s.io/v1alpha1
kind: BaselineAdminNetworkPolicy
metadata:
name: default
spec:
subject:
namespaces:
matchLabels:
security: internal
ingress:
- name: "deny-ingress-from-monitoring"
action: "Deny"
from:
- namespaces:
namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: monitoring
# ...
action フィールドに Pass 値を指定した AdminNetworkPolicy リソースを BaselineAdminNetworkPolicy リソースと組み合わせて使用すると、マルチテナントポリシーを作成できます。このマルチテナントポリシーを使用すると、あるテナントのアプリケーションの監視データを収集しながら、別のテナントのデータを収集しないことが可能になります。
管理者が「AdminNetworkPolicy の Pass アクションの例」と「BaselineAdminNetwork Policy の Deny の例」の両方を適用すると、BANP の前に評価される NetworkPolicy リソースを作成するかどうかをテナントが選択できるようになります。
たとえば、テナント 1 が Ingress トラフィックを監視する次の NetworkPolicy リソースを設定したとします。
例24.7 NetworkPolicy の例
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-monitoring
namespace: tenant 1
spec:
podSelector:
policyTypes:
- Ingress
ingress:
- from:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: monitoring
# ...
この場合、テナント 1 のポリシーは、「AdminNetworkPolicy の Pass アクションの例」の後、security レベルが internal のテナントに着信する Ingress 監視トラフィックをすべて拒否する「BaselineAdminNetworkPolicy の Deny の例」の前に評価されます。テナント 1 の NetworkPolicy オブジェクトを設定すると、テナント 1 はアプリケーションのデータを収集できるようになります。一方、NetworkPolicy オブジェクトが設定されていないテナント 2 は、データを収集できません。管理者はデフォルトでは内部のテナントを監視していませんでした。その代わりに BANP を作成し、テナントが NetworkPolicy オブジェクトを使用して BANP のデフォルト動作をオーバーライドできるようにしました。
