6.2. 管理ネットワークポリシー
6.2.1. OVN-Kubernetes AdminNetworkPolicy
6.2.1.1. AdminNetworkPolicy
AdminNetworkPolicy
(ANP) は、クラスタースコープのカスタムリソース定義 (CRD) です。Red Hat OpenShift Service on AWS 管理者は、namespace を作成する前にネットワークポリシーを作成することで、ANP を使用してネットワークを保護できます。さらに、NetworkPolicy
オブジェクトによってオーバーライドできないネットワークポリシーをクラスタースコープのレベルで作成できます。
AdminNetworkPolicy
オブジェクトと NetworkPolicy
オブジェクトの主な違いは、前者は管理者用でクラスタースコープであるのに対し、後者はテナント所有者用で namespace スコープであることです。
ANP を使用すると、管理者は以下を指定できます。
-
評価の順序を決定する
priority
値。値が小さいほど優先度が高くなります。 - ポリシーが適用される namespace のセットまたは namespace で構成される Pod のセット。
-
subject
へのすべての Ingress トラフィックに適用される Ingress ルールのリスト。 -
subject
からのすべての Egress トラフィックに適用される Egress ルールのリスト。
AdminNetworkPolicy の例
例6.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: namespaceSelector: matchLabels: custom-anp: tenant-1 podSelector: matchLabels: custom-anp: tenant-1 6 egress:7 - name: "pass-all-egress-to-tenant-1" action: "Pass" to: - pods: namespaceSelector: matchLabels: custom-anp: tenant-1 podSelector: matchLabels: custom-anp: tenant-1
- 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 ファイルの例
apiVersion: policy.networking.k8s.io/v1alpha1 kind: AdminNetworkPolicy metadata: name: allow-monitoring spec: priority: 9 subject: namespaces: {} # Use the empty selector with caution because it also selects OpenShift namespaces as well. ingress: - name: "allow-ingress-from-monitoring" action: "Allow" from: - namespaces: matchLabels: kubernetes.io/metadata.name: monitoring # ...
これは、関係者全員がオーバーライドできない強力な Allow
ANP の例です。テナントは、NetworkPolicy
オブジェクトを使用してテナント自体の監視をブロックすることはできません。また、監視を実行するテナントが監視の対象を決定することもできません。
AdminNetworkPolicy の Deny の例
優先度 5 で定義されている次の ANP は、monitoring
namespace から制限付きテナント (security: restricted
ラベルを持つ namespace) への Ingress トラフィックをすべてブロックします。
例6.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: 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
オブジェクトによって評価されるようにします。
例6.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: matchLabels: kubernetes.io/metadata.name: monitoring # ...
この例は、テナント所有者によって定義された NetworkPolicy
オブジェクトに決定を委譲する強力な Pass
アクション ANP です。この pass-monitoring
ANP により、internal
セキュリティーレベルでグループ化されたすべてのテナント所有者は、インフラストラクチャーの監視サービスによって namespace スコープの NetworkPolicy
オブジェクトを使用してメトリクスを収集する必要があるかどうかを選択できます。
6.2.2. OVN-Kubernetes BaselineAdminNetworkPolicy
6.2.2.1. BaselineAdminNetworkPolicy
BaselineAdminNetworkPolicy
(BANP) は、クラスタースコープのカスタムリソース定義 (CRD) です。Red Hat OpenShift Service on AWS は、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 ファイルの例
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: 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: 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 トラフィックに対するガードレールポリシーとして機能します。
例6.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: matchLabels: kubernetes.io/metadata.name: monitoring # ...
action
フィールドに Pass
値を指定した AdminNetworkPolicy
リソースを BaselineAdminNetworkPolicy
リソースと組み合わせて使用すると、マルチテナントポリシーを作成できます。このマルチテナントポリシーを使用すると、あるテナントのアプリケーションの監視データを収集しながら、別のテナントのデータを収集しないことが可能になります。
管理者が「AdminNetworkPolicy の Pass
アクションの例」と「BaselineAdminNetwork Policy の Deny
の例」の両方を適用すると、BANP の前に評価される NetworkPolicy
リソースを作成するかどうかをテナントが選択できるようになります。
たとえば、テナント 1 が Ingress トラフィックを監視する次の NetworkPolicy
リソースを設定したとします。
例6.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 のデフォルト動作をオーバーライドできるようにしました。