Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

ネットワークセキュリティー

OpenShift Container Platform 4.20

OpenShift Container Platform におけるネットワークトラフィックの保護とネットワークポリシーの適用

概要

このドキュメントでは、OpenShift Container Platform におけるネットワークポリシーや Egress ファイアウォールなどのネットワークセキュリティー機能を実装および管理する方法を説明します。

第1章 ネットワークポリシー API について
リンクのコピー

ネットワークポリシーは、クラスタースコープと namespace スコープの両方のネットワークポリシー API を使用して定義されます。これらのさまざまなレベルにわたってネットワークポリシーを定義することで、完全なマルチテナント分離を含む、クラスターの高度なネットワークセキュリティー設定を作成できます。

1.1. ネットワークポリシーとその範囲
リンクのコピー

クラスタースコープのネットワークポリシー

クラスターおよびネットワーク管理者は、AdminNetworkPolicy を使用してクラスターレベルでネットワークポリシーを定義できます。AdminNetworkPolicy 機能は、AdminNetworkPolicy API と BaselineAdminNetworkPolicy API の 2 つの API で構成されます。これらの API は、クラスター全体に適用できるルール、または namespace スコープの NetworkPolicy に委譲できるルールを設定するために使用されます。

AdminNetworkPolicy API を使用して定義されたポリシーは、「許可」または「拒否」に設定されている場合、他のすべてのポリシータイプよりも優先されます。ただし、管理者は "Pass" を使用して、特定のポリシーの責任を namespace スコープの NetworkPolicy に委譲し、アプリケーション開発者と namespace テナントが、プロジェクトのネットワークセキュリティーの特定の側面を制御できるようにすることもできます。

BaselineAdminNetworkPolicy API を使用して定義されたポリシーは、他のネットワークポリシーによってオーバーライドされない場合にのみ適用されます。AdminNetworkPolicy API を使用して、ネットワークポリシーの側面を namespace スコープの NetworkPolicy に委譲する場合は、BaselineAdminNetworkPolicy で適切な最小限の制限も定義する必要があります。これにより、namespace の NetworkPolicy が十分な保護を提供しない場合に、クラスターレベルでネットワークセキュリティーのベースラインレベルが確保されます。

namespace スコープのネットワークポリシー
アプリケーション開発者と namespace テナントは、NetworkPolicy API を使用して、特定の namespace のネットワークポリシールールを定義できます。namespace の NetworkPolicy 内のルールは、BaselineAdminNetworkPolicy API を使用して設定されたクラスター全体のルール、またはクラスター全体の AdminNetworkPolicy API から委譲または「渡された」クラスター全体のルールよりも優先されます。

1.2. ネットワークポリシーの評価と適用方法
リンクのコピー

ネットワーク接続が確立されると、ネットワークプロバイダー (デフォルト: OVN-Kubernetes) は、接続の詳細をネットワークポリシールールと照合して、接続の処理方法を決定します。

OVN-Kubernetes は、次の順序でネットワークポリシーオブジェクトに対する接続を評価します。

  1. AdminNetworkPolicy 層で一致を確認します。

    1. 接続が Allow または Deny ルールに一致する場合、そのルールに従って評価を停止します。
    2. 接続が Pass ルールに一致する場合は、NetworkPolicy 層に移動します。

  2. NetworkPolicy 層で一致を確認します。

    1. 接続がルールに一致する場合、そのルールに従って評価を停止します。
    2. 一致するものが見つからない場合は、BaselineAdminNetworkPolicy 層に移動します。
  3. BaselineAdminNetworkPolicy 層の一致するルールに従います。

図1.1 OVN-Kubernetes によるネットワークポリシーの評価

OVN-Kubernetes アクセス制御リスト (ACL)

1.3. AdminNetworkPolicy と NetworkPolicy カスタムリソースの主な違い
リンクのコピー

次の表は、クラスタースコープの AdminNetworkPolicy API と namespace スコープの NetworkPolicy API の主な違いを説明しています。

Expand
ポリシーの要素AdminNetworkPolicyNetworkPolicy

対象ユーザー

クラスター管理者または同等の権限

namespace の所有者

スコープ

Cluster

namespace

トラフィックのドロップ

明示的な Deny アクションをルールとして設定することでサポートされます。

ポリシー作成時に暗黙的に Deny 分離することでサポートされます。

トラフィックの委譲

Pass アクションをルールとして設定することでサポートされます。

該当なし。

トラフィックの許可

明示的に Allow アクションをルールとして設定することでサポートされます。

すべてのルールに対するデフォルトのアクションは allow です。

ポリシー内のルールの優先順位

ANP 内で表示される順序によって異なります。ルールの位置が高いほど、優先順位が高くなります。

ルールは加算的です。

ポリシーの優先順位

ANP 間では、priority フィールドによって評価の順序が設定されます。優先順位の数字が低いほど、ポリシーの優先順位が高くなります。

ポリシー間にポリシー順序はありません。

機能の優先順位

最初に Tier 1 ACL を介して評価され、最後に BANP が Tier 3 ACL を介して評価されます。

ANP の後、BANP の前に適用され、ACL の Tier 2 で評価されます。

Pod 選択の一致

namespace 間で異なるルールを適用できます。

1 つの namespace 内の Pod に異なるルールを適用できます。

クラスターの Egress トラフィック

nodes と networks ピアを介してサポートされます。

受け入れられた CIDR 構文とともに ipBlock フィールドを使用してサポートされます。

クラスター Ingress トラフィック

サポート対象外。

サポート対象外。

完全修飾ドメイン名 (FQDN) ピアサポート

サポート対象外。

サポート対象外。

namespace セレクター

namespaces.matchLabels フィールドを使用した namespace の高度な選択をサポートします。

namespaceSelector フィールドを使用したラベルベースでの namespace の選択をサポートします

第2章 管理ネットワークポリシー
リンクのコピー

2.1. OVN-Kubernetes AdminNetworkPolicy
リンクのコピー

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 ルールのリスト。
2.1.1.1. AdminNetworkPolicy の例
リンクのコピー

例2.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 の値を受け入れます。

関連情報

2.1.1.2. ルールの AdminNetworkPolicy アクション
リンクのコピー

管理者は、AdminNetworkPolicy ルールの action フィールドに Allow、Deny、または Pass を設定できます。OVN-Kubernetes は階層型 ACL を使用してネットワークトラフィックルールを評価するため、ANP を使用すると、非常に強力なポリシールールを設定できます。このポリシールールを変更するには、管理者がルールを変更、削除するか、より高い優先度のルールを設定してオーバーライドする必要があります。

2.1.1.2.1. AdminNetworkPolicy の Allow の例
リンクのコピー

優先度 9 で定義されている次の ANP は、monitoring namespace からクラスター内の任意のテナント (他のすべての namespace) への Ingress トラフィックをすべて許可します。

例2.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 オブジェクトを使用してテナント自体の監視をブロックすることはできません。また、監視を実行するテナントが監視の対象を決定することもできません。

2.1.1.2.2. AdminNetworkPolicy の Deny の例
リンクのコピー

優先度 5 で定義されている次の ANP は、monitoring namespace から制限付きテナント (security: restricted ラベルを持つ namespace) への Ingress トラフィックをすべてブロックします。

例2.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 の例よりも) 優先度の値が低いため優先順位が高くなり、これにより制限付きテナントが監視されることはなくなります。

2.1.1.2.3. AdminNetworkPolicy の Pass の例
リンクのコピー

優先度 7 で定義されている次の ANP は、monitoring namespace から内部インフラストラクチャーテナント (security: internal ラベルを持つ namespace) への Ingress トラフィックをすべて ACL の階層 2 に渡し、トラフィックが namespace の NetworkPolicy オブジェクトによって評価されるようにします。

例2.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 オブジェクトを使用してメトリクスを収集する必要があるかどうかを選択できます。

2.2. OVN-Kubernetes BaselineAdminNetworkPolicy
リンクのコピー

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 ルールのリスト。
2.2.1.1. BaselineAdminNetworkPolicy の例
リンクのコピー

例2.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 名を指定します。
2.2.1.2. BaselineAdminNetworkPolicy の Deny の例
リンクのコピー

次の BANP シングルトンは、internal セキュリティーレベルのテナントに着信するすべての Ingress 監視トラフィックに対してデフォルトの拒否ポリシーを設定します。「AdminNetworkPolicy の Pass の例」と組み合わせると、この拒否ポリシーは、ANP pass-monitoring ポリシーによって渡されるすべての Ingress トラフィックに対するガードレールポリシーとして機能します。

例2.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 リソースを設定したとします。

例2.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 監視トラフィックをすべて拒否する「BaselineAdminNetwork Policy の Deny の例」の前に評価されます。テナント 1 の NetworkPolicy オブジェクトを設定すると、テナント 1 はアプリケーションのデータを収集できるようになります。一方、NetworkPolicy オブジェクトが設定されていないテナント 2 は、データを収集できません。管理者はデフォルトでは内部のテナントを監視していませんでした。その代わりに BANP を作成し、テナントが NetworkPolicy オブジェクトを使用して BANP のデフォルト動作をオーバーライドできるようにしました。

2.3. ANP と BANP の監視
リンクのコピー

AdminNetworkPolicy および BaselineAdminNetworkPolicy リソースには、ポリシーの監視と管理に使用できるメトリクスがあります。メトリクスの詳細は、以下の表を参照してください。

2.3.1. AdminNetworkPolicy のメトリクス
リンクのコピー

Expand
名前説明詳細

ovnkube_controller_admin_network_policies

該当なし

クラスター内の AdminNetworkPolicy リソースの合計数。

ovnkube_controller_baseline_admin_network_policies

該当なし

クラスター内の BaselineAdminNetworkPolicy リソースの合計数。値は 0 または 1 になります。

ovnkube_controller_admin_network_policies_rules

  • direction: Ingress または Egress のいずれかを指定します。
  • action: Pass、Allow、または Deny のいずれかを指定します。

direction と action 別にグループ化された、クラスター内の全 ANP ポリシーにわたるルールの合計数。

ovnkube_controller_baseline_admin_network_policies_rules

  • direction: Ingress または Egress のいずれかを指定します。
  • action: Allow または Deny のいずれかを指定します。

direction と action 別にグループ化された、クラスター内の全 BANP ポリシーにわたるルールの合計数。

ovnkube_controller_admin_network_policies_db_objects

table_name: ACL または Address_Set のいずれかを指定します

table_name でグループ化されたクラスター内の全 ANP によって作成された OVN Northbound データベース (nbdb) オブジェクトの合計数。

ovnkube_controller_baseline_admin_network_policies_db_objects

table_name: ACL または Address_Set のいずれかを指定します

table_name でグループ化されたクラスター内の全 BANP によって作成された OVN Northbound データベース (nbdb) オブジェクトの合計数。

2.4. AdminNetworkPolicy の Egress ノードとネットワークピア
リンクのコピー

このセクションでは、nodes と networks のピアを説明します。管理者は、このセクションの例を使用して、クラスター内のノースバウンドトラフィックを制御するための AdminNetworkPolicy と BaselineAdminNetworkPolicy を設計できます。

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 ルールに対してのみ指定できます。

2.4.1.1. ノードピアを使用してクラスターノードへの Egress トラフィックを制御する
リンクのコピー

nodes ピアを使用すると、管理者は Pod からクラスター内のノードへの Egress トラフィックを制御できます。この利点は、クラスターにノードを追加したり、クラスターからノードを削除したりするときにポリシーを変更する必要がないことです。

次の例では、ノードセレクターピアを使用して、restricted、confidential、または internal レベルのセキュリティーを持つ任意の namespace によるポート 6443 上の Kubernetes API サーバーへの Egress トラフィックを許可します。また、セキュリティーレベルが restricted、confidential、または internal のいずれかである namespace からクラスター内のすべてのワーカーノードへのトラフィックも拒否します。

例2.8 nodes ピアを使用した ANP Allow Egress の例

apiVersion: policy.networking.k8s.io/v1alpha1
kind: AdminNetworkPolicy
metadata:
  name: egress-security-allow
spec:
  egress:
  - action: Deny
    to:
    - nodes:
        matchExpressions:
        - key: node-role.kubernetes.io/worker
          operator: Exists
  - action: Allow
    name: allow-to-kubernetes-api-server-and-engr-dept-pods
    ports:
    - portNumber:
        port: 6443
        protocol: TCP
    to:
    - nodes:
1 

        matchExpressions:
        - key: node-role.kubernetes.io/control-plane
          operator: Exists
    - pods:
2 

        namespaceSelector:
          matchLabels:
            dept: engr
        podSelector: {}
  priority: 55
  subject:
3 

    namespaces:
      matchExpressions:
      - key: security
4 

        operator: In
        values:
        - restricted
        - confidential
        - internal
1
matchExpressions フィールドを使用して、クラスター内のノードまたはノードセットを指定します。
2
dept: engr のラベルが付けられたすべての Pod を指定します。
3
ネットワークポリシーで使用されるラベルに一致する namespace を含む ANP のサブジェクトを指定します。この例は、security レベルが restricted、confidential、または internal である namespace のいずれかに一致します。
4
matchExpressions フィールドのキー/値のペアを指定します。
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 ルールを設定する必要があります。

例2.9 networks ピアを使用した ANP と BANP の例

apiVersion: policy.networking.k8s.io/v1alpha1
kind: AdminNetworkPolicy
metadata:
  name: network-as-egress-peer
spec:
  priority: 70
  subject:
    namespaces: {} # Use the empty selector with caution because it also selects OpenShift namespaces as well.
  egress:
  - name: "deny-egress-to-external-dns-servers"
    action: "Deny"
    to:
    - networks:
1 

      - 8.8.8.8/32
      - 8.8.4.4/32
      - 208.67.222.222/32
    ports:
      - portNumber:
          protocol: UDP
          port: 53
  - name: "allow-all-egress-to-intranet"
    action: "Allow"
    to:
    - networks:
2 

      - 89.246.180.0/22
      - 60.45.72.0/22
  - name: "allow-all-intra-cluster-traffic"
    action: "Allow"
    to:
    - namespaces: {} # Use the empty selector with caution because it also selects OpenShift namespaces as well.
  - name: "pass-all-egress-to-internet"
    action: "Pass"
    to:
    - networks:
      - 0.0.0.0/0
3 

---
apiVersion: policy.networking.k8s.io/v1alpha1
kind: BaselineAdminNetworkPolicy
metadata:
  name: default
spec:
  subject:
    namespaces: {} # Use the empty selector with caution because it also selects OpenShift namespaces as well.
  egress:
  - name: "deny-all-egress-to-internet"
    action: "Deny"
    to:
    - networks:
      - 0.0.0.0/0
4 

---
1
networks を使用して、クラスター外の CIDR ネットワークの範囲を指定します。
2
リソースからのクラスター内トラフィックの CIDR 範囲を指定します。
3 4
networks 値を 0.0.0.0/0 に設定して、すべてに対して Deny Egress を指定します。Deny を 0.0.0.0/0 に設定する前に、必要な宛先に対して優先度の高い Allow ルールが設定されていることを確認してください。これにより、Kubernetes API および DNS サーバーを含むすべてのトラフィックが拒否されます。

network-as-egress-peer ANP と、networks ピアを使用する default の BANP を組み合わせると、次の Egress ポリシーが適用されます。

  • すべての Pod が、リストされた IP アドレスの外部 DNS サーバーと通信できない。
  • すべての Pod が、会社のイントラネットの残りの部分と通信できる。
  • すべての Pod が、他の Pod、ノード、およびサービスと通信できる。
  • どの Pod もインターネットと通信できない。最後の ANP Pass ルールと強力な BANP Deny ルールを組み合わせることで、クラスター内のトラフィックを保護するガードレールポリシーが作成されます。
2.4.1.3. ノードピアとネットワークピアを一緒に使用する
リンクのコピー

クラスター管理者は、ANP および BANP ポリシーで nodes と networks ピアを組み合わせることができます。

例2.10 nodes と networks ピアの例

apiVersion: policy.networking.k8s.io/v1alpha1
kind: AdminNetworkPolicy
metadata:
  name: egress-peer-1
1 

spec:
  egress:
2 

  - action: "Allow"
    name: "allow-egress"
    to:
    - nodes:
        matchExpressions:
        - key: worker-group
          operator: In
          values:
          - workloads # Egress traffic from nodes with label worker-group: workloads is allowed.
    - networks:
      - 104.154.164.170/32
    - pods:
        namespaceSelector:
          matchLabels:
            apps: external-apps
        podSelector:
          matchLabels:
            app: web # This rule in the policy allows the traffic directed to pods labeled apps: web in projects with apps: external-apps to leave the cluster.
  - action: "Deny"
    name: "deny-egress"
    to:
    - nodes:
        matchExpressions:
        - key: worker-group
          operator: In
          values:
          - infra # Egress traffic from nodes with label worker-group: infra is denied.
    - networks:
      - 104.154.164.160/32 # Egress traffic to this IP address from cluster is denied.
    - pods:
        namespaceSelector:
          matchLabels:
            apps: internal-apps
        podSelector: {}
  - action: "Pass"
    name: "pass-egress"
    to:
    - nodes:
        matchExpressions:
        - key: node-role.kubernetes.io/worker
          operator: Exists # All other egress traffic is passed to NetworkPolicy or BANP for evaluation.
  priority: 30
3 

  subject:
4 

    namespaces:
      matchLabels:
        apps: all-apps
1
ポリシーの名前を指定します。
2
nodes および networks ピアの場合、egress として ANP のノースバウンドトラフィック制御のみを使用できます。
3
ANP の優先順位を指定して、評価する順序を決定します。優先度の低いルールの方が優先順位が高くなります。ANP は 0 - 99 の値を受け入れます。0 が最高の優先度、99 が最低の優先度です。
4
ポリシーのルールを適用するクラスター内の Pod のセットを指定します。この例では、すべての namespace における、apps: all-apps ラベルを持つすべての Pod がポリシーの subject になります。

2.5. AdminNetworkPolicy のトラブルシューティング
リンクのコピー

2.5.1. ANP の作成の確認
リンクのコピー

AdminNetworkPolicy (ANP) と BaselineAdminNetworkPolicy (BANP) が正しく作成されていることを確認するには、oc describe anp または oc describe banp のコマンドのステータス出力を確認します。

ステータスが良好な場合は、OVN DB plumbing was successful および SetupSucceeded と表示されます。

例2.11 正常なステータスの ANP の例

...
Conditions:
Last Transition Time:  2024-06-08T20:29:00Z
Message:               Setting up OVN DB plumbing was successful
Reason:                SetupSucceeded
Status:                True
Type:                  Ready-In-Zone-ovn-control-plane Last Transition Time:  2024-06-08T20:29:00Z
Message:               Setting up OVN DB plumbing was successful
Reason:                SetupSucceeded
Status:                True
Type:                  Ready-In-Zone-ovn-worker
Last Transition Time:  2024-06-08T20:29:00Z
Message:               Setting up OVN DB plumbing was successful
Reason:                SetupSucceeded
Status:                True
Type:                  Ready-In-Zone-ovn-worker2
...

設定が失敗した場合、それぞれのゾーンコントローラーからエラーが報告されます。

例2.12 不正なステータスとエラーメッセージを含む ANP の例

...
Status:
  Conditions:
    Last Transition Time:  2024-06-25T12:47:44Z
    Message:               error attempting to add ANP cluster-control with priority 600 because, OVNK only supports priority ranges 0-99
    Reason:                SetupFailed
    Status:                False
    Type:                  Ready-In-Zone-example-worker-1.example.example-org.net
    Last Transition Time:  2024-06-25T12:47:45Z
    Message:               error attempting to add ANP cluster-control with priority 600 because, OVNK only supports priority ranges 0-99
    Reason:                SetupFailed
    Status:                False
    Type:                  Ready-In-Zone-example-worker-0.example.example-org.net
    Last Transition Time:  2024-06-25T12:47:44Z
    Message:               error attempting to add ANP cluster-control with priority 600 because, OVNK only supports priority ranges 0-99
    Reason:                SetupFailed
    Status:                False
    Type:                  Ready-In-Zone-example-ctlplane-1.example.example-org.net
    Last Transition Time:  2024-06-25T12:47:44Z
    Message:               error attempting to add ANP cluster-control with priority 600 because, OVNK only supports priority ranges 0-99
    Reason:                SetupFailed
    Status:                False
    Type:                  Ready-In-Zone-example-ctlplane-2.example.example-org.net
    Last Transition Time:  2024-06-25T12:47:44Z
    Message:               error attempting to add ANP cluster-control with priority 600 because, OVNK only supports priority ranges 0-99
    Reason:                SetupFailed
    Status:                False
    Type:                  Ready-In-Zone-example-ctlplane-0.example.example-org.net
    ```

失敗したポリシーのトラブルシューティングに役立つ nbctl コマンドは、次のセクションを参照してください。

2.5.1.1. ANP および BANP への nbctl コマンドの使用
リンクのコピー

失敗したセットアップのトラブルシューティングを行うには、まず ACL、AdressSet、Port_Group などの OVN Northbound データベース (nbdb) オブジェクトを確認します。nbdb を表示するには、そのノードの Pod 内にいて、そのノードのデータベース内のオブジェクトを表示する必要があります。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。
注記

クラスターで ovn nbctl コマンドを実行するには、関連するノード上の `nbdb` にリモートシェルを起動する必要があります。

出力を生成するために次のポリシーが使用されました。

例2.13 出力の生成に使用される AdminNetworkPolicy

apiVersion: policy.networking.k8s.io/v1alpha1
kind: AdminNetworkPolicy
metadata:
  name: cluster-control
spec:
  priority: 34
  subject:
    namespaces:
      matchLabels:
        anp: cluster-control-anp # Only namespaces with this label have this ANP
  ingress:
  - name: "allow-from-ingress-router" # rule0
    action: "Allow"
    from:
    - namespaces:
        matchLabels:
          policy-group.network.openshift.io/ingress: ""
  - name: "allow-from-monitoring" # rule1
    action: "Allow"
    from:
    - namespaces:
        matchLabels:
          kubernetes.io/metadata.name: openshift-monitoring
    ports:
    - portNumber:
        protocol: TCP
        port: 7564
    - namedPort: "scrape"
  - name: "allow-from-open-tenants" # rule2
    action: "Allow"
    from:
    - namespaces: # open tenants
        matchLabels:
          tenant: open
  - name: "pass-from-restricted-tenants" # rule3
    action: "Pass"
    from:
    - namespaces: # restricted tenants
        matchLabels:
          tenant: restricted
  - name: "default-deny" # rule4
    action: "Deny"
    from:
    - namespaces: {} # Use the empty selector with caution because it also selects OpenShift namespaces as well.
  egress:
  - name: "allow-to-dns" # rule0
    action: "Allow"
    to:
    - pods:
        namespaceSelector:
          matchLabels:
            kubernetes.io/metadata.name: openshift-dns
        podSelector:
          matchLabels:
            app: dns
    ports:
    - portNumber:
        protocol: UDP
        port: 5353
  - name: "allow-to-kapi-server" # rule1
    action: "Allow"
    to:
    - nodes:
        matchExpressions:
        - key: node-role.kubernetes.io/control-plane
          operator: Exists
    ports:
    - portNumber:
        protocol: TCP
        port: 6443
  - name: "allow-to-splunk" # rule2
    action: "Allow"
    to:
    - namespaces:
        matchLabels:
          tenant: splunk
    ports:
    - portNumber:
        protocol: TCP
        port: 8991
    - portNumber:
        protocol: TCP
        port: 8992
  - name: "allow-to-open-tenants-and-intranet-and-worker-nodes" # rule3
    action: "Allow"
    to:
    - nodes: # worker-nodes
        matchExpressions:
        - key: node-role.kubernetes.io/worker
          operator: Exists
    - networks: # intranet
      - 172.29.0.0/30
      - 10.0.54.0/19
      - 10.0.56.38/32
      - 10.0.69.0/24
    - namespaces: # open tenants
        matchLabels:
          tenant: open
  - name: "pass-to-restricted-tenants" # rule4
    action: "Pass"
    to:
    - namespaces: # restricted tenants
        matchLabels:
          tenant: restricted
  - name: "default-deny"
    action: "Deny"
    to:
    - networks:
      - 0.0.0.0/0

手順

  1. 次のコマンドを実行して、ノード情報を含む Pod をリスト表示します。 

    $ oc get pods -n openshift-ovn-kubernetes -owide

    出力例

    NAME                                     READY   STATUS    RESTARTS   AGE   IP           NODE                                       NOMINATED NODE   READINESS GATES
ovnkube-control-plane-5c95487779-8k9fd   2/2     Running   0          34m   10.0.0.5     ci-ln-0tv5gg2-72292-6sjw5-master-0         <none>           <none>
ovnkube-control-plane-5c95487779-v2xn8   2/2     Running   0          34m   10.0.0.3     ci-ln-0tv5gg2-72292-6sjw5-master-1         <none>           <none>
ovnkube-node-524dt                       8/8     Running   0          33m   10.0.0.4     ci-ln-0tv5gg2-72292-6sjw5-master-2         <none>           <none>
ovnkube-node-gbwr9                       8/8     Running   0          24m   10.0.128.4   ci-ln-0tv5gg2-72292-6sjw5-worker-c-s9gqt   <none>           <none>
ovnkube-node-h4fpx                       8/8     Running   0          33m   10.0.0.5     ci-ln-0tv5gg2-72292-6sjw5-master-0         <none>           <none>
ovnkube-node-j4hzw                       8/8     Running   0          24m   10.0.128.2   ci-ln-0tv5gg2-72292-6sjw5-worker-a-hzbh5   <none>           <none>
ovnkube-node-wdhgv                       8/8     Running   0          33m   10.0.0.3     ci-ln-0tv5gg2-72292-6sjw5-master-1         <none>           <none>
ovnkube-node-wfncn                       8/8     Running   0          24m   10.0.128.3   ci-ln-0tv5gg2-72292-6sjw5-worker-b-5bb7f   <none>           <none>

  2. 次のコマンドを実行して、Pod に移動してノースバウンドデータベースを確認します。 

    $ oc rsh -c nbdb -n openshift-ovn-kubernetes ovnkube-node-524dt

  3. ACL nbdb を確認するには、次のコマンドを実行します。 

    $ ovn-nbctl find ACL 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,"k8s.ovn.org/name"=cluster-control}'
    詳細は以下のようになります。, cluster-control
    トラブルシューティングする AdminNetworkPolicy の名前を指定します。
    AdminNetworkPolicy
    AdminNetworkPolicy または BaselineAdminNetworkPolicy のタイプを指定します。

    例2.14 ACL の出力例

    _uuid               : 0d5e4722-b608-4bb1-b625-23c323cc9926
action              : allow-related
direction           : to-lport
external_ids        : {direction=Ingress, gress-index="2", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Ingress:2:None", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=None}
label               : 0
log                 : false
match               : "outport == @a14645450421485494999 && ((ip4.src == $a13730899355151937870))"
meter               : acl-logging
name                : "ANP:cluster-control:Ingress:2"
options             : {}
priority            : 26598
severity            : []
tier                : 1

_uuid               : b7be6472-df67-439c-8c9c-f55929f0a6e0
action              : drop
direction           : from-lport
external_ids        : {direction=Egress, gress-index="5", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:5:None", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=None}
label               : 0
log                 : false
match               : "inport == @a14645450421485494999 && ((ip4.dst == $a11452480169090787059))"
meter               : acl-logging
name                : "ANP:cluster-control:Egress:5"
options             : {apply-after-lb="true"}
priority            : 26595
severity            : []
tier                : 1

_uuid               : 5a6e5bb4-36eb-4209-b8bc-c611983d4624
action              : pass
direction           : to-lport
external_ids        : {direction=Ingress, gress-index="3", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Ingress:3:None", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=None}
label               : 0
log                 : false
match               : "outport == @a14645450421485494999 && ((ip4.src == $a764182844364804195))"
meter               : acl-logging
name                : "ANP:cluster-control:Ingress:3"
options             : {}
priority            : 26597
severity            : []
tier                : 1

_uuid               : 04f20275-c410-405c-a923-0e677f767889
action              : pass
direction           : from-lport
external_ids        : {direction=Egress, gress-index="4", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:4:None", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=None}
label               : 0
log                 : false
match               : "inport == @a14645450421485494999 && ((ip4.dst == $a5972452606168369118))"
meter               : acl-logging
name                : "ANP:cluster-control:Egress:4"
options             : {apply-after-lb="true"}
priority            : 26596
severity            : []
tier                : 1

_uuid               : 4b5d836a-e0a3-4088-825e-f9f0ca58e538
action              : drop
direction           : to-lport
external_ids        : {direction=Ingress, gress-index="4", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Ingress:4:None", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=None}
label               : 0
log                 : false
match               : "outport == @a14645450421485494999 && ((ip4.src == $a13814616246365836720))"
meter               : acl-logging
name                : "ANP:cluster-control:Ingress:4"
options             : {}
priority            : 26596
severity            : []
tier                : 1

_uuid               : 5d09957d-d2cc-4f5a-9ddd-b97d9d772023
action              : allow-related
direction           : from-lport
external_ids        : {direction=Egress, gress-index="2", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:2:tcp", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=tcp}
label               : 0
log                 : false
match               : "inport == @a14645450421485494999 && ((ip4.dst == $a18396736153283155648)) && tcp && tcp.dst=={8991,8992}"
meter               : acl-logging
name                : "ANP:cluster-control:Egress:2"
options             : {apply-after-lb="true"}
priority            : 26598
severity            : []
tier                : 1

_uuid               : 1a68a5ed-e7f9-47d0-b55c-89184d97e81a
action              : allow-related
direction           : from-lport
external_ids        : {direction=Egress, gress-index="1", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:1:tcp", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=tcp}
label               : 0
log                 : false
match               : "inport == @a14645450421485494999 && ((ip4.dst == $a10706246167277696183)) && tcp && tcp.dst==6443"
meter               : acl-logging
name                : "ANP:cluster-control:Egress:1"
options             : {apply-after-lb="true"}
priority            : 26599
severity            : []
tier                : 1

_uuid               : aa1a224d-7960-4952-bdfb-35246bafbac8
action              : allow-related
direction           : to-lport
external_ids        : {direction=Ingress, gress-index="1", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Ingress:1:tcp", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=tcp}
label               : 0
log                 : false
match               : "outport == @a14645450421485494999 && ((ip4.src == $a6786643370959569281)) && tcp && tcp.dst==7564"
meter               : acl-logging
name                : "ANP:cluster-control:Ingress:1"
options             : {}
priority            : 26599
severity            : []
tier                : 1

_uuid               : 1a27d30e-3f96-4915-8ddd-ade7f22c117b
action              : allow-related
direction           : from-lport
external_ids        : {direction=Egress, gress-index="3", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:3:None", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=None}
label               : 0
log                 : false
match               : "inport == @a14645450421485494999 && ((ip4.dst == $a10622494091691694581))"
meter               : acl-logging
name                : "ANP:cluster-control:Egress:3"
options             : {apply-after-lb="true"}
priority            : 26597
severity            : []
tier                : 1

_uuid               : b23a087f-08f8-4225-8c27-4a9a9ee0c407
action              : allow-related
direction           : from-lport
external_ids        : {direction=Egress, gress-index="0", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:0:udp", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=udp}
label               : 0
log                 : false
match               : "inport == @a14645450421485494999 && ((ip4.dst == $a13517855690389298082)) && udp && udp.dst==5353"
meter               : acl-logging
name                : "ANP:cluster-control:Egress:0"
options             : {apply-after-lb="true"}
priority            : 26600
severity            : []
tier                : 1

_uuid               : d14ed5cf-2e06-496e-8cae-6b76d5dd5ccd
action              : allow-related
direction           : to-lport
external_ids        : {direction=Ingress, gress-index="0", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Ingress:0:None", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=None}
label               : 0
log                 : false
match               : "outport == @a14645450421485494999 && ((ip4.src == $a14545668191619617708))"
meter               : acl-logging
name                : "ANP:cluster-control:Ingress:0"
options             : {}
priority            : 26600
severity            : []
tier                : 1
    注記

    Ingress および Egress の出力には、ACL のポリシーのロジックが表示されます。たとえば、パケットが指定された match と一致するたびに action が実行されます。

    1. 次のコマンドを実行して、ルールの特定の ACL を調べます。 

      $ ovn-nbctl find ACL 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,direction=Ingress,"k8s.ovn.org/name"=cluster-control,gress-index="1"}'
      詳細は以下のようになります。, cluster-control
      ANP の name を指定します。
      Ingress
      トラフィックの direction を Ingress または Egress のいずれかのタイプで指定します。
      1
      確認するルールを指定します。

      priority 34 の cluster-control という名前の ANP の例では、Ingress rule 1 の出力例は次のとおりです。

      例2.15 出力例

      _uuid               : aa1a224d-7960-4952-bdfb-35246bafbac8
action              : allow-related
direction           : to-lport
external_ids        : {direction=Ingress, gress-index="1", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Ingress:1:tcp", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=tcp}
label               : 0
log                 : false
match               : "outport == @a14645450421485494999 && ((ip4.src == $a6786643370959569281)) && tcp && tcp.dst==7564"
meter               : acl-logging
name                : "ANP:cluster-control:Ingress:1"
options             : {}
priority            : 26599
severity            : []
tier                : 1

  4. nbdb 内のアドレスセットを確認するには、次のコマンドを実行します。 

    $ ovn-nbctl find Address_Set 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,"k8s.ovn.org/name"=cluster-control}'

    例2.16 Address_Set の出力例

    _uuid               : 56e89601-5552-4238-9fc3-8833f5494869
addresses           : ["192.168.194.135", "192.168.194.152", "192.168.194.193", "192.168.194.254"]
external_ids        : {direction=Egress, gress-index="1", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:1:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a10706246167277696183

_uuid               : 7df9330d-380b-4bdb-8acd-4eddeda2419c
addresses           : ["10.132.0.10", "10.132.0.11", "10.132.0.12", "10.132.0.13", "10.132.0.14", "10.132.0.15", "10.132.0.16", "10.132.0.17", "10.132.0.5", "10.132.0.7", "10.132.0.71", "10.132.0.75", "10.132.0.8", "10.132.0.81", "10.132.0.9", "10.132.2.10", "10.132.2.11", "10.132.2.12", "10.132.2.14", "10.132.2.15", "10.132.2.3", "10.132.2.4", "10.132.2.5", "10.132.2.6", "10.132.2.7", "10.132.2.8", "10.132.2.9", "10.132.3.64", "10.132.3.65", "10.132.3.72", "10.132.3.73", "10.132.3.76", "10.133.0.10", "10.133.0.11", "10.133.0.12", "10.133.0.13", "10.133.0.14", "10.133.0.15", "10.133.0.16", "10.133.0.17", "10.133.0.18", "10.133.0.19", "10.133.0.20", "10.133.0.21", "10.133.0.22", "10.133.0.23", "10.133.0.24", "10.133.0.25", "10.133.0.26", "10.133.0.27", "10.133.0.28", "10.133.0.29", "10.133.0.30", "10.133.0.31", "10.133.0.32", "10.133.0.33", "10.133.0.34", "10.133.0.35", "10.133.0.36", "10.133.0.37", "10.133.0.38", "10.133.0.39", "10.133.0.40", "10.133.0.41", "10.133.0.42", "10.133.0.44", "10.133.0.45", "10.133.0.46", "10.133.0.47", "10.133.0.48", "10.133.0.5", "10.133.0.6", "10.133.0.7", "10.133.0.8", "10.133.0.9", "10.134.0.10", "10.134.0.11", "10.134.0.12", "10.134.0.13", "10.134.0.14", "10.134.0.15", "10.134.0.16", "10.134.0.17", "10.134.0.18", "10.134.0.19", "10.134.0.20", "10.134.0.21", "10.134.0.22", "10.134.0.23", "10.134.0.24", "10.134.0.25", "10.134.0.26", "10.134.0.27", "10.134.0.28", "10.134.0.30", "10.134.0.31", "10.134.0.32", "10.134.0.33", "10.134.0.34", "10.134.0.35", "10.134.0.36", "10.134.0.37", "10.134.0.38", "10.134.0.4", "10.134.0.42", "10.134.0.9", "10.135.0.10", "10.135.0.11", "10.135.0.12", "10.135.0.13", "10.135.0.14", "10.135.0.15", "10.135.0.16", "10.135.0.17", "10.135.0.18", "10.135.0.19", "10.135.0.23", "10.135.0.24", "10.135.0.26", "10.135.0.27", "10.135.0.29", "10.135.0.3", "10.135.0.4", "10.135.0.40", "10.135.0.41", "10.135.0.42", "10.135.0.43", "10.135.0.44", "10.135.0.5", "10.135.0.6", "10.135.0.7", "10.135.0.8", "10.135.0.9"]
external_ids        : {direction=Ingress, gress-index="4", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Ingress:4:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a13814616246365836720

_uuid               : 84d76f13-ad95-4c00-8329-a0b1d023c289
addresses           : ["10.132.3.76", "10.135.0.44"]
external_ids        : {direction=Egress, gress-index="4", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:4:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a5972452606168369118

_uuid               : 0c53e917-f7ee-4256-8f3a-9522c0481e52
addresses           : ["10.132.0.10", "10.132.0.11", "10.132.0.12", "10.132.0.13", "10.132.0.14", "10.132.0.15", "10.132.0.16", "10.132.0.17", "10.132.0.5", "10.132.0.7", "10.132.0.71", "10.132.0.75", "10.132.0.8", "10.132.0.81", "10.132.0.9", "10.132.2.10", "10.132.2.11", "10.132.2.12", "10.132.2.14", "10.132.2.15", "10.132.2.3", "10.132.2.4", "10.132.2.5", "10.132.2.6", "10.132.2.7", "10.132.2.8", "10.132.2.9", "10.132.3.64", "10.132.3.65", "10.132.3.72", "10.132.3.73", "10.132.3.76", "10.133.0.10", "10.133.0.11", "10.133.0.12", "10.133.0.13", "10.133.0.14", "10.133.0.15", "10.133.0.16", "10.133.0.17", "10.133.0.18", "10.133.0.19", "10.133.0.20", "10.133.0.21", "10.133.0.22", "10.133.0.23", "10.133.0.24", "10.133.0.25", "10.133.0.26", "10.133.0.27", "10.133.0.28", "10.133.0.29", "10.133.0.30", "10.133.0.31", "10.133.0.32", "10.133.0.33", "10.133.0.34", "10.133.0.35", "10.133.0.36", "10.133.0.37", "10.133.0.38", "10.133.0.39", "10.133.0.40", "10.133.0.41", "10.133.0.42", "10.133.0.44", "10.133.0.45", "10.133.0.46", "10.133.0.47", "10.133.0.48", "10.133.0.5", "10.133.0.6", "10.133.0.7", "10.133.0.8", "10.133.0.9", "10.134.0.10", "10.134.0.11", "10.134.0.12", "10.134.0.13", "10.134.0.14", "10.134.0.15", "10.134.0.16", "10.134.0.17", "10.134.0.18", "10.134.0.19", "10.134.0.20", "10.134.0.21", "10.134.0.22", "10.134.0.23", "10.134.0.24", "10.134.0.25", "10.134.0.26", "10.134.0.27", "10.134.0.28", "10.134.0.30", "10.134.0.31", "10.134.0.32", "10.134.0.33", "10.134.0.34", "10.134.0.35", "10.134.0.36", "10.134.0.37", "10.134.0.38", "10.134.0.4", "10.134.0.42", "10.134.0.9", "10.135.0.10", "10.135.0.11", "10.135.0.12", "10.135.0.13", "10.135.0.14", "10.135.0.15", "10.135.0.16", "10.135.0.17", "10.135.0.18", "10.135.0.19", "10.135.0.23", "10.135.0.24", "10.135.0.26", "10.135.0.27", "10.135.0.29", "10.135.0.3", "10.135.0.4", "10.135.0.40", "10.135.0.41", "10.135.0.42", "10.135.0.43", "10.135.0.44", "10.135.0.5", "10.135.0.6", "10.135.0.7", "10.135.0.8", "10.135.0.9"]
external_ids        : {direction=Egress, gress-index="2", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:2:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a18396736153283155648

_uuid               : 5228bf1b-dfd8-40ec-bfa8-95c5bf9aded9
addresses           : []
external_ids        : {direction=Ingress, gress-index="0", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Ingress:0:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a14545668191619617708

_uuid               : 46530d69-70da-4558-8c63-884ec9dc4f25
addresses           : ["10.132.2.10", "10.132.2.5", "10.132.2.6", "10.132.2.7", "10.132.2.8", "10.132.2.9", "10.133.0.47", "10.134.0.33", "10.135.0.10", "10.135.0.11", "10.135.0.12", "10.135.0.19", "10.135.0.24", "10.135.0.7", "10.135.0.8", "10.135.0.9"]
external_ids        : {direction=Ingress, gress-index="1", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Ingress:1:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a6786643370959569281

_uuid               : 65fdcdea-0b9f-4318-9884-1b51d231ad1d
addresses           : ["10.132.3.72", "10.135.0.42"]
external_ids        : {direction=Ingress, gress-index="2", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Ingress:2:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a13730899355151937870

_uuid               : 73eabdb0-36bf-4ca3-b66d-156ac710df4c
addresses           : ["10.0.32.0/19", "10.0.56.38/32", "10.0.69.0/24", "10.132.3.72", "10.135.0.42", "172.29.0.0/30", "192.168.194.103", "192.168.194.2"]
external_ids        : {direction=Egress, gress-index="3", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:3:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a10622494091691694581

_uuid               : 50cdbef2-71b5-474b-914c-6fcd1d7712d3
addresses           : ["10.132.0.10", "10.132.0.11", "10.132.0.12", "10.132.0.13", "10.132.0.14", "10.132.0.15", "10.132.0.16", "10.132.0.17", "10.132.0.5", "10.132.0.7", "10.132.0.71", "10.132.0.75", "10.132.0.8", "10.132.0.81", "10.132.0.9", "10.132.2.10", "10.132.2.11", "10.132.2.12", "10.132.2.14", "10.132.2.15", "10.132.2.3", "10.132.2.4", "10.132.2.5", "10.132.2.6", "10.132.2.7", "10.132.2.8", "10.132.2.9", "10.132.3.64", "10.132.3.65", "10.132.3.72", "10.132.3.73", "10.132.3.76", "10.133.0.10", "10.133.0.11", "10.133.0.12", "10.133.0.13", "10.133.0.14", "10.133.0.15", "10.133.0.16", "10.133.0.17", "10.133.0.18", "10.133.0.19", "10.133.0.20", "10.133.0.21", "10.133.0.22", "10.133.0.23", "10.133.0.24", "10.133.0.25", "10.133.0.26", "10.133.0.27", "10.133.0.28", "10.133.0.29", "10.133.0.30", "10.133.0.31", "10.133.0.32", "10.133.0.33", "10.133.0.34", "10.133.0.35", "10.133.0.36", "10.133.0.37", "10.133.0.38", "10.133.0.39", "10.133.0.40", "10.133.0.41", "10.133.0.42", "10.133.0.44", "10.133.0.45", "10.133.0.46", "10.133.0.47", "10.133.0.48", "10.133.0.5", "10.133.0.6", "10.133.0.7", "10.133.0.8", "10.133.0.9", "10.134.0.10", "10.134.0.11", "10.134.0.12", "10.134.0.13", "10.134.0.14", "10.134.0.15", "10.134.0.16", "10.134.0.17", "10.134.0.18", "10.134.0.19", "10.134.0.20", "10.134.0.21", "10.134.0.22", "10.134.0.23", "10.134.0.24", "10.134.0.25", "10.134.0.26", "10.134.0.27", "10.134.0.28", "10.134.0.30", "10.134.0.31", "10.134.0.32", "10.134.0.33", "10.134.0.34", "10.134.0.35", "10.134.0.36", "10.134.0.37", "10.134.0.38", "10.134.0.4", "10.134.0.42", "10.134.0.9", "10.135.0.10", "10.135.0.11", "10.135.0.12", "10.135.0.13", "10.135.0.14", "10.135.0.15", "10.135.0.16", "10.135.0.17", "10.135.0.18", "10.135.0.19", "10.135.0.23", "10.135.0.24", "10.135.0.26", "10.135.0.27", "10.135.0.29", "10.135.0.3", "10.135.0.4", "10.135.0.40", "10.135.0.41", "10.135.0.42", "10.135.0.43", "10.135.0.44", "10.135.0.5", "10.135.0.6", "10.135.0.7", "10.135.0.8", "10.135.0.9"]
external_ids        : {direction=Egress, gress-index="0", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:0:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a13517855690389298082

_uuid               : 32a42f32-2d11-43dd-979d-a56d7ee6aa57
addresses           : ["10.132.3.76", "10.135.0.44"]
external_ids        : {direction=Ingress, gress-index="3", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Ingress:3:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a764182844364804195

_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

    1. 次のコマンドを実行して、ルールの特定のアドレスセットを調べます。 

      $ ovn-nbctl find Address_Set 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,direction=Egress,"k8s.ovn.org/name"=cluster-control,gress-index="5"}'

      例2.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

  5. 次のコマンドを実行して、nbdb 内のポートグループを確認します。 

    $ ovn-nbctl find Port_Group 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,"k8s.ovn.org/name"=cluster-control}'

    例2.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]

第3章 ネットワークポリシー
リンクのコピー

3.1. ネットワークポリシーについて
リンクのコピー

開発者は、クラスター内の Pod へのトラフィックを制限するネットワークポリシーを定義できます。

3.1.1. ネットワークポリシーについて
リンクのコピー

デフォルトで、プロジェクトのすべての Pod は他の Pod およびネットワークのエンドポイントからアクセスできます。プロジェクトで 1 つ以上の Pod を分離するには、そのプロジェクトで NetworkPolicy オブジェクトを作成し、許可する着信接続を指定します。プロジェクト管理者は独自のプロジェクト内で NetworkPolicy オブジェクトの作成および削除を実行できます。

Pod が 1 つ以上の NetworkPolicy オブジェクトのセレクターで一致する場合、Pod はそれらの 1 つ以上の NetworkPolicy オブジェクトで許可される接続のみを受け入れます。NetworkPolicy オブジェクトによって選択されていない Pod は完全にアクセス可能です。

ネットワークポリシーは、Transmission Control Protocol (TCP)、User Datagram Protocol (UDP)、Internet Control Message Protocol (ICMP)、および Stream Control Transmission Protocol (SCTP) プロトコルにのみ適用されます。他のプロトコルは影響を受けません。

警告
  • ネットワークポリシーは、ホストのネットワーク namespace には適用されません。ホストネットワークが有効にされている Pod はネットワークポリシールールによる影響を受けません。ただし、ホストネットワークを使用する Pod に接続する Pod は、ネットワークポリシールールの影響を受ける可能性があります。
  • podSelector フィールドを {} に設定せずに namespaceSelector フィールドを使用すると、hostNetwork Pod が含まれません。ネットワークポリシーの作成時に hostNetwork Pod をターゲットにするには、namespaceSelector フィールドで podSelector を {} に設定して使用する必要があります。
  • ネットワークポリシーは、ローカルホストまたは常駐ノードからのトラフィックをブロックすることはできません。

  • ネットワークポリシーを作成する際は、カスタムネームスペースまたはプロジェクトに network.openshift.io/policy-group: ingress ラベルを適用しないでください。このラベルは Operator が管理し、OpenShift Container Platform のネットワーク機能専用です。システムによって作成された名前空間では、これを変更してはいけません。

    このラベルを使用すると、断続的なネットワーク接続の切断、意図しないシステム NetworkPolicies リソースの適用、またはオペレーターが状態を調整しようとする際に設定のずれが発生する可能性があります。カスタムトラフィックグループを作成する場合は、必ず以下の手順に示すように、一意のユーザー定義ラベルを使用してください。

以下のサンプル NetworkPolicy オブジェクトは、複数の異なるシナリオをサポートすることを示しています。

  • すべてのトラフィックを拒否します。

    プロジェクトに deny by default (デフォルトで拒否) を実行させるには、すべての Pod に一致するが、トラフィックを一切許可しない NetworkPolicy オブジェクトを追加します。 

    kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: deny-by-default
spec:
  podSelector: {}
  ingress: []

  • OpenShift Container Platform Ingress Controller からの接続のみを許可します。

    プロジェクトで OpenShift Container Platform Ingress Controller からの接続のみを許可するには、以下の NetworkPolicy オブジェクトを追加します。 

    apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-openshift-ingress
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          policy-group.network.openshift.io/ingress: ""
  podSelector: {}
  policyTypes:
  - Ingress

  • プロジェクト内の Pod からの接続のみを受け入れます。

    重要

    同じ namespace 内の hostNetwork Pod からの Ingress 接続を許可するには、allow-from-hostnetwork ポリシーと allow-same-namespace ポリシーを一緒に適用する必要があります。

    Pod が同じプロジェクト内の他の Pod からの接続を受け入れるが、他のプロジェクトの 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.1.1. allow-from-router ネットワークポリシーの使用
リンクのコピー

次の NetworkPolicy を使用して、ルーターの設定に関係なく外部トラフィックを許可します。 

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-router
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          policy-group.network.openshift.io/ingress: ""
1 

  podSelector: {}
  policyTypes:
  - Ingress
1
policy-group.network.openshift.io/ingress:"" ラベルは OVN-Kubernetes をサポートします。
3.1.1.2. allow-from-hostnetwork ネットワークポリシーの使用
リンクのコピー

次の allow-from-hostnetwork NetworkPolicy オブジェクトを追加して、ホストネットワーク Pod からのトラフィックを転送します。 

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-hostnetwork
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          policy-group.network.openshift.io/host-network: ""
  podSelector: {}
  policyTypes:
  - Ingress

3.1.2. OVN-Kubernetes ネットワークプラグインによるネットワークポリシーの最適化
リンクのコピー

OVN-Kubernetes のネットワークポリシーを最適化してフロー数を削減し、必要な場合に外部 IP トラフィックを許可する方法を学びましょう。

ネットワークポリシーを設計する場合は、以下のガイドラインを参照してください。

  • 同じ 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 つのセレクターとして表現する場合に限り適用できます。セレクターが異なるラベルに基づいている場合、この最適化は適用できない可能性があります。その場合は、ネットワークポリシーの最適化に特化して新規ラベルをいくつか適用することを検討してください。

3.1.2.1. OVN-Kubernetes の NetworkPolicy CR と外部 IP
リンクのコピー

OVN-Kubernetes では、NetworkPolicy カスタムリソース (CR) によって厳密な分離ルールが適用されます。サービスが外部 IP を使用して公開されている場合、トラフィックを許可するように明示的に設定されていない限り、ネットワークポリシーによって他の namespace からのアクセスがブロックされる可能性があります。

namespace をまたいで外部 IP へのアクセスを許可するには、必要な namespace からの Ingress を明示的に許可し、指定されたサービスポートへのトラフィックが許可されるようにする NetworkPolicy CR を作成します。必要なポートへのトラフィックを許可しなければ、アクセスが制限される可能性があります。

出力例

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    annotations:
    name: <policy_name>
    namespace: openshift-ingress
  spec:
    ingress:
    - ports:
      - port: 80
        protocol: TCP
    - ports:
      - port: 443
        protocol: TCP
    - from:
      - namespaceSelector:
          matchLabels:
          kubernetes.io/metadata.name: <my_namespace>
    podSelector: {}
    policyTypes:
    - Ingress

ここでは、以下のようになります。

<policy_name>
ポリシーの名前を指定します。
<my_namespace>
ポリシーがデプロイされる namespace の名前を指定します。

詳細は、「ネットワークポリシーについて」を参照してください。

3.1.3. 次のステップ
リンクのコピー

3.2. ネットワークポリシーの作成
リンクのコピー

クラスター管理者は、namespace のネットワークポリシーを作成できます。

3.2.1. NetworkPolicy オブジェクトの例
リンクのコピー

以下は、NetworkPolicy オブジェクトの設定例に解説を付けたものです。 

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-27107
spec:
  podSelector:
    matchLabels:
      app: mongodb
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: app
    ports:
    - protocol: TCP
      port: 27017

ここでは、以下のようになります。

name
NetworkPolicy オブジェクトの名前。
spec.podSelector
ポリシーが適用される Pod を説明するセレクター。ポリシーオブジェクトは NetworkPolicy オブジェクトが定義されるプロジェクトの Pod のみを選択できます。
ingress.from.podSelector
ポリシーオブジェクトが入力トラフィックを許可する Pod に一致するセレクター。セレクターは、NetworkPolicy と同じ namespace にある Pod を照合して検索します。
ingress.ports
トラフィックを受け入れる 1 つ以上の宛先ポートのリスト。

3.2.2. CLI を使用したネットワークポリシーの作成
リンクのコピー

クラスターの namespace に許可される Ingress または Egress ネットワークトラフィックを記述する詳細なルールを定義するには、ネットワークポリシーを作成できます。

注記

cluster-admin ロールを持つユーザーでログインしている場合、クラスター内の namespace でネットワークポリシーを作成できます。

前提条件

  • クラスターが、mode: NetworkPolicy が設定された NetworkPolicy オブジェクトをサポートするネットワークプラグイン (OVN-Kubernetes ネットワークプラグインなど) を使用している。
  • OpenShift CLI (oc) がインストールされている。
  • あなたは 管理者権限 を持つユーザー特権でクラスターにログインしました。
  • ネットワークポリシーが適用される namespace で作業している。

手順

  1. ポリシールールを作成します。

    1. <policy_name>.yaml ファイルを作成します。 

      $ touch <policy_name>.yaml

      ここでは、以下のようになります。

      <policy_name>
      ネットワークポリシーファイル名を指定します。

    2. 作成したファイルにネットワークポリシーを定義します。次の例では、全 namespace 内の全 Pod からの Ingress トラフィックを拒否します。これは基本的なポリシーであり、他のネットワークポリシーの設定によって許可されたクロス Pod トラフィック以外のすべてのクロス Pod ネットワーキングをブロックします。 

      kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress: []

      次の設定例では、同じ namespace 内の全 Pod からの Ingress トラフィックを許可します。 

      kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-same-namespace
spec:
  podSelector:
  ingress:
  - from:
    - podSelector: {}
# ...

      次の例では、特定の namespace から 1 つの Pod への Ingress トラフィックを許可します。このポリシーは 、名前空間 y で実行されている Pod から、pod-a ラベルを持つ Pod へのトラフィックを許可します。 

      kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-traffic-pod
spec:
  podSelector:
   matchLabels:
      pod: pod-a
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
           kubernetes.io/metadata.name: namespace-y
# ...

      次の設定例では、サービスへのトラフィックを制限します。このポリシーを適用すると、app=bookstore と role=api の両方のラベルを持つすべての Pod に、app=bookstore というラベルを持つ Pod のみがアクセスできるようになります。この例では、アプリケーションは、ラベル app=bookstore および role=api でマークされた REST API サーバーである可能性があります。

      この設定例は、次のユースケースに対応しています。

      • サービスへのトラフィックを、それを使用する必要がある他のマイクロサービスのみに制限します。

      • データベースへの接続を制限して、それを使用するアプリケーションのみを許可します。 

        kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: api-allow
spec:
  podSelector:
    matchLabels:
      app: bookstore
      role: api
  ingress:
  - from:
      - podSelector:
          matchLabels:
            app: bookstore
# ...

  2. ネットワークポリシーオブジェクトを作成するには、以下のコマンドを入力します。正常に処理された場合、ポリシーオブジェクトの名前と 作成 ステータスが表示されます。 

    $ oc apply -f <policy_name>.yaml -n <namespace>

    ここでは、以下のようになります。

    <policy_name>
    ネットワークポリシーファイル名を指定します。
    <namespace>
    オプションのパラメーター。現在の namespace とは異なる namespace でオブジェクトを定義した場合、パラメーターは namespace を指定します。

    正常に処理された場合、ポリシーオブジェクトの名前と 作成 ステータスが表示されます。

    注記

    cluster-admin 権限で Web コンソールにログインする場合、YAML で、または Web コンソールのフォームから、クラスターの任意の namespace でネットワークポリシーを直接作成できます。

3.2.3. デフォルトの全拒否ネットワークポリシーの作成
リンクのコピー

デフォルトの全拒否ネットワークポリシーは、デプロイされた他のネットワークポリシーの設定によって許可されるネットワークトラフィックと、ホストネットワークを使用する Pod 間のトラフィック以外のすべての Pod 間ネットワークをブロックします。この手順では 、my-project 名前空間に デフォルトで拒否する ポリシーを適用することにより、強力な拒否ポリシーを強制します。

警告

トラフィック通信を許可する NetworkPolicy カスタムリソース (CR) を設定しない場合、以下のポリシーはクラスター全体で通信問題を引き起こす可能性があります。

前提条件

  • クラスターが、mode: NetworkPolicy が設定された NetworkPolicy オブジェクトをサポートするネットワークプラグイン (OVN-Kubernetes ネットワークプラグインなど) を使用している。
  • OpenShift CLI (oc) がインストールされている。
  • あなたは 管理者権限 を持つユーザー特権でクラスターにログインしました。
  • ネットワークポリシーが適用される namespace で作業している。

手順

  1. すべての namespace におけるすべての Pod からの Ingress を拒否する deny-by-default ポリシーを定義する次の YAML を作成します。YAML を deny-by-default.yaml ファイルに保存します。 

    kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: deny-by-default
  namespace: my-project
spec:
  podSelector: {}
  ingress: []

    ここでは、以下のようになります。

    namespace
    ポリシーをデプロイする namespace を指定します。たとえば、my-project という 名前空間。
    podSelector
    このフィールドが空の場合、設定はすべての Pod と一致します。したがって、このポリシーは my-project 名前空間内のすべての Pod に適用されます。
    ingress
    [] は、イングレス ルールが指定されていないことを示します。これにより、すべての Pod への受信トラフィックがドロップされます。

  2. 次のコマンドを入力して、ポリシーを適用します。正常に処理された場合、ポリシーオブジェクトの名前と 作成 ステータスが表示されます。 

    $ oc apply -f deny-by-default.yaml

3.2.4. 外部クライアントからのトラフィックを許可するネットワークポリシーの作成
リンクのコピー

deny-by-default ポリシーを設定すると、外部クライアントからラベル app=web を持つ Pod へのトラフィックを許可するポリシーの設定に進むことができます。

注記

cluster-admin ロールを持つユーザーでログインしている場合、クラスター内の namespace でネットワークポリシーを作成できます。

この手順に従って、パブリックインターネットから直接、またはロードバランサーを使用して Pod にアクセスすることにより、外部サービスを許可するポリシーを設定します。トラフィックは、ラベル app=web を持つ Pod にのみ許可されます。

前提条件

  • クラスターが、mode: NetworkPolicy が設定された NetworkPolicy オブジェクトをサポートするネットワークプラグイン (OVN-Kubernetes ネットワークプラグインなど) を使用している。
  • OpenShift CLI (oc) がインストールされている。
  • あなたは 管理者権限 を持つユーザー特権でクラスターにログインしました。
  • ネットワークポリシーが適用される namespace で作業している。

手順

  1. パブリックインターネットからのトラフィックが直接、またはロードバランサーを使用して Pod にアクセスできるようにするポリシーを作成します。YAML を web-allow-external.yaml ファイルに保存します。 

    kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
spec:
  policyTypes:
  - Ingress
  podSelector:
    matchLabels:
      app: web
  ingress:
    - {}

  2. 次のコマンドを入力して、ポリシーを適用します。正常に処理された場合、ポリシーオブジェクトの名前と 作成 ステータスが表示されます。 

    $ oc apply -f web-allow-external.yaml

    このポリシーは、次の図に示すように、外部トラフィックを含むすべてのリソースからのトラフィックを許可します。

    外部クライアントからのトラフィックを許可する

全 namespace 内の全 Pod から特定のアプリケーションへのトラフィックを許可するポリシーを設定できます。

注記

cluster-admin ロールを持つユーザーでログインしている場合、クラスター内の namespace でネットワークポリシーを作成できます。

前提条件

  • クラスターが、mode: NetworkPolicy が設定された NetworkPolicy オブジェクトをサポートするネットワークプラグイン (OVN-Kubernetes ネットワークプラグインなど) を使用している。
  • OpenShift CLI (oc) がインストールされている。
  • あなたは 管理者権限 を持つユーザー特権でクラスターにログインしました。
  • ネットワークポリシーが適用される namespace で作業している。

手順

  1. すべての namespace のすべての Pod から特定のアプリケーションへのトラフィックを許可するポリシーを作成します。YAML を web-allow-all-namespaces.yaml ファイルに保存します。 

    apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: web-allow-all-namespaces
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: web
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector: {}

    ここでは、以下のようになります。

    app
    デフォルト名前空間の app:web Pod にのみポリシーを適用します。
    namespaceSelector

    すべての namespace のすべての Pod を選択します。

    注記

    デフォルトでは、ポリシーオブジェクトで namespaceSelector パラメーターを指定しない場合、名前空間は選択されません。これは、そのネットワークポリシーがデプロイされている namespace からのみのトラフィックを許可することを意味します。

  2. 次のコマンドを入力して、ポリシーを適用します。正常に処理された場合、ポリシーオブジェクトの名前と 作成 ステータスが表示されます。 

    $ oc apply -f web-allow-all-namespaces.yaml

検証

  1. 次のコマンドを入力して、default の名前空間で Web サービスを開始します。 

    $ oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80

  2. 次のコマンドを実行して、alpine イメージを secondary 名前空間にデプロイし、シェルを開始します。 

    $ oc run test-$RANDOM --namespace=secondary --rm -i -t --image=alpine -- sh

  3. シェルで次のコマンドを実行し、サービスがリクエストを許可することを確認します。 

    # wget -qO- --timeout=2 http://web.default
     
    <!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

特定の名前空間から、ラベルが アプリケーション=web の Pod へのトラフィックを許可するポリシーを設定できます。この設定は、次のユースケースで役立ちます。

  • 実稼働データベースへのトラフィックを、実稼働ワークロードがデプロイされている namespace のみに制限します。
  • 特定の namespace にデプロイされた監視ツールを有効にして、現在の namespace からメトリクスをスクレイピングします。
注記

cluster-admin ロールを持つユーザーでログインしている場合、クラスター内の namespace でネットワークポリシーを作成できます。

前提条件

  • クラスターが、mode: NetworkPolicy が設定された NetworkPolicy オブジェクトをサポートするネットワークプラグイン (OVN-Kubernetes ネットワークプラグインなど) を使用している。
  • OpenShift CLI (oc) がインストールされている。
  • あなたは 管理者権限 を持つユーザー特権でクラスターにログインしました。
  • ネットワークポリシーが適用される namespace で作業している。
警告

network.openshift.io/policy-group: ingress ラベルをカスタム名前空間またはプロジェクトに適用しないでください。このラベルは Operator が管理し、OpenShift Container Platform のネットワーク機能専用です。システムによって作成された名前空間では、これを変更してはいけません。

このラベルを使用すると、断続的なネットワーク接続の切断、意図しないシステム NetworkPolicies リソースの適用、またはオペレーターが状態を調整しようとする際に設定のずれが発生する可能性があります。カスタムトラフィックグループを作成する場合は、必ず以下の手順に示すように、一意のユーザー定義ラベルを使用してください。

手順

  1. ラベルが Purpose=production の特定の名前空間内のすべての Pod からのトラフィックを許可するポリシーを作成します。YAML を web-allow-prod.yaml ファイルに保存します。 

    kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: web-allow-prod
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: web
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          purpose: production

    ここでは、以下のようになります。

    app
    デフォルトの名前空間の app:web Pod にのみポリシーを適用します。
    purpose
    ラベルが purpose=production の名前空間内の Pod のみにトラフィックを制限します。

  2. 次のコマンドを入力して、ポリシーを適用します。正常に処理された場合、ポリシーオブジェクトの名前と 作成 ステータスが表示されます。 

    $ oc apply -f web-allow-prod.yaml

検証

  1. 次のコマンドを入力して、default の名前空間で Web サービスを開始します。 

    $ oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80

  2. 次のコマンドを実行して、prod namespace を作成します。 

    $ oc create namespace prod

  3. 次のコマンドを実行して、prod 名前空間にラベルを付けます。 

    $ oc label namespace/prod purpose=production

  4. 次のコマンドを実行して、dev 名前空間を作成します。 

    $ oc create namespace dev

  5. 次のコマンドを実行して、dev 名前空間にラベルを付けます。 

    $ oc label namespace/dev purpose=testing

  6. 次のコマンドを実行して、alpine イメージを dev 名前空間にデプロイし、シェルを開始します。 

    $ oc run test-$RANDOM --namespace=dev --rm -i -t --image=alpine -- sh

  7. シェルで次のコマンドを実行し、ブロックされた要求の理由を確認します。たとえば、期待される出力は wget: download timed out です。 

    # wget -qO- --timeout=2 http://web.default

  8. 次のコマンドを実行して、alpine イメージを prod namespace にデプロイし、シェルを開始します。 

    $ oc run test-$RANDOM --namespace=prod --rm -i -t --image=alpine -- sh

  9. シェルで次のコマンドを実行し、リクエストが許可されていることを確認します。 

    # wget -qO- --timeout=2 http://web.default
     
    <!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

3.3. ネットワークポリシーの表示
リンクのコピー

クラスター管理者は、namespace のネットワークポリシーを表示できます。

3.3.1. NetworkPolicy オブジェクトの例
リンクのコピー

以下は、NetworkPolicy オブジェクトの設定例に解説を付けたものです。 

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-27107
spec:
  podSelector:
    matchLabels:
      app: mongodb
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: app
    ports:
    - protocol: TCP
      port: 27017

ここでは、以下のようになります。

name
NetworkPolicy オブジェクトの名前。
spec.podSelector
ポリシーが適用される Pod を説明するセレクター。ポリシーオブジェクトは NetworkPolicy オブジェクトが定義されるプロジェクトの Pod のみを選択できます。
ingress.from.podSelector
ポリシーオブジェクトが入力トラフィックを許可する Pod に一致するセレクター。セレクターは、NetworkPolicy と同じ namespace にある Pod を照合して検索します。
ingress.ports
トラフィックを受け入れる 1 つ以上の宛先ポートのリスト。

3.3.2. CLI を使用したネットワークポリシーの表示
リンクのコピー

namespace のネットワークポリシーを検査できます。

注記

cluster-admin 特権でログインすると、クラスター内の任意のネームスペースのネットワークポリシーを編集できます。

注記

cluster-admin 特権でログインすると、クラスター内の任意のネームスペースのネットワークポリシーを編集できます。Web コンソールでは、YAML 形式で直接ポリシーを編集するか、アクション メニューを使用して編集できます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • admin 権限を持つユーザーとしてクラスターにログインしている。
  • ネットワークポリシーが存在する namespace で作業している。

手順

  1. namespace 内のネットワークポリシーをリスト表示します。

    1. 次のコマンドを入力し、namespace 内に定義されているネットワークポリシーオブジェクトを表示します。 

      $ oc get networkpolicy

    2. オプション: 特定のネットワークポリシーを調べるには、次のコマンドを入力します。 

      $ oc describe networkpolicy <policy_name> -n <namespace>

      ここでは、以下のようになります。

      <policy_name>
      検査するネットワークポリシーの名前を指定します。
      <namespace>

      オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。 

      $ oc describe networkpolicy allow-same-namespace
       
      Name:         allow-same-namespace
Namespace:    ns1
Created on:   2021-05-24 22:28:56 -0400 EDT
Labels:       <none>
Annotations:  <none>
Spec:
  PodSelector:     <none> (Allowing the specific traffic to all pods in this namespace)
  Allowing ingress traffic:
    To Port: <any> (traffic allowed to all ports)
    From:
      PodSelector: <none>
  Not affecting egress traffic
  Policy Types: Ingress

3.4. ネットワークポリシーの編集
リンクのコピー

クラスター管理者は、namespace の既存のネットワークポリシーを編集できます。

3.4.1. ネットワークポリシーの編集
リンクのコピー

既存のポリシー設定を変更するには、名前空間内のネットワークポリシーを編集します。ポリシーを編集するには、ポリシーファイルを変更して oc apply コマンド で適用するか、oc edit コマンドを直接使用します。

注記

cluster-admin 特権でログインすると、クラスター内の任意のネームスペースのネットワークポリシーを編集できます。

注記

cluster-admin 特権でログインすると、クラスター内の任意のネームスペースのネットワークポリシーを編集できます。Web コンソールでは、YAML 形式で直接ポリシーを編集するか、アクション メニューを使用して編集できます。

前提条件

  • クラスターが、mode: NetworkPolicy が設定された NetworkPolicy オブジェクトをサポートするネットワークプラグイン (OVN-Kubernetes ネットワークプラグインなど) を使用している。
  • OpenShift CLI (oc) がインストールされている。
  • admin 権限を持つユーザーとしてクラスターにログインしている。
  • ネットワークポリシーが存在する namespace で作業している。

手順

  1. オプション: namespace のネットワークポリシーオブジェクトをリスト表示するには、以下のコマンドを入力します。 

    $ oc get network policy -n <namespace>

    ここでは、以下のようになります。

    <namespace>
    オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。

  2. ネットワークポリシーオブジェクトを編集します。

    1. ネットワークポリシーの定義をファイルに保存した場合は、ファイルを編集して必要な変更を加えてから、以下のコマンドを入力します。 

      $ oc apply -n <namespace> -f <policy_file>.yaml

      ここでは、以下のようになります。

      <namespace>
      オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
      <policy_file>
      ネットワークポリシーを含むファイルの名前を指定します。

    2. ネットワークポリシーオブジェクトを直接更新する必要がある場合、以下のコマンドを入力できます。 

      $ oc edit network policy <policy_name> -n <namespace>

      ここでは、以下のようになります。

      <policy_name>
      ネットワークポリシーの名前を指定します。
      <namespace>
      オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。

  3. ネットワークポリシーオブジェクトが更新されていることを確認します。 

    $ oc describe networkpolicy <policy_name> -n <namespace>

    ここでは、以下のようになります。

    <policy_name>
    ネットワークポリシーの名前を指定します。
    <namespace>
    オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。

3.4.2. NetworkPolicy オブジェクトの例
リンクのコピー

以下は、NetworkPolicy オブジェクトの設定例に解説を付けたものです。 

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-27107
spec:
  podSelector:
    matchLabels:
      app: mongodb
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: app
    ports:
    - protocol: TCP
      port: 27017

ここでは、以下のようになります。

name
NetworkPolicy オブジェクトの名前。
spec.podSelector
ポリシーが適用される Pod を説明するセレクター。ポリシーオブジェクトは NetworkPolicy オブジェクトが定義されるプロジェクトの Pod のみを選択できます。
ingress.from.podSelector
ポリシーオブジェクトが入力トラフィックを許可する Pod に一致するセレクター。セレクターは、NetworkPolicy と同じ namespace にある Pod を照合して検索します。
ingress.ports
トラフィックを受け入れる 1 つ以上の宛先ポートのリスト。

3.5. ネットワークポリシーの削除
リンクのコピー

クラスター管理者は、namespace からネットワークポリシーを削除できます。

3.5.1. CLI を使用したネットワークポリシーの削除
リンクのコピー

namespace のネットワークポリシーを削除できます。

注記

cluster-admin 特権でログインすると、クラスター内の任意の名前空間にあるネットワークポリシーを削除できます。

注記

cluster-admin 特権でログインすると、クラスター内の任意の名前空間にあるネットワークポリシーを削除できます。Web コンソールでは、YAML 形式で直接ポリシーを削除するか、アクション メニューを使用してポリシーを削除できます。

前提条件

  • クラスターが、mode: NetworkPolicy が設定された NetworkPolicy オブジェクトをサポートするネットワークプラグイン (OVN-Kubernetes ネットワークプラグインなど) を使用している。
  • OpenShift CLI (oc) がインストールされている。
  • あなたは 管理者権限 を持つユーザー特権でクラスターにログインしました。
  • ネットワークポリシーが存在する namespace で作業している。

手順

  • ネットワークポリシーオブジェクトを削除するには、以下のコマンドを入力します。正常に処理された場合、ポリシーオブジェクトの名前と 削除 ステータスが表示されます。 

    $ oc delete networkpolicy <policy_name> -n <namespace>

    ここでは、以下のようになります。

    <policy_name>
    ネットワークポリシーの名前を指定します。
    <namespace>
    オプションのパラメーター。現在の namespace とは異なる namespace でオブジェクトを定義した場合、パラメーターは namespace を指定します。

3.6. プロジェクトのデフォルトネットワークポリシーの定義
リンクのコピー

クラスター管理者は、新規プロジェクトの作成時にネットワークポリシーを自動的に含めるように新規プロジェクトテンプレートを変更できます。新規プロジェクトのカスタマイズされたテンプレートがまだない場合には、まずテンプレートを作成する必要があります。

3.6.1. 新規プロジェクトのテンプレートの変更
リンクのコピー

クラスター管理者は、デフォルトのプロジェクトテンプレートを変更し、新規プロジェクトをカスタム要件に基づいて作成できます。

独自のカスタムプロジェクトテンプレートを作成するには、以下を実行します。

前提条件

  • cluster-admin パーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。

手順

  1. cluster-admin 権限を持つユーザーとしてログインします。

  2. デフォルトのプロジェクトテンプレートを生成します。 

    $ oc adm create-bootstrap-project-template -o yaml > template.yaml
  3. オブジェクトを追加するか、既存オブジェクトを変更することにより、テキストエディターで生成される template.yaml ファイルを変更します。

  4. プロジェクトテンプレートは、openshift-config namespace に作成する必要があります。変更したテンプレートを読み込みます。 

    $ oc create -f template.yaml -n openshift-config

  5. Web コンソールまたは CLI を使用し、プロジェクト設定リソースを編集します。

    • Web コンソールの使用

      1. Administration → Cluster Settings ページに移動します。
      2. Configuration をクリックし、すべての設定リソースを表示します。
      3. Project のエントリーを見つけ、Edit YAML をクリックします。

    • CLI の使用

      1. project.config.openshift.io/cluster リソースを編集します。 

        $ oc edit project.config.openshift.io/cluster

  6. spec セクションを、projectRequestTemplate および name パラメーターを組み込むように更新し、アップロードされたプロジェクトテンプレートの名前を設定します。デフォルト名は project-request です。

    カスタムプロジェクトテンプレートを含むプロジェクト設定リソース

    apiVersion: config.openshift.io/v1
kind: Project
metadata:
# ...
spec:
  projectRequestTemplate:
    name: <template_name>
# ...

  7. 変更を保存した後、変更が正常に適用されたことを確認するために、新しいプロジェクトを作成します。

3.6.2. 新規プロジェクトへのネットワークポリシーの追加
リンクのコピー

クラスター管理者は、ネットワークポリシーを新規プロジェクトのデフォルトテンプレートに追加できます。OpenShift Container Platform は、プロジェクトのテンプレートに指定されたすべての NetworkPolicy オブジェクトを自動的に作成します。

前提条件

  • クラスターが、OVN-Kubernetes などの NetworkPolicy オブジェクトをサポートするデフォルトの Container Network Interface (CNI) ネットワークプラグインを使用している。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてクラスターにログインする。
  • 新規プロジェクトのカスタムデフォルトプロジェクトテンプレートを作成している。

手順

  1. 以下のコマンドを実行して、新規プロジェクトのデフォルトテンプレートを編集します。 

    $ oc edit template <project_template> -n openshift-config

    <project_template> を、クラスターに設定したデフォルトテンプレートの名前に置き換えます。デフォルトのテンプレート名は project-request です。

  2. テンプレートでは、各 NetworkPolicy オブジェクトを要素として objects パラメーターに追加します。objects パラメーターは、1 つ以上のオブジェクトのコレクションを受け入れます。

    以下の例では、objects パラメーターのコレクションにいくつかの NetworkPolicy オブジェクトが含まれます。 

    objects:
- apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: allow-from-same-namespace
  spec:
    podSelector: {}
    ingress:
    - from:
      - podSelector: {}
- apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: allow-from-openshift-ingress
  spec:
    ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            policy-group.network.openshift.io/ingress:
    podSelector: {}
    policyTypes:
    - Ingress
- apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: allow-from-kube-apiserver-operator
  spec:
    ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            kubernetes.io/metadata.name: openshift-kube-apiserver-operator
        podSelector:
          matchLabels:
            app: kube-apiserver-operator
    policyTypes:
    - Ingress
...

  3. オプション: 新しいプロジェクトを作成し、ネットワークポリシーオブジェクトが正常に作成されたことを確認します。

    1. プロジェクトを新規作成します。 

      $ oc new-project <project>
      1
      1
      <project> を、作成しているプロジェクトの名前に置き換えます。

    2. 新規プロジェクトテンプレートのネットワークポリシーオブジェクトが新規プロジェクトに存在することを確認します。 

      $ oc get networkpolicy

      想定される出力: 

      NAME                           POD-SELECTOR   AGE
allow-from-openshift-ingress   <none>         7s
allow-from-same-namespace      <none>         7s

3.7. ネットワークポリシーを使用したマルチテナント分離の設定
リンクのコピー

クラスター管理者は、マルチテナントネットワークの分離を実行するようにネットワークポリシーを設定できます。

注記

このセクションで説明するようにネットワークポリシーを設定すると、以前のバージョンの OpenShift Container Platform における OpenShift SDN のマルチテナントモードと同様のネットワーク分離が実現します。

3.7.1. ネットワークポリシーを使用したマルチテナント分離の設定
リンクのコピー

他のプロジェクト namespace の Pod およびサービスから分離できるようにプロジェクトを設定できます。

前提条件

  • クラスターが、mode: NetworkPolicy が設定された NetworkPolicy オブジェクトをサポートするネットワークプラグイン (OVN-Kubernetes ネットワークプラグインなど) を使用している。
  • OpenShift CLI (oc) がインストールされている。
  • admin 権限を持つユーザーとしてクラスターにログインしている。

手順

  1. 以下の NetworkPolicy オブジェクトを作成します。

    1. allow-from-openshift-ingress という名前のポリシー: 

      $ cat << EOF| oc create -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-openshift-ingress
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          policy-group.network.openshift.io/ingress: ""
  podSelector: {}
  policyTypes:
  - Ingress
EOF
      注記

      policy-group.network.openshift.io/ingress: "" は、OVN-Kubernetes の推奨される namespace セレクターラベルです。

    2. allow-from-openshift-monitoring という名前のポリシー。 

      $ cat << EOF| oc create -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-openshift-monitoring
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          network.openshift.io/policy-group: monitoring
  podSelector: {}
  policyTypes:
  - Ingress
EOF

    3. allow-same-namespace という名前のポリシー: 

      $ cat << EOF| oc create -f -
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-same-namespace
spec:
  podSelector:
  ingress:
  - from:
    - podSelector: {}
EOF

    4. allow-from-kube-apiserver-operator という名前のポリシー: 

      $ cat << EOF| oc create -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-kube-apiserver-operator
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: openshift-kube-apiserver-operator
      podSelector:
        matchLabels:
          app: kube-apiserver-operator
  policyTypes:
  - Ingress
EOF

      詳細は、新規の New kube-apiserver-operator webhook controller validating health of webhook を参照してください。

  2. オプション: 以下のコマンドを実行し、ネットワークポリシーオブジェクトが現在のプロジェクトに存在することを確認します。 

    $ oc describe networkpolicy

    出力例

    Name:         allow-from-openshift-ingress
Namespace:    example1
Created on:   2020-06-09 00:28:17 -0400 EDT
Labels:       <none>
Annotations:  <none>
Spec:
  PodSelector:     <none> (Allowing the specific traffic to all pods in this namespace)
  Allowing ingress traffic:
    To Port: <any> (traffic allowed to all ports)
    From:
      NamespaceSelector: policy-group.network.openshift.io/ingress:
  Not affecting egress traffic
  Policy Types: Ingress


Name:         allow-from-openshift-monitoring
Namespace:    example1
Created on:   2020-06-09 00:29:57 -0400 EDT
Labels:       <none>
Annotations:  <none>
Spec:
  PodSelector:     <none> (Allowing the specific traffic to all pods in this namespace)
  Allowing ingress traffic:
    To Port: <any> (traffic allowed to all ports)
    From:
      NamespaceSelector: network.openshift.io/policy-group: monitoring
  Not affecting egress traffic
  Policy Types: Ingress

3.7.2. 次のステップ
リンクのコピー

第4章 ネットワークセキュリティーの監査ロギング
リンクのコピー

OVN-Kubernetes ネットワークプラグインは、Open Virtual Network (OVN) アクセス制御リスト (ACL) を使用して、AdminNetworkPolicy、BaselineAdminNetworkPolicy、NetworkPolicy、および EgressFirewall オブジェクトを管理します。監査ログは、NetworkPolicy、EgressFirewall、および BaselineAdminNetworkPolicy カスタムリソース (CR) の allow および deny ACL イベントを公開します。ロギングは、AdminNetworkPolicy (ANP) CR の allow、deny、pass ACL イベントも公開します。

注記

監査ログは、OVN-Kubernetes ネットワークプラグイン でのみ使用できます。

4.1. 監査設定
リンクのコピー

監査ロギングの設定は、OVN-Kubernetes クラスターネットワークプロバイダー設定の一部として指定されます。次の YAML は、監査ログのデフォルト値を示しています。

監査ロギング設定

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  defaultNetwork:
    ovnKubernetesConfig:
      policyAuditConfig:
        destination: "null"
        maxFileSize: 50
        rateLimit: 20
        syslogFacility: local0

次の表では、監査ログの設定フィールドを説明します。

Expand
表4.1 policyAuditConfig オブジェクト
フィールド型説明

rateLimit

integer

ノードごとに毎秒生成されるメッセージの最大数。デフォルト値は、1 秒あたり 20 メッセージです。

maxFileSize

integer

監査ログの最大サイズ (バイト単位)。デフォルト値は 50000000 (50MB) です。

maxLogFiles

integer

保持されるログファイルの最大数。

destination

string

以下の追加の監査ログターゲットのいずれかになります。

libc
ホスト上の journald プロセスの libc syslog() 関数。
udp:<host>:<port>
syslog サーバー。<host>:<port> を syslog サーバーのホストおよびポートに置き換えます。
unix:<file>
<file> で指定された Unix ドメインソケットファイル。
null
監査ログを追加のターゲットに送信しないでください。

syslogFacility

string

RFC5424 で定義される kern などの syslog ファシリティー。デフォルト値は local0 です。

4.2. 監査ロギング
リンクのコピー

syslog サーバーや UNIX ドメインソケットなど、監査ログの宛先を設定できます。追加の設定に関係なく、監査ログは常にクラスター内の各 OVN-Kubernetes Pod の /var/log/ovn/acl-audit-log.log に保存されます。

各 namespace 設定に k8s.ovn.org/acl-logging セクションをアノテーション付けすることで、各 namespace の監査ログを有効にできます。k8s.ovn.org/acl-logging セクションでは、namespace の監査ログを有効にするために、allow、deny、またはその両方の値を指定する必要があります。

注記

ネットワークポリシーでは、Pass アクションセットをルールとして設定することはサポートされていません。

ACL ロギング実装は、ネットワークのアクセス制御リスト (ACL) イベントをログに記録します。これらのログを表示して、潜在的なセキュリティー問題を分析できます。

namespace アノテーションの例

kind: Namespace
apiVersion: v1
metadata:
  name: example1
  annotations:
    k8s.ovn.org/acl-logging: |-
      {
        "deny": "info",
        "allow": "info"
      }

デフォルトの ACL ロギング設定値を表示するには、cluster-network-03-config.yml ファイルの policyAuditConfig オブジェクトを参照してください。必要に応じて、このファイル内のログファイルパラメーターの ACL ロギング設定値を変更できます。

ログメッセージの形式は、RFC5424 で定義されている syslog と互換性があります。syslog ファシリティーは設定可能です。デフォルトは local0 です。次の例は、ログメッセージに出力される主要なパラメーターとその値を示しています。

パラメーターとその値を出力するロギングメッセージの例

<timestamp>|<message_serial>|acl_log(ovn_pinctrl0)|<severity>|name="<acl_name>", verdict="<verdict>", severity="<severity>", direction="<direction>": <flow>

詳細は、以下のようになります。

  • <timestamp> は、ログメッセージが作成された日時を示します。
  • <message_serial> には、ログメッセージのシリアル番号がリストされます。
  • acl_log(ovn_pinctrl0) は、OVN-Kubernetes プラグイン内のログメッセージの場所を出力するリテラル文字列です。
  • <severity> は、ログメッセージの重大度レベルを設定します。allow タスクと deny タスクをサポートする監査ログを有効にすると、ログメッセージ出力に 2 つの重大度レベルが表示されます。
  • <name> は、ネットワークポリシーによって作成された OVN ネットワークブリッジングデータベース (nbdb) 内の ACL ロギング実装の名前を示します。
  • <verdict> は、allow または drop のいずれかになります。
  • <direction> は、to-lport または from-lport のいずれかで、ポリシーが Pod に向かうトラフィックまたは Pod から出るトラフィックに適用されたことを示します。
  • <flow> は、OpenFlow プロトコルと同等の形式でパケット情報を表示します。このパラメーターは Open vSwitch (OVS) フィールドで構成されます。

次の例は、flow パラメーターがシステムメモリーからパケット情報を抽出するために使用する OVS フィールドを示しています。

flow パラメーターがパケット情報を抽出するために使用する OVS フィールドの例

<proto>,vlan_tci=0x0000,dl_src=<src_mac>,dl_dst=<source_mac>,nw_src=<source_ip>,nw_dst=<target_ip>,nw_tos=<tos_dscp>,nw_ecn=<tos_ecn>,nw_ttl=<ip_ttl>,nw_frag=<fragment>,tp_src=<tcp_src_port>,tp_dst=<tcp_dst_port>,tcp_flags=<tcp_flags>

詳細は、以下のようになります。

  • <proto> はプロトコルを指定します。有効な値は tcp と udp です。
  • vlan_tci=0x0000 は、内部 Pod ネットワークトラフィックに VLAN ID が設定されていないため、VLAN ヘッダーを 0 として示します。
  • <src_mac> は、メディアアクセス制御 (MAC) アドレスのソースを指定します。
  • <source_mac> は、MAC アドレスの宛先を指定します。
  • <source_ip> は、送信元 IP アドレスをリストします
  • <target_ip> は、ターゲット IP アドレスをリストします。
  • <tos_dscp> は、特定のネットワークトラフィックを他のトラフィックよりも分類して優先順位を付ける差別化サービスコードポイント (DSCP) 値を指定します。
  • <tos_ecn> は、ネットワーク内の輻輳したトラフィックを示す明示的輻輳通知 (ECN) 値を示します。
  • <ip_ttl> は、パケットの Time To Live (TTL) 情報を示します。
  • <fragment> は、一致させる IP フラグメントまたは IP 非フラグメントのタイプを指定します。
  • <tcp_src_port> は、TCP および UDP プロトコルのポートのソースを示します。
  • <tcp_dst_port> は、TCP および UDP プロトコルの宛先ポートをリストします。
  • <tcp_flags> は、SYN、ACK、PSH などの多数のフラグをサポートします。複数の値を設定する必要がある場合は、各値を縦棒 (|) で区切ります。UDP プロトコルはこのパラメーターをサポートしていません。
注記

以前のフィールドの説明の詳細は、OVS の man ページの ovs-fields を参照してください。

ネットワークポリシーの ACL 拒否ログエントリーの例

2023-11-02T16:28:54.139Z|00004|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:Ingress", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:01,dl_dst=0a:58:0a:81:02:23,nw_src=10.131.0.39,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=62,nw_frag=no,tp_src=58496,tp_dst=8080,tcp_flags=syn
2023-11-02T16:28:55.187Z|00005|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:Ingress", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:01,dl_dst=0a:58:0a:81:02:23,nw_src=10.131.0.39,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=62,nw_frag=no,tp_src=58496,tp_dst=8080,tcp_flags=syn
2023-11-02T16:28:57.235Z|00006|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:Ingress", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:01,dl_dst=0a:58:0a:81:02:23,nw_src=10.131.0.39,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=62,nw_frag=no,tp_src=58496,tp_dst=8080,tcp_flags=syn

以下の表は、namespace アノテーションの値を説明しています。

Expand
表4.2 k8s.ovn.org/acl-logging の監査ロギング namespace アノテーション
フィールド説明

deny

deny アクションを含む ACL ルールに一致するすべてのトラフィックへの namespace アクセスをブロックします。このフィールドは、alert、warning、notice、info、または debug の値をサポートします。

allow

allow アクションを含む ACL ルールに一致するすべてのトラフィックへの namespace アクセスを許可します。このフィールドは、alert、warning、notice、info、または debug の値をサポートします。

pass

pass アクションは、管理ネットワークポリシーの ACL ルールに適用されます。pass アクションにより、namespace 内のネットワークポリシーまたはベースライン管理ネットワークポリシールールのいずれかを使用して、すべての受信トラフィックと送信トラフィックを評価できます。ネットワークポリシーは pass アクションをサポートしていません。

4.3. AdminNetworkPolicy 監査ログ
リンクのコピー

監査ロギングは、次の例のように、ANP ポリシーに k8s.ovn.org/acl-logging キーのアノテーションを付けることにより、AdminNetworkPolicy CR ごとに有効になります。

例4.1 AdminNetworkPolicy CR のアノテーションの例

apiVersion: policy.networking.k8s.io/v1alpha1
kind: AdminNetworkPolicy
metadata:
  annotations:
    k8s.ovn.org/acl-logging: '{ "deny": "alert", "allow": "alert", "pass" : "warning" }'
  name: anp-tenant-log
spec:
  priority: 5
  subject:
    namespaces:
      matchLabels:
        tenant: backend-storage # Selects all pods owned by storage tenant.
  ingress:
    - name: "allow-all-ingress-product-development-and-customer" # Product development and customer tenant ingress to backend storage.
      action: "Allow"
      from:
      - pods:
          namespaceSelector:
            matchExpressions:
            - key: tenant
              operator: In
              values:
              - product-development
              - customer
          podSelector: {}
    - name: "pass-all-ingress-product-security"
      action: "Pass"
      from:
      - namespaces:
          matchLabels:
              tenant: product-security
    - name: "deny-all-ingress" # Ingress to backend from all other pods in the cluster.
      action: "Deny"
      from:
      - namespaces: {}
  egress:
    - name: "allow-all-egress-product-development"
      action: "Allow"
      to:
      - pods:
          namespaceSelector:
            matchLabels:
              tenant: product-development
          podSelector: {}
    - name: "pass-egress-product-security"
      action: "Pass"
      to:
      - namespaces:
           matchLabels:
             tenant: product-security
    - name: "deny-all-egress" # Egress from backend denied to all other pods.
      action: "Deny"
      to:
      - namespaces: {}

特定の OVN ACL に該当し、ロギングアノテーションで設定されたアクション基準を満たすたびに、ログが生成されます。たとえば、ラベルが tenant: product-development の namespace のいずれかが tenant: backend-storage のラベルが付いた namespace にアクセスするイベントでは、ログが生成されます。

注記

ACL ロギングは 60 文字に制限されます。ANP の name フィールドが長い場合、ログの残りの部分が切り捨てられます。

以下は、ログエントリーの例の方向インデックスです。

Expand
方向ルール

Ingress

Rule0
product-development および customer のテナントから backend-storage テナントの Ingress を許可する、Ingress0: Allow
Rule1
product-security` から `backend-storage テナントの Ingress を通過させる、Ingress1: Pass
Rule2
全 Pod からの Ingress を拒否する、Ingress2: Deny

Egress

Rule0
product-development への Egress を許可する、Egress0: Allow
Rule1
product-security への Egress を通過させる、Egress1: Pass
Rule2
その他の Pod すべてへの Egress を拒否する、Egress2: Deny

例4.2 anp-tenant-log という名前の AdminNetworkPolicy の Ingress:0 および Egress:0 による Allow アクションに関する ACL ログエントリー例

2024-06-10T16:27:45.194Z|00052|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Ingress:0", verdict=allow, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:1a,dl_dst=0a:58:0a:80:02:19,nw_src=10.128.2.26,nw_dst=10.128.2.25,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=57814,tp_dst=8080,tcp_flags=syn
2024-06-10T16:28:23.130Z|00059|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Ingress:0", verdict=allow, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:18,dl_dst=0a:58:0a:80:02:19,nw_src=10.128.2.24,nw_dst=10.128.2.25,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=38620,tp_dst=8080,tcp_flags=ack
2024-06-10T16:28:38.293Z|00069|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Egress:0", verdict=allow, severity=alert, direction=from-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:19,dl_dst=0a:58:0a:80:02:1a,nw_src=10.128.2.25,nw_dst=10.128.2.26,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=47566,tp_dst=8080,tcp_flags=fin|ack=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=55704,tp_dst=8080,tcp_flags=ack

例4.3 anp-tenant-log という名前の AdminNetworkPolicy の Ingress:1 および Egress:1 による Pass アクションに関する ACL ログエントリー例

2024-06-10T16:33:12.019Z|00075|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Ingress:1", verdict=pass, severity=warning, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:1b,dl_dst=0a:58:0a:80:02:19,nw_src=10.128.2.27,nw_dst=10.128.2.25,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=37394,tp_dst=8080,tcp_flags=ack
2024-06-10T16:35:04.209Z|00081|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Egress:1", verdict=pass, severity=warning, direction=from-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:19,dl_dst=0a:58:0a:80:02:1b,nw_src=10.128.2.25,nw_dst=10.128.2.27,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=34018,tp_dst=8080,tcp_flags=ack

例4.4 anp-tenant-log という名前の AdminNetworkPolicy の Egress:2 および Ingress2 による Deny アクションに関する ACL ログエントリー例

2024-06-10T16:43:05.287Z|00087|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Egress:2", verdict=drop, severity=alert, direction=from-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:19,dl_dst=0a:58:0a:80:02:18,nw_src=10.128.2.25,nw_dst=10.128.2.24,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=51598,tp_dst=8080,tcp_flags=syn
2024-06-10T16:44:43.591Z|00090|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Ingress:2", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:1c,dl_dst=0a:58:0a:80:02:19,nw_src=10.128.2.28,nw_dst=10.128.2.25,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=33774,tp_dst=8080,tcp_flags=syn

次の表は、ANP アノテーションを説明しています。

Expand
表4.3 監査ログの AdminNetworkPolicy アノテーション
アノテーション値

k8s.ovn.org/acl-logging

namespace の監査ログを有効にするには、Allow、Deny、または Pass を指定する必要があります。

Deny
オプション: alert、warning、notice、info、または debug を指定します。
Allow
オプション: alert、warning、notice、info、または debug を指定します。
Pass
オプション: alert、warning、notice、info、または debug を指定します。

4.4. BaselineAdminNetworkPolicy 監査ログ
リンクのコピー

監査ロギングは、次の例のように、BANP ポリシーに k8s.ovn.org/acl-logging キーのアノテーションを付けすることで、BaselineAdminNetworkPolicy CR で有効になります。

例4.5 BaselineAdminNetworkPolicy CR のアノテーションの例

apiVersion: policy.networking.k8s.io/v1alpha1
kind: BaselineAdminNetworkPolicy
metadata:
  annotations:
    k8s.ovn.org/acl-logging: '{ "deny": "alert", "allow": "alert"}'
  name: default
spec:
  subject:
    namespaces:
      matchLabels:
          tenant: workloads # Selects all workload pods in the cluster.
  ingress:
  - name: "default-allow-dns" # This rule allows ingress from dns tenant to all workloads.
    action: "Allow"
    from:
    - namespaces:
          matchLabels:
            tenant: dns
  - name: "default-deny-dns" # This rule denies all ingress from all pods to workloads.
    action: "Deny"
    from:
    - namespaces: {} # Use the empty selector with caution because it also selects OpenShift namespaces as well.
  egress:
  - name: "default-deny-dns" # This rule denies all egress from workloads. It will be applied when no ANP or network policy matches.
    action: "Deny"
    to:
    - namespaces: {} # Use the empty selector with caution because it also selects OpenShift namespaces as well.

この例では、ラベルが tenant: dns の namespace のいずれかが tenant: workloads ラベルを持つ namespace にアクセスするイベントで、ログが生成されます。

以下は、ログエントリーの例の方向インデックスです。

Expand
方向ルール

Ingress

Rule0
dns テナントから workloads テナントへの Ingress を許可する、Ingress0: Allow
Rule1
全 Pod から workloads テナントへの Ingress を拒否する、Ingress1: Deny

Egress

Rule0
すべての Pod への Egress を拒否する、Egress0: Deny

例4.6 Ingress:0 での default BANP の Allow アクションに関する ACL 許可ログエントリーの例

2024-06-10T18:11:58.263Z|00022|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Ingress:0", verdict=allow, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:57,dl_dst=0a:58:0a:82:02:56,nw_src=10.130.2.87,nw_dst=10.130.2.86,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=60510,tp_dst=8080,tcp_flags=syn
2024-06-10T18:11:58.264Z|00023|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Ingress:0", verdict=allow, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:57,dl_dst=0a:58:0a:82:02:56,nw_src=10.130.2.87,nw_dst=10.130.2.86,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=60510,tp_dst=8080,tcp_flags=psh|ack
2024-06-10T18:11:58.264Z|00024|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Ingress:0", verdict=allow, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:57,dl_dst=0a:58:0a:82:02:56,nw_src=10.130.2.87,nw_dst=10.130.2.86,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=60510,tp_dst=8080,tcp_flags=ack
2024-06-10T18:11:58.264Z|00025|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Ingress:0", verdict=allow, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:57,dl_dst=0a:58:0a:82:02:56,nw_src=10.130.2.87,nw_dst=10.130.2.86,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=60510,tp_dst=8080,tcp_flags=ack
2024-06-10T18:11:58.264Z|00026|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Ingress:0", verdict=allow, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:57,dl_dst=0a:58:0a:82:02:56,nw_src=10.130.2.87,nw_dst=10.130.2.86,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=60510,tp_dst=8080,tcp_flags=fin|ack
2024-06-10T18:11:58.264Z|00027|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Ingress:0", verdict=allow, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:57,dl_dst=0a:58:0a:82:02:56,nw_src=10.130.2.87,nw_dst=10.130.2.86,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=60510,tp_dst=8080,tcp_flags=ack

例4.7 Egress:0 および Ingress:1 での default BANP の Allow アクションに関する ACL 許可ログエントリーの例

2024-06-10T18:09:57.774Z|00016|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Egress:0", verdict=drop, severity=alert, direction=from-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:56,dl_dst=0a:58:0a:82:02:57,nw_src=10.130.2.86,nw_dst=10.130.2.87,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=45614,tp_dst=8080,tcp_flags=syn
2024-06-10T18:09:58.809Z|00017|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Egress:0", verdict=drop, severity=alert, direction=from-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:56,dl_dst=0a:58:0a:82:02:57,nw_src=10.130.2.86,nw_dst=10.130.2.87,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=45614,tp_dst=8080,tcp_flags=syn
2024-06-10T18:10:00.857Z|00018|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Egress:0", verdict=drop, severity=alert, direction=from-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:56,dl_dst=0a:58:0a:82:02:57,nw_src=10.130.2.86,nw_dst=10.130.2.87,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=45614,tp_dst=8080,tcp_flags=syn
2024-06-10T18:10:25.414Z|00019|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Ingress:1", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:58,dl_dst=0a:58:0a:82:02:56,nw_src=10.130.2.88,nw_dst=10.130.2.86,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=40630,tp_dst=8080,tcp_flags=syn
2024-06-10T18:10:26.457Z|00020|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Ingress:1", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:58,dl_dst=0a:58:0a:82:02:56,nw_src=10.130.2.88,nw_dst=10.130.2.86,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=40630,tp_dst=8080,tcp_flags=syn
2024-06-10T18:10:28.505Z|00021|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Ingress:1", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:58,dl_dst=0a:58:0a:82:02:56,nw_src=10.130.2.88,nw_dst=10.130.2.86,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=40630,tp_dst=8080,tcp_flags=syn

次の表では、BANP アノテーションを説明します。

Expand
表4.4 監査ログの BaselineAdminNetworkPolicy アノテーション
アノテーション値

k8s.ovn.org/acl-logging

namespace の監査ロギングを有効にするには、少なくとも Allow または Deny のいずれかを指定する必要があります。

Deny
オプション: alert、warning、notice、info、または debug を指定します。
Allow
オプション: alert、warning、notice、info、または debug を指定します。

4.5. クラスターの Egress ファイアウォールとネットワークポリシー監査の設定
リンクのコピー

クラスター管理者は、クラスターの監査ログをカスタマイズできます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてクラスターにログインする。

手順

  • 監査ロギング設定をカスタマイズするには、次のコマンドを入力します。 

    $ oc edit network.operator.openshift.io/cluster
    ヒント

    次の YAML をカスタマイズして適用し、監査ログを設定することもできます。 

    apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  defaultNetwork:
    ovnKubernetesConfig:
      policyAuditConfig:
        destination: "null"
        maxFileSize: 50
        rateLimit: 20
        syslogFacility: local0

検証

  1. ネットワークポリシーを使用して namespace を作成するには、次の手順を実行します。

    1. 検証用の namespace を作成します。 

      $ cat <<EOF| oc create -f -
kind: Namespace
apiVersion: v1
metadata:
  name: verify-audit-logging
  annotations:
    k8s.ovn.org/acl-logging: '{ "deny": "alert", "allow": "alert" }'
EOF

      成功した出力には、ネットワークポリシーと created ステータスを含む namespace がリスト表示されます。

    2. namespace のネットワークポリシーを作成します。 

      $ cat <<EOF| oc create -n verify-audit-logging -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
spec:
  podSelector:
    matchLabels:
  policyTypes:
  - Ingress
  - Egress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-same-namespace
  namespace: verify-audit-logging
spec:
  podSelector: {}
  policyTypes:
   - Ingress
   - Egress
  ingress:
    - from:
        - podSelector: {}
  egress:
    - to:
       - namespaceSelector:
          matchLabels:
            kubernetes.io/metadata.name: verify-audit-logging
EOF

      出力例

      networkpolicy.networking.k8s.io/deny-all created
networkpolicy.networking.k8s.io/allow-from-same-namespace created

  2. ソーストラフィックの Pod を default namespace に作成します。 

    $ cat <<EOF| oc create -n default -f -
apiVersion: v1
kind: Pod
metadata:
  name: client
spec:
  containers:
    - name: client
      image: registry.access.redhat.com/rhel7/rhel-tools
      command: ["/bin/sh", "-c"]
      args:
        ["sleep inf"]
EOF

  3. verify-audit-logging namespace に 2 つの Pod を作成します。 

    $ for name in client server; do
cat <<EOF| oc create -n verify-audit-logging -f -
apiVersion: v1
kind: Pod
metadata:
  name: ${name}
spec:
  containers:
    - name: ${name}
      image: registry.access.redhat.com/rhel7/rhel-tools
      command: ["/bin/sh", "-c"]
      args:
        ["sleep inf"]
EOF
done

    成功した出力には、pod/client や pod/server などの 2 つの Pod と、created ステータスがリスト表示されます。

  4. トラフィックを生成し、ネットワークポリシー監査ログエントリーを作成するには、以下の手順を実行します。

    1. verify-audit-logging namespace で server という名前の Pod の IP アドレスを取得します。 

      $ POD_IP=$(oc get pods server -n verify-audit-logging -o jsonpath='{.status.podIP}')

    2. default namespace にある client という名前の Pod から、前のコマンドの IP アドレスを ping し、すべてのパケットがドロップされていることを確認します。 

      $ oc exec -it client -n default -- /bin/ping -c 2 $POD_IP

      出力例

      PING 10.128.2.55 (10.128.2.55) 56(84) bytes of data.

--- 10.128.2.55 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 2041ms

    3. verify-audit-logging namespace のクライアント Pod から、POD_IP shell 環境変数に保存されている IP アドレスに ping し、システムがすべてのパケットを許可していることを確認します。 

      $ oc exec -it client -n verify-audit-logging -- /bin/ping -c 2 $POD_IP

      出力例

      PING 10.128.0.86 (10.128.0.86) 56(84) bytes of data.
64 bytes from 10.128.0.86: icmp_seq=1 ttl=64 time=2.21 ms
64 bytes from 10.128.0.86: icmp_seq=2 ttl=64 time=0.440 ms

--- 10.128.0.86 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.440/1.329/2.219/0.890 ms

  5. ネットワークポリシー監査ログの最新エントリーを表示します。 

    $ for pod in $(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node --no-headers=true | awk '{ print $1 }') ; do
    oc exec -it $pod -n openshift-ovn-kubernetes -- tail -4 /var/log/ovn/acl-audit-log.log
  done

    出力例

    2023-11-02T16:28:54.139Z|00004|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:Ingress", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:01,dl_dst=0a:58:0a:81:02:23,nw_src=10.131.0.39,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=62,nw_frag=no,tp_src=58496,tp_dst=8080,tcp_flags=syn
2023-11-02T16:28:55.187Z|00005|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:Ingress", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:01,dl_dst=0a:58:0a:81:02:23,nw_src=10.131.0.39,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=62,nw_frag=no,tp_src=58496,tp_dst=8080,tcp_flags=syn
2023-11-02T16:28:57.235Z|00006|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:Ingress", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:01,dl_dst=0a:58:0a:81:02:23,nw_src=10.131.0.39,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=62,nw_frag=no,tp_src=58496,tp_dst=8080,tcp_flags=syn
2023-11-02T16:49:57.909Z|00028|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Egress:0", verdict=allow, severity=alert, direction=from-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0
2023-11-02T16:49:57.909Z|00029|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Ingress:0", verdict=allow, severity=alert, direction=to-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0
2023-11-02T16:49:58.932Z|00030|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Egress:0", verdict=allow, severity=alert, direction=from-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0
2023-11-02T16:49:58.932Z|00031|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Ingress:0", verdict=allow, severity=alert, direction=to-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0

4.6. namespace の Egress ファイアウォールとネットワークポリシーの監査ログを有効にする
リンクのコピー

クラスター管理者は、namespace の監査ログを有効にすることができます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてクラスターにログインする。

手順

  • namespace の監査ログを有効にするには、次のコマンドを入力します。 

    $ oc annotate namespace <namespace> \
  k8s.ovn.org/acl-logging='{ "deny": "alert", "allow": "notice" }'

    ここでは、以下のようになります。

    <namespace>
    namespace の名前を指定します。
    ヒント

    監査ロギングを有効にするには、次の YAML を適用することもできます。 

    kind: Namespace
apiVersion: v1
metadata:
  name: <namespace>
  annotations:
    k8s.ovn.org/acl-logging: |-
      {
        "deny": "alert",
        "allow": "notice"
      }

    成功した出力には、監査ロギング名と annotated ステータスがリスト表示されます。

検証

  • 監査ログの最新のエントリーを表示します。 

    $ for pod in $(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node --no-headers=true | awk '{ print $1 }') ; do
    oc exec -it $pod -n openshift-ovn-kubernetes -- tail -4 /var/log/ovn/acl-audit-log.log
  done

    出力例

    2023-11-02T16:49:57.909Z|00028|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Egress:0", verdict=allow, severity=alert, direction=from-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0
2023-11-02T16:49:57.909Z|00029|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Ingress:0", verdict=allow, severity=alert, direction=to-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0
2023-11-02T16:49:58.932Z|00030|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Egress:0", verdict=allow, severity=alert, direction=from-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0
2023-11-02T16:49:58.932Z|00031|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Ingress:0", verdict=allow, severity=alert, direction=to-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0

4.7. namespace の Egress ファイアウォールとネットワークポリシーの監査ログを無効にする
リンクのコピー

クラスター管理者は、namespace の監査ログを無効にすることができます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてクラスターにログインする。

手順

  • namespace の監査ログを無効にするには、次のコマンドを入力します。 

    $ oc annotate --overwrite namespace <namespace> k8s.ovn.org/acl-logging-

    ここでは、以下のようになります。

    <namespace>
    namespace の名前を指定します。
    ヒント

    監査ロギングを無効にするには、次の YAML を適用することもできます。 

    kind: Namespace
apiVersion: v1
metadata:
  name: <namespace>
  annotations:
    k8s.ovn.org/acl-logging: null

    成功した出力には、監査ロギング名と annotated ステータスがリスト表示されます。

第5章 Egress ファイアウォール
リンクのコピー

5.1. プロジェクトの Egress ファイアウォールの表示
リンクのコピー

クラスター管理者は、既存の egress ファイアウォールの名前をリスト表示し、特定の egress ファイアウォールのトラフィックルールを表示できます。

5.1.1. EgressFirewall カスタムリソース (CR) の表示
リンクのコピー

クラスター内の EgressFirewall CR を表示できます。

前提条件

  • OVN-Kubernetes ネットワークプラグインを使用するクラスター。
  • oc として知られる OpenShift コマンドラインインターフェイス (CLI) のインストール。
  • クラスターにログインすること。

手順

  1. オプション: クラスターで定義されている EgressFirewall CR の名前を表示するには、次のコマンドを入力します。 

    $ oc get egressfirewall --all-namespaces

  2. ポリシーを検査するには、以下のコマンドを入力します。<policy_name> を検査するポリシーの名前に置き換えます。 

    $ oc describe egressfirewall <policy_name>

    出力例

    Name:		default
Namespace:	project1
Created:	20 minutes ago
Labels:		<none>
Annotations:	<none>
Rule:		Allow to 1.2.3.0/24
Rule:		Allow to www.example.com
Rule:		Deny to 0.0.0.0/0

5.2. プロジェクトの Egress ファイアウォールの編集
リンクのコピー

クラスター管理者は、既存の Egress ファイアウォールのネットワークトラフィックルールを変更できます。

5.2.1. EgressFirewall カスタムリソース (CR) の編集
リンクのコピー

クラスター管理者は、プロジェクトの Egress ファイアウォールを更新できます。

前提条件

  • OVN-Kubernetes ネットワークプラグインを使用するクラスター。
  • OpenShift CLI (oc) がインストールされている。
  • クラスター管理者としてクラスターにログインする必要があります。

手順

  1. プロジェクトの EgressFirewall CR の名前を検索します。<project> はプロジェクトの名前に置き換えます。 

    $ oc get -n <project> egressfirewall

  2. オプション: Egress ネットワークファイアウォールを作成したときに EgressFirewall オブジェクトのコピーを保存しなかった場合は、次のコマンドを入力してコピーを作成します。 

    $ oc get -n <project> egressfirewall <name> -o yaml > <filename>.yaml

    <project> はプロジェクトの名前に置き換えます。<name> はオブジェクトの名前に置き換えます。<filename> は YAML を保存するファイルの名前に置き換えます。

  3. ポリシールールを変更した後、次のコマンドを入力して EgressFirewall CR を置き換えます。<filename> は、更新した EgressFirewall CR が含まれているファイルの名前に置き換えます。 

    $ oc replace -f <filename>.yaml

5.3. プロジェクトからの Egress ファイアウォールの削除
リンクのコピー

クラスター管理者は、プロジェクトから Egress ファイアウォールを削除して、OpenShift Container Platform クラスター外に出るプロジェクトからネットワークトラフィックに対するすべての制限を削除できます。

5.3.1. EgressFirewall CR の削除
リンクのコピー

クラスター管理者は、プロジェクトから Egress ファイアウォールを削除できます。

前提条件

  • OVN-Kubernetes ネットワークプラグインを使用するクラスター。
  • OpenShift CLI (oc) がインストールされている。
  • クラスター管理者としてクラスターにログインする必要があります。

手順

  1. プロジェクトの EgressFirewall CR の名前を検索します。<project> はプロジェクトの名前に置き換えます。 

    $ oc get egressfirewall -n <project>

  2. 次のコマンドを入力して、EgressFirewall CR を削除します。<project> をプロジェクトの名前に、<name> をオブジェクトの名前に置き換えます。 

    $ oc delete -n <project> egressfirewall <name>

5.4. プロジェクトの Egress ファイアウォールの設定
リンクのコピー

クラスター管理者は、OpenShift Container Platform クラスター外に出る Egress トラフィックを制限するプロジェクトの Egress ファイアウォールを作成できます。

5.4.1. Egress ファイアウォールのプロジェクトでの機能
リンクのコピー

クラスター管理者は、Egress ファイアウォール を使用して、一部またはすべての Pod がクラスター内からアクセスできる外部ホストを制限できます。Egress ファイアウォールポリシーは以下のシナリオをサポートします。

  • Pod の接続を内部ホストに制限し、パブリックインターネットへの接続を開始できないようにする。
  • Pod の接続をパブリックインターネットに制限し、OpenShift Container Platform クラスター外にある内部ホストへの接続を開始できないようにする。
  • OpenShift Container Platform クラスター外にある指定された内部サブネットまたはホストに Pod が到達できないようにする。
  • Pod の接続先を特定の外部ホストに制限する。

たとえば、指定された IP 範囲へのあるプロジェクトへのアクセスを許可する一方で、別のプロジェクトへの同じアクセスを拒否することができます。または、アプリケーション開発者が Python pip ミラーから更新するのを制限し、承認されたソースからのみ更新が行われるように強制することもできます。

EgressFirewall カスタムリソース (CR) を作成して、Egress ファイアウォールポリシーを設定します。Egress ファイアウォールは、以下のいずれかの基準を満たすネットワークトラフィックと一致します。

  • CIDR 形式の IP アドレス範囲。
  • IP アドレスに解決する DNS 名
  • ポート番号
  • プロトコル。TCP、UDP、および SCTP のいずれかになります。
5.4.1.1. Egress ファイアウォールの制限
リンクのコピー

Egress ファイアウォールには以下の制限があります。

  • プロジェクトに複数の EgressFirewall CR を含めることはできません。
  • Egress ファイアウォールルールは、ルーターを通過するトラフィックには適用されません。Route CR オブジェクトを作成する権限を持つユーザーは、禁止された宛先を指すルートを作成することにより、Egress ファイアウォールポリシールールを回避できます。
  • Egress ファイアウォールは、ホストネットワークの namespace には適用されません。ホストネットワークが有効になっている Pod は、Egress ファイアウォールルールの影響を受けません。

  • Egress ファイアウォールに 0.0.0.0/0 の拒否ルールが含まれる場合、OpenShift Container Platform API サーバーへのアクセスはブロックされます。API サーバーに接続するには、IP アドレスごとに許可ルールを追加するか、Egress ポリシールールで nodeSelector タイプの許可ルールを使用する必要があります。

    次の例は、API サーバーへのアクセスを確保するために必要な Egress ファイアウォールルールの順序を示しています。 

    apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: default
  namespace: <namespace>
spec:
  egress:
  - to:
      cidrSelector: <api_server_address_range>
    1 
    
    type: Allow
# ...
  - to:
      cidrSelector: 0.0.0.0/0
    2 
    
    type: Deny

    ここでは、以下のようになります。

    <namespace>
    Egress ファイアウォールの namespace を指定します。
    <api_server_address_range>
    OpenShift Container Platform API サーバーを含む IP アドレス範囲を指定します。
    <cidrSelector>

    OpenShift Container Platform API サーバーへのアクセスを禁止するグローバル拒否ルールを設定するには、0.0.0.0/0 という値を指定します。

    API サーバーの IP アドレスを見つけるには、oc get ep kubernetes -n default を実行します。

    詳細は、BZ#1988324 を参照してください。

  • プロジェクトごとに、最大 8,000 件のルールを含む EgressFirewall オブジェクトを最大 1 つ定義できます。
  • Red Hat OpenShift Networking で OVN-Kubernetes ネットワークプラグインを共有ゲートウェイモードで使用している場合、戻りの Ingress 応答が Egress ファイアウォールルールの影響を受けます。Egress ファイアウォールルールによって Ingress 応答の宛先 IP がドロップされると、トラフィックがドロップされます。
  • 一般に、Egress ファイアウォールポリシーでドメインネームサーバー (DNS) 名を使用しても、CoreDNS を介したローカル DNS 解決には影響しません。ただし、Egress ファイアウォールポリシーでドメイン名が使用されており、影響を受ける Pod の DNS 解決を外部 DNS サーバーが処理する場合は、DNS サーバーの IP アドレスへのアクセスを許可する Egress ファイアウォールルールを含める必要があります。

これらの制限のいずれかに違反すると、プロジェクトの Egress ファイアウォールが壊れます。その結果、すべての外部ネットワークトラフィックがドロップされ、組織にセキュリティーリスクが生じる可能性があります。

EgressFirewall リソースは、kube-node-lease、kube-public、kube-system、openshift、および openshift- プロジェクトに作成されます。

5.4.1.2. Egress ポリシールールのマッチング順序
リンクのコピー

OVN-Kubernetes は、Egress ファイアウォールポリシールールを、最初から最後まで、定義された順序で評価します。Pod からの Egress 接続に一致する最初のルールが適用されます。この接続では、後続のルールは無視されます。

5.4.1.3. DNS (Domain Name Server) 解決の仕組み
リンクのコピー

Egress ファイアウォールポリシールールのいずれかで DNS 名を使用する場合、ドメイン名の適切な解決には、以下の制限が適用されます。

  • ドメイン名の更新は、Time-to-Live (TTL) 期間に基づいてポーリングされます。デフォルトで、期間は 30 分です。Egress ファイアウォールコントローラーがローカルネームサーバーでドメイン名をクエリーする場合に、応答に 30 分未満の TTL が含まれる場合、コントローラーは DNS 名の期間を返される値に設定します。それぞれの DNS 名は、DNS レコードの TTL の期限が切れた後にクエリーされます。
  • Pod は、必要に応じて同じローカルネームサーバーからドメインを解決する必要があります。そうしない場合、Egress ファイアウォールコントローラーと Pod によって認識されるドメインの IP アドレスが異なる可能性があります。ホスト名の IP アドレスが異なる場合、Egress ファイアウォールは一貫して実行されないことがあります。
  • Egress ファイアウォールコントローラーおよび Pod は同じローカルネームサーバーを非同期にポーリングするため、Pod は Egress コントローラーが実行する前に更新された IP アドレスを取得する可能性があります。これにより、競合状態が生じます。この現時点の制限により、EgressFirewall オブジェクトのドメイン名の使用は、IP アドレスの変更が頻繁に生じないドメインの場合にのみ推奨されます。
5.4.1.3.1. DNS 解決とワイルドカードドメイン名の解決の改善
リンクのコピー

DNS レコードに関連付けられた IP アドレスが頻繁に変更される場合や、Egress ファイアウォールポリシールールでワイルドカードドメイン名を指定する必要がある場合もあります。

このような状況では、OVN-Kubernetes クラスターマネージャーは、Egress ファイアウォールポリシールールで使用される一意の DNS 名ごとに DNSNameResolver カスタムリソースオブジェクトを作成します。このカスタムリソースには次の情報が保存されます。

重要

Egress ファイアウォールルールの DNS 解決の改善は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

DNSNameResolver CR 定義の例

apiVersion: networking.openshift.io/v1alpha1
kind: DNSNameResolver
spec:
  name: www.example.com.
status:
  resolvedNames:
  - dnsName: www.example.com.
    resolvedAddress:
    - ip: "1.2.3.4"
      ttlSeconds: 60
      lastLookupTime: "2023-08-08T15:07:04Z"

ここでは、以下のようになります。

<name>
DNS 名を示します。これは、標準の DNS 名またはワイルドカード DNS 名のいずれかになります。ワイルドカード DNS 名の場合、DNS 名解決情報には、ワイルドカード DNS 名に一致するすべての DNS 名が含まれます。
<dnsName>
spec.name フィールドに一致する解決済みの DNS 名を示します。spec.name フィールドにワイルドカード DNS 名が含まれている場合、解決時にワイルドカード DNS 名と一致する標準 DNS 名を含む複数の dnsName エントリーが作成されます。ワイルドカード DNS 名も正常に解決できる場合は、このフィールドには、ワイルドカード DNS 名も格納されます。<ip> DNS 名に関連付けられている現在の IP アドレスを示します。
<ttlSeconds>
直近の Time-to-Live (TTL) の期間を示します。
<lastLookupTime>
直近の検索時刻を示します。

DNS 解決中に、クエリー内の DNS 名が DNSNameResolver CR で定義された名前と一致する場合、CR status フィールドで以前の情報がそれに応じて更新されます。DNS ワイルドカード名のルックアップが失敗した場合、デフォルトの TTL である 30 分後に要求が再試行されます。

OVN-Kubernetes クラスターマネージャーは、EgressFirewall カスタムリソースオブジェクトの更新を監視し、更新が発生すると、それらの Egress ファイアウォールポリシーに関連付けられた DNSNameResolver CR を作成、変更、または削除します。

警告

DNSNameResolver カスタムリソースを直接変更しないでください。これにより、Egress ファイアウォールの望ましくない動作が発生する可能性があります。

5.4.2. EgressFirewall カスタムリソース (CR)
リンクのコピー

Egress ファイアウォールのルールを 1 つ以上定義できます。ルールは、ルールが適用されるトラフィックを指定して Allow ルールまたは Deny ルールのいずれかになります。

次の YAML は EgressFirewall CR を示しています。

EgressFirewall オブジェクト

apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: <ovn>
spec:
  egress: <egress_rules>
    ...

ここでは、以下のようになります。

<ovn>
オブジェクトの名前は default である必要があります。
<egress_rules>
次のセクションで説明するように、1 つ以上の Egress ネットワークポリシールールをまとめて指定します。
5.4.2.1. EgressFirewall ルール
リンクのコピー

次の YAML は、EgressFirewall リソースのルールを示しています。ユーザーは、CIDR 形式の IP アドレス範囲またはドメイン名を選択するか、nodeSelector フィールドを使用して、Egress トラフィックを許可または拒否できます。egress スタンザは、単一または複数のオブジェクトの配列を予想します。

Egress ポリシールールのスタンザ

egress:
- type: <type>
  to:
    cidrSelector: <cidr_range>
    dnsName: <dns_name>
    nodeSelector: <label_name>: <label_value>
  ports: <optional_port>
      ...

ここでは、以下のようになります。

<type>
ルールの種類を指定します。値には Allow または Deny のいずれかを指定する必要があります。
<to>
cidrSelector フィールドまたは dnsName フィールドを指定する Egress トラフィックの一致ルールを記述するためのスタンザを指定します。同じルールで両方のフィールドを使用することはできません。
<cidr_range>
CIDR 形式の IP アドレス範囲を指定します。
<dns_name>
DNS ドメイン名を指定します。
<nodeSelector>
ユーザーが定義するキーと値のペアであるラベルを指定します。ラベルは Pod などのオブジェクトに添付されます。nodeSelector を使用すると、1 つ以上のノードラベルを選択して、Pod に添付できます。
<ports>
このルールのネットワークポートとプロトコルをまとめて記述するオプションのフィールドを指定します。

ports スタンザ

ports:
- port:
  protocol:

ここでは、以下のようになります。

<port>
80 や 443 などのネットワークポートを指定します。このフィールドに値を指定する場合は、protocol フィールドにも値を指定する必要があります。
<protocol>
ネットワークプロトコルを指定します。値は TCP、UDP、または SCTP のいずれかである必要があります。
5.4.2.2. EgressFirewall CR の例
リンクのコピー

以下の例では、複数の Egress ファイアウォールポリシールールを定義します。 

apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: default
spec:
  egress:
1 

  - type: Allow
    to:
      cidrSelector: 1.2.3.0/24
  - type: Deny
    to:
      cidrSelector: 0.0.0.0/0

ここでは、以下のようになります。

<egress>
Egress ファイアウォールポリシールールのオブジェクトをまとめて指定します。

次の例では、トラフィックが TCP プロトコルおよび宛先ポート 80 または任意のプロトコルおよび宛先ポート 443 のいずれかを使用している場合に、IP アドレス 172.16.1.1/32 のホストへのトラフィックを拒否するポリシールールを定義します。 

apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: default
spec:
  egress:
  - type: Deny
    to:
      cidrSelector: 172.16.1.1/32
    ports:
    - port: 80
      protocol: TCP
    - port: 443
5.4.2.3. nodeSelector を使用した EgressFirewall CR の例
リンクのコピー

クラスター管理者は、nodeSelector フィールドを使用してラベルを指定することにより、クラスター内のノードへの Egress トラフィックを許可または拒否できます。ラベルは、1 つ以上のノードに適用できます。ラベルは便利です。ノードの IP アドレスごとに手動でルールを追加する代わりに、ノードセレクターを使用して、Egress ファイアウォールの背後にある Pod からホストネットワーク上の Pod へのアクセスを許可するラベルを作成できるためです。以下は、region=east ラベルを使用した例です。 

apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: default
spec:
    egress:
    - to:
        nodeSelector:
          matchLabels:
            region: east
      type: Allow

5.4.3. EgressFirewall カスタムリソース (CR) の作成
リンクのコピー

クラスター管理者は、プロジェクトの Egress ファイアウォールポリシーオブジェクトを作成できます。

重要

プロジェクトにすでに EgressFirewall リソースがある場合は、既存のポリシーを編集して、Egress ファイアウォールルールを変更する必要があります。

前提条件

  • OVN-Kubernetes ネットワークプラグインを使用するクラスター。
  • OpenShift CLI (oc) がインストールされている。
  • クラスター管理者としてクラスターにログインする必要があります。

手順

  1. ポリシールールを作成します。

    1. <policy_name>.yaml ファイルを作成します。この場合、<policy_name> は Egress ポリシールールを記述します。
    2. ファイル内に EgressFirewall オブジェクトを定義します。

  2. 次のコマンドを入力してポリシーオブジェクトを作成します。<policy_name> をポリシーの名前に、<project> をルールが適用されるプロジェクトに置き換えます。 

    $ oc create -f <policy_name>.yaml -n <project>

    正常な出力には、egressfirewall.k8s.ovn.org/v1 の名前と created ステータスが表示されます。

  3. オプション: 後に変更できるように <policy_name>.yaml ファイルを保存します。

第6章 IPsec 暗号化の設定
リンクのコピー

IPsec を有効にすると、ノード間の内部 Pod 間のクラスタートラフィックと、Pod とクラスター外部の IPsec エンドポイント間の外部トラフィックの両方を暗号化できます。OVN-Kubernetes クラスターネットワーク上のノード間のすべての Pod 間ネットワークトラフィックが、トランスポートモード の IPsec で暗号化されます。

IPsec はデフォルトで無効にされています。クラスターのインストール中またはインストール後に IPsec を有効にできます。クラスターのインストールの詳細は、OpenShift Container Platform インストールの概要 を参照してください。

注記

libreswan および NetworkManager-libreswan パッケージの OpenShift Container Platform バージョンが異なる場合にクラスターを OpenShift Container Platform 4.20 にアップグレードすると、2 回連続してコンピュートノードの再起動操作が発生します。最初の再起動では、Cluster Network Operator (CNO) が IPsec 設定をコンピューティングノードに適用します。2 回目の再起動では、Machine Config Operator (MCO) が最新のマシン設定をクラスターに適用します。

CNO と MCO の更新を 1 つのノードの再起動に結合するには、次のタスクを実行します。

  • クラスターをアップグレードする前に、コンピュートノードをグループ化する MachineConfigPools カスタムリソース (CR) で paused パラメーターを true に設定します。
  • クラスターをアップグレードした後、パラメーターを false に設定します。

詳細は、コントロールプレーンのみの更新の実行 を参照してください。

OpenShift Container Platform クラスター上の IPsec には次のサポート制限があります。

  • IBM Cloud® では、IPsec はネットワークアドレス変換トラバーサル (NAT-T) のみをサポートします。このプラットフォームでは、Encapsulating Security Payload (ESP) はサポートされていません。
  • クラスターが Red Hat OpenShift Container Platform の Hosted Control Plane を使用している場合、IPsec は、Pod 間のトラフィックや外部ホストへのトラフィックの IPsec 暗号化でサポートされません。
  • 1 つ以上のネットワークインターフェイスが Open vSwitch (OVS) に接続されている場合、ネットワークインターフェイスでの ESP ハードウェアオフロードの使用はサポートされません。クラスターに対して IPsec を有効にすると、OVS に接続されたインターフェイスで IPsec が使用されるようになります。デフォルトでは、OpenShift Container Platform は、OVS に接続されたすべてのインターフェイスで ESP ハードウェアオフロードを無効にします。
  • OVS に接続されていないネットワークインターフェイスに対して IPsec を有効にした場合、クラスター管理者は、OVS に接続されていない各インターフェイスで ESP ハードウェアオフロードを手動で無効にする必要があります。

次のリストは、IPsec ドキュメントの主要なタスクの概要を示しています。

  • クラスターのインストール後に IPsec を有効または無効にする
  • クラスターと外部ホスト間のトラフィックの IPsec 暗号化を設定する
  • IPsec が異なるノード上の Pod 間のトラフィックを暗号化することを確認する

6.1. 動作モード
リンクのコピー

OpenShift Container Platform クラスターで IPsec を使用する場合、以下の動作モードから選択できます。

Expand
表6.1 IPsec の動作モード
Mode説明デフォルト

Disabled

トラフィックは暗号化されません。これはクラスターのデフォルトです。

はい

Full

Pod 間のトラフィックが、「Pod 間の IPsec によって暗号化されるネットワークトラフィックフローのタイプ」の説明のとおりに暗号化されます。IPsec に必要な設定手順を完了すると、外部ノードへのトラフィックを暗号化できます。

いいえ

External

IPsec に必要な設定手順を完了すると、外部ノードへのトラフィックを暗号化できます。

いいえ

6.2. 前提条件
リンクのコピー

外部ホストへのトラフィックを暗号化するために IPsec をサポートする場合は、次の前提条件が満たされていることを確認してください。

  • OVN-Kubernetes ネットワークプラグインの ovnKubernetesConfig.gatewayConfig 仕様で routingViaHost=true を設定する。

  • NMState Operator をインストールする。この Operator は、IPsec 設定を指定するために必要です。詳細は、Kubernetes NMState Operator を参照してください。

    注記

    NMState Operator は、Google Cloud で IPsec を設定する場合にのみサポートされます。

  • Butane ツール (butane) がインストールされている。Butane をインストールするには、Butane のインストール を参照してください。

これらの前提条件は、証明書をホストの NSS データベースに追加するために、および外部ホストと通信するように IPsec を設定するために必要です。

6.3. IPsec が有効になっている場合のネットワーク接続要件
リンクのコピー

OpenShift Container Platform クラスターのコンポーネントが通信できるように、マシン間のネットワーク接続を設定する必要があります。すべてのマシンではクラスターの他のすべてのマシンのホスト名を解決できる必要があります。

Expand
表6.2 すべてのマシンからすべてのマシンへの通信に使用されるポート
プロトコルポート説明

UDP

500

IPsec IKE パケット

4500

IPsec NAT-T パケット

ESP

該当なし

IPsec Encapsulating Security Payload (ESP)

6.4. Pod 間のトラフィックの IPsec 暗号化
リンクのコピー

Pod 間のトラフィックの IPsec 暗号化は、次のセクションで、暗号化される Pod 間のトラフィック、使用される暗号化プロトコルの種類、および X.509 証明書の処理の仕組みを説明します。以下のセクションは、クラスターと外部ホスト間の IPsec 暗号化には適用されません。この種の暗号化は、特定の外部ネットワークインフラストラクチャーに合わせて手動で設定する必要があります。

6.4.1. Pod 間の IPsec によって暗号化されるネットワークトラフィックフローのタイプ
リンクのコピー

IPsec を有効にすると、Pod 間の以下のネットワークトラフィックフローのみが暗号化されます。

  • クラスターネットワーク上の複数の異なるノードの Pod 間のトラフィック
  • ホストネットワークの Pod からクラスターネットワーク上の Pod へのトラフィック

以下のトラフィックフローは暗号化されません。

  • クラスターネットワーク上の同じノードの Pod 間のトラフィック
  • ホストネットワーク上の Pod 間のトラフィック
  • クラスターネットワークの Pod からホストネットワークの Pod へのトラフィック

暗号化されていないフローと暗号化されていないフローを以下の図に示します。

IPsec の暗号化および暗号化されていないトラフィックフロー

6.4.2. 暗号化プロトコルおよび IPsec モード
リンクのコピー

使用する暗号化は AES-GCM-16-256 です。整合性チェック値 (ICV) は 16 バイトです。鍵の長さは 256 ビットです。

使用される IPsec モードは トランスポートモード です。これは、元のパケットの IP ヘッダーに Encapsulated Security Payload (ESP) ヘッダーを追加してパケットデータを暗号化することで、エンドツーエンドの通信を暗号化するモードです。OpenShift Container Platform は現在、Pod 間通信に IPsec Tunnel モード を使用したり、サポートしたりしません。

6.4.3. セキュリティー証明書の生成およびローテーション
リンクのコピー

Cluster Network Operator (CNO) は、暗号化用に IPsec によって使用される自己署名の X.509 認証局 (CA) を生成します。各ノードの証明書署名要求 (CSR) は、CNO によって自動的に満たされます。

この CA は 10 年間有効です。個別のノード証明書は 5 年間有効で、4 年半が経過すると自動的にローテーションされます。

6.5. 外部トラフィックの IPsec 暗号化
リンクのコピー

OpenShift Container Platform は、外部ホスト宛のトラフィックを暗号化するために IPsec を使用することをサポートしています。これにより、転送中のデータの機密性と整合性が確保されます。この機能を利用するには、ユーザーが X.509 証明書を提供する必要があります。

6.5.1. サポートされているプラットフォーム
リンクのコピー

この機能は次のプラットフォームでサポートされています。

  • ベアメタル
  • Google Cloud
  • Red Hat OpenStack Platform (RHOSP)
  • VMware vSphere
重要

Red Hat Enterprise Linux (RHEL) コンピュートノードがある場合、これらのプラットフォームは外部トラフィックの IPsec 暗号化をサポートしません。

クラスターが Red Hat OpenShift Container Platform の Hosted Control Plane を使用している場合、外部ホストへのトラフィックを暗号化するための IPsec の設定はサポートされません。

6.5.2. 制限事項
リンクのコピー

次の禁止事項が遵守されていることを確認してください。

  • 外部トラフィックの IPsec を設定する場合、IPv6 設定は現在 NMState Operator によってサポートされません。
  • 提供する証明書バンドル内の証明書共通名 (CN) には、接頭辞 ovs_ を指定できません。この名前は、各ノードのネットワークセキュリティーサービス (NSS) データベース内の Pod 間の IPsec CN 名と競合する可能性があるためです。

6.6. IPsec 暗号化の有効化
リンクのコピー

クラスター管理者は、クラスターと外部 IPsec エンドポイント間の Pod 間 IPsec 暗号化を有効化できます。

次のいずれかのモードで IPsec を設定できます。

  • Full: Pod 間のトラフィックおよび外部トラフィックの暗号化
  • External: 外部トラフィックの暗号化
注記

IPsec を Full モードで設定する場合は、「外部トラフィックの IPsec 暗号化の設定」手順も完了する必要があります。

IPsec を Full モードで有効化した場合、クラスター管理者は、full スキーマを networks.operator.openshift.io に追加することで、モードのオプションを設定できます。full スキーマは encapsulation パラメーターをサポートします。このパラメーターを使用して、IPsec トラフィックのネットワークアドレス変換トラバーサル (NAT-T) カプセル化を設定できます。encapsulation パラメーターは次の値をサポートします。

  • Auto はデフォルト値であり、libreswan がノード内のトラフィックでネットワークアドレス変換 (NAT) パケットを検出すると、UDP カプセル化を有効にします。
  • Always は、ノードで利用可能なすべてのトラフィックタイプに対して、UDP カプセル化を有効にします。このオプションは、ノード内の NAT パケットを検出する際に libreswan に依存しません。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてクラスターにログインしている。
  • クラスター MTU のサイズを 46 バイト減らして、IPsec ESP ヘッダーにオーバーヘッドを設けている。

手順

  1. IPsec 暗号化を有効にするには、次のコマンドを入力します。 

    $ oc patch networks.operator.openshift.io cluster --type=merge -p \
  '{
  "spec":{
    "defaultNetwork":{
      "ovnKubernetesConfig":{
        "ipsecConfig":{
          "mode":"<mode">
    1 
    
        }}}}}'
    1 1
    外部ホストへのトラフィックを暗号化するには External を指定します。Pod 間のトラフィックを暗号化し、必要に応じて外部ホストへのトラフィックを暗号化するには Full を指定します。デフォルトでは、IPsec は無効になっています。

    IPsec が Full モードで有効化され、encapsulation が Always に設定されている場合の設定例

    $ oc patch networks.operator.openshift.io cluster --type=merge -p \
  '{
  "spec":{
    "defaultNetwork":{
      "ovnKubernetesConfig":{
        "ipsecConfig":{
          "mode":"Full",
          "full":{
            "encapsulation": "Always"
          }}}}}}'

  2. 「外部トラフィックの IPsec 暗号化の設定」手順を完了して、IPsec を使用して外部トラフィックを暗号化します。

検証

  1. OVN-Kubernetes データプレーン Pod の名前を見つけるには、次のコマンドを入力します。 

    $ oc get pods -n openshift-ovn-kubernetes -l=app=ovnkube-node

    出力例

    ovnkube-node-5xqbf                       8/8     Running   0              28m
ovnkube-node-6mwcx                       8/8     Running   0              29m
ovnkube-node-ck5fr                       8/8     Running   0              31m
ovnkube-node-fr4ld                       8/8     Running   0              26m
ovnkube-node-wgs4l                       8/8     Running   0              33m
ovnkube-node-zfvcl                       8/8     Running   0              34m
...

  2. 次のコマンドを実行して、クラスターで IPsec が有効になっていることを確認します。

    注記

    クラスター管理者は、IPsec を Full モードで設定した際に、クラスター上の Pod 間で IPsec を有効化したことを確認できます。この手順では、クラスターと外部ホストの間で IPsec が機能しているかどうかは検証されません。 

    $ oc -n openshift-ovn-kubernetes rsh ovnkube-node-<XXXXX> ovn-nbctl --no-leader-only get nb_global . ipsec
    1

    ここで、<XXXXX> は、前のステップの Pod のランダムな文字シーケンスを指定します。

    コマンドからの正常な出力には、ステータスが true と表示されます。

6.7. 外部トラフィックの IPsec 暗号化の設定
リンクのコピー

クラスター管理者は、IPsec を使用して外部トラフィックを暗号化するには、PKCS#12 証明書の提供を含め、ネットワークインフラストラクチャーに IPsec を設定する必要があります。この手順では Butane を使用してマシン設定を作成するため、butane ツールがインストールされている必要があります。

注記

マシン設定を適用すると、Machine Config Operator (MCO) により、クラスター内の影響を受けるノードが再起動され、新しいマシン設定がロールアウトされます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • ローカルコンピューターに butane ツールされている。
  • NMState Operator がクラスターにインストールされている。
  • cluster-admin 権限を持つユーザーとしてクラスターにログインしている。
  • IPsec エンドポイント用の既存の PKCS#12 証明書と、Privacy Enhanced Mail (PEM) 形式の CA 証明書がある。
  • クラスターで Full または External モードの IPsec が有効になっている。
  • OVN-Kubernetes ネットワークプラグインの ovnKubernetesConfig.gatewayConfig 仕様で、routingViaHost パラメーターを true に設定する。

手順

  1. NMState Operator ノードネットワーク設定ポリシーを使用して IPsec 設定を作成します。詳細は、nmstatectl を使用して IPsec ベースの VPN 接続を設定する 参照してください。

    1. IPsec エンドポイントであるクラスターノードの IP アドレスを特定するために、次のコマンドを入力します。 

      $ oc get nodes

    2. 次の例のように、NMState Operator のノードネットワーク設定ポリシーを含む ipsec-config.yaml という名前のファイルを作成します。NodeNetworkConfigurationPolicy オブジェクトの概要は、The Kubernetes NMState project を参照してください。

      NMState IPsec トランスポート設定の例

      apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: ipsec-config
spec:
  nodeSelector:
    kubernetes.io/hostname: "<hostname>"
  desiredState:
    interfaces:
    - name: <interface_name>
      type: ipsec
      libreswan:
        left: <cluster_node>
        leftid: '%fromcert'
        leftrsasigkey: '%cert'
        leftcert: left_server
        leftmodecfgclient: false
        right: <external_host>
        rightid: '%fromcert'
        rightrsasigkey: '%cert'
        rightsubnet: <external_address>/32
        ikev2: insist
        type: transport

      ここでは、以下のようになります。

      kubernetes.io/hostname
      ポリシーを適用するホスト名を指定します。このホストは、IPsec 設定の左側のホストとして機能します。
      name
      ホスト上に作成するインターフェイスの名前を指定します。
      left
      クラスター側で IPsec トンネルを終端するクラスターノードのホスト名を指定します。この名前は、提供した PKCS#12 証明書の SAN [Subject Alternate Name] と一致する必要があります。
      right
      外部ホスト名 (host.example.com など) を指定します。この名前は、提供した PKCS#12 証明書の SAN [Subject Alternate Name] と一致する必要があります。
      rightsubnet

      外部ホストの IP アドレス (10.1.2.3/32 など) を指定します。

      NMState IPsec トンネル設定の例

      apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: ipsec-config
spec:
  nodeSelector:
    kubernetes.io/hostname: "<hostname>"
  desiredState:
    interfaces:
    - name: <interface_name>
      type: ipsec
      libreswan:
        left: <cluster_node>
        leftid: '%fromcert'
        leftmodecfgclient: false
        leftrsasigkey: '%cert'
        leftcert: left_server
        right: <external_host>
        rightid: '%fromcert'
        rightrsasigkey: '%cert'
        rightsubnet: <external_address>/32
        ikev2: insist
        type: tunnel

    3. IPsec インターフェイスを設定するために、次のコマンドを入力します。 

      $ oc create -f ipsec-config.yaml

  2. 次の証明書ファイルを提供して、各ホストのネットワークセキュリティーサービス (NSS) データベースに追加します。これらのファイルは、次のステップで Butane 設定の一部としてインポートされます。

    • left_server.p12: IPsec エンドポイントの証明書バンドル
    • ca.pem: 証明書に署名した認証局
  3. 証明書をクラスターに追加するためのマシン設定を作成します。

  4. マウントされたシークレットファイルからパスワードを読み取ります。 

    $ password=$(cat run/secrets/<left_server_password>)
    • left_server_password:: パスワードが含まれているファイルの名前。このファイルはマウントされたシークレット内に存在します。

  5. 次のコマンドを入力して、Red Hat Enterprise Linux (RHEL) に同梱されている pk12util ツールを使用し、PKCS#12 ファイルを保護しているパスワードを指定します。<password> 値を自分のパスワードに置き換えてください。 

    $ pk12util -W "<password>" -i /etc/pki/certs/left_server.p12 -d /var/lib/ipsec/nss/

  6. コントロールプレーンとコンピュートノードの Butane 設定ファイルを作成するには、次のコマンドを入力します。

    注記

    設定ファイルで指定する Butane のバージョン は、OpenShift Container Platform のバージョンと同じである必要があり、末尾は常に 0 です。たとえば、4.20.0 などです。Butane の詳細は、「Butane を使用したマシン設定の作成」を参照してください。 

    $ for role in master worker; do
  cat >> "99-ipsec-${role}-endpoint-config.bu" <<-EOF
  variant: openshift
  version: 4.20.0
  metadata:
    name: 99-${role}-import-certs
    labels:
      machineconfiguration.openshift.io/role: $role
  systemd:
    units:
    - name: ipsec-import.service
      enabled: true
      contents: |
        [Unit]
        Description=Import external certs into ipsec NSS
        Before=ipsec.service

        [Service]
        Type=oneshot
        ExecStart=/usr/local/bin/ipsec-addcert.sh
        RemainAfterExit=false
        StandardOutput=journal

        [Install]
        WantedBy=multi-user.target
  storage:
    files:
    - path: /etc/pki/certs/ca.pem
      mode: 0400
      overwrite: true
      contents:
        local: ca.pem
    - path: /etc/pki/certs/left_server.p12
      mode: 0400
      overwrite: true
      contents:
        local: left_server.p12
    - path: /usr/local/bin/ipsec-addcert.sh
      mode: 0740
      overwrite: true
      contents:
        inline: |
          #!/bin/bash -e
          echo "importing cert to NSS"
          certutil -A -n "CA" -t "CT,C,C" -d /var/lib/ipsec/nss/ -i /etc/pki/certs/ca.pem
          pk12util -W "" -i /etc/pki/certs/left_server.p12 -d /var/lib/ipsec/nss/
          certutil -M -n "left_server" -t "u,u,u" -d /var/lib/ipsec/nss/
EOF
done

  7. 前のステップで作成した Butane ファイルをマシン設定に変換するには、次のコマンドを入力します。 

    $ for role in master worker; do
  butane -d . 99-ipsec-${role}-endpoint-config.bu -o ./99-ipsec-$role-endpoint-config.yaml
done

  8. マシン設定をクラスターに適用するには、次のコマンドを入力します。 

    $ for role in master worker; do
  oc apply -f 99-ipsec-${role}-endpoint-config.yaml
done
    重要

    Machine Config Operator (MCO) は各マシン設定プール内のマシンを更新するときに、各ノードを 1 つずつ再起動します。外部 IPsec 接続が利用可能になるまで、すべてのノードが更新されるのを待つ必要があります。

検証

  1. 以下のコマンドを実行してマシン設定プールのステータスを確認します。 

    $ oc get mcp

    正常に更新されたノードには、UPDATED=true、UPDATING=false、DEGRADED=false のステータスがあります。

    注記

    デフォルトで、MCO はプールごとに一度に 1 つのマシンを更新するため、移行にかかる合計時間がクラスターのサイズと共に増加します。

  2. IPsec マシン設定が正常にロールアウトされたことを確認するために、次のコマンドを入力します。

    1. IPsec マシン設定の作成を確認します。 

      $ oc get mc | grep ipsec

      出力例

      80-ipsec-master-extensions        3.2.0        6d15h
80-ipsec-worker-extensions        3.2.0        6d15h

    2. コントロールプレーンノードに IPsec 拡張機能が適用されたことを確認します。 

      $ oc get mcp master -o yaml | grep 80-ipsec-master-extensions -c

    3. コンピュートノードに IPsec 拡張機能が適用されたことを確認します。出力例には 2 と表示されます。 

      $ oc get mcp worker -o yaml | grep 80-ipsec-worker-extensions -c

6.9. 外部 IPsec エンドポイントの IPsec 暗号化の無効化
リンクのコピー

クラスター管理者は、外部ホストへの既存の IPsec トンネルを削除できます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてクラスターにログインしている。
  • クラスターで Full または External モードの IPsec が有効になっている。

手順

  1. 次の YAML を使用して、remove-ipsec-tunnel.yaml という名前のファイルを作成します。 

    kind: NodeNetworkConfigurationPolicy
apiVersion: nmstate.io/v1
metadata:
  name: <name>
spec:
  nodeSelector:
    kubernetes.io/hostname: <node_name>
  desiredState:
    interfaces:
    - name: <tunnel_name>
      type: ipsec
      state: absent

    ここでは、以下のようになります。

    name
    ノードネットワーク設定ポリシーの名前を指定します。
    node_name
    削除する IPsec トンネルが存在するノードの名前を指定します。
    tunnel_name
    既存の IPsec トンネルのインターフェイス名を指定します。

  2. IPsec トンネルを削除するために、次のコマンドを入力します。 

    $ oc apply -f remove-ipsec-tunnel.yaml

6.10. IPsec 暗号化の無効化
リンクのコピー

クラスター管理者は、IPsec 暗号化を無効にすることができます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてクラスターにログインしている。

手順

  1. IPsec 暗号化を無効にするには、次のいずれかのオプションを選択します。

    1. ipsecConfig.mode パラメーターが External または Full に設定され、ipsecConfig.full スキーマが networks.operator.openshift.io に追加されていない場合は、次のコマンドを入力します。 

      $ oc patch networks.operator.openshift.io cluster --type=merge -p \
  '{
  "spec":{
    "defaultNetwork":{
      "ovnKubernetesConfig":{
        "ipsecConfig":{
          "mode":"Disabled"
        }}}}}'

    2. ipsecConfig.mode パラメーターが Full に設定され、ipsecConfig.full 設定が networks.operator.openshift.io に追加されている場合は、次のコマンドを入力します。 

      $ oc patch networks.operator.openshift.io cluster --type='json' -p \
      '[{"op": "remove", "path": "/spec/defaultNetwork/ovnKubernetesConfig/ipsecConfig/full"},
      {"op": "replace", "path": "/spec/defaultNetwork/ovnKubernetesConfig/ipsecConfig/mode", "value": "Disabled"}]'
  2. オプション: IP パケット内の IPsec Encapsulating Security Payload (ESP) ヘッダーからのオーバーヘッドがなくなるため、クラスター MTU のサイズを 46 バイト増やすことができます。

第7章 ゼロトラストネットワーク
リンクのコピー

ゼロトラストは、すべてのインタラクションが信頼できない状態から始まるという前提に基づきセキュリティーアーキテクチャーを設計するアプローチです。これは、通信がファイアウォールの内側で開始されるかどうかに基づき信頼性を決定する従来のアーキテクチャーとは対照的です。より具体的には、ゼロトラストは、暗黙的信頼モデルと 1 回限りの認証に依存するセキュリティーアーキテクチャーのギャップを埋めようとします。

OpenShift Container Platform は、コンテナーやコンテナー内で実行されているソフトウェアを変更することなく、プラットフォーム上で実行されているコンテナーにゼロトラストネットワーク機能を追加できます。Red Hat は、コンテナーのゼロトラストネットワーキング機能をさらに強化できる製品もさらにいくつか提供しています。コンテナー内で実行されているソフトウェアを変更できる場合は、Red Hat がサポートする他のプロジェクトを使用して、さらに機能を追加できます。

以下は、ゼロトラストネットワークの対象となる機能の詳細です。

7.1. Root of Trust
リンクのコピー

公開証明書と秘密鍵はゼロトラストネットワークにとって重要です。これらは、各コンポーネントを相互に識別し、認証し、トラフィックを保護するために使用されます。証明書は他の証明書によって署名され、ルート認証局 (CA) への信頼チェーンが存在します。ネットワークに参加するすべてが、信頼チェーンを検証できるように、最終的にルート CA の公開鍵を持っている必要があります。一般に公開されている場合、通常は世界的に知られているルート CA のセットであり、その鍵はオペレーティングシステムや Web ブラウザーなどとともに配布されます。ただし、プライベート CA の証明書がすべての関係者に配布されている場合、クラスターまたは企業向けにプライベート CA を実行できます。

活用方法:

  • OpenShift Container Platform: OpenShift は、クラスターリソースの保護に使用される クラスター CA をインストール時 に作成します。ただし、OpenShift Container Platform は、クラスター内で サービス証明書 を作成して署名することもでき、そのクラスター CA バンドルを必要に応じて Pod に注入することもできます。OpenShift Container Platform によって作成および署名された サービス証明書 の有効期間 (TTL) は 26 カ月で、13 カ月ごとに自動的にローテーションされます。必要に応じて手動でローテーションすることも可能です。
  • OpenShift cert-manager Operator: cert-manager を使用すると、外部の root of trust によって署名された鍵を要求できます。委譲された署名証明書を使用して実行する方法の他に、外部発行者と統合するために設定できる発行者が多数あります。cert-manager API は、ゼロトラストネットワーク内の他のソフトウェア (Red Hat OpenShift Service Mesh など) が必要な証明書を要求するために使用することも、お客様のソフトウェアが直接使用することも可能です。

7.2. トラフィック認証と暗号化
リンクのコピー

回線上のすべてのトラフィックが暗号化され、エンドポイントが識別可能になります。一例として、相互認証方式である Mutual TLS (mTLS) が挙げられます。

活用方法:

  • OpenShift Container Platform: 透過的な Pod 間の IPsec を使用することで、トラフィックの送信元と送信先を IP アドレスで識別できます。Egress トラフィックを IPsec を使用して暗号化 する機能があります。Egress IP 機能を使用すると、トラフィックの送信元 IP アドレスを使用して、クラスター内のトラフィックの送信元を識別できます。
  • Red Hat OpenShift Service Mesh: Pod から送信されるトラフィックを透過的に拡張して認証と暗号化を提供する強力な mTLS 機能 を提供します。
  • OpenShift cert-manager Operator: カスタムリソース定義 (CRD) を使用して、プログラムが SSL/TLS プロトコルに使用するためにマウントできる証明書を要求します。

7.3. 識別と認証
リンクのコピー

CA を使用して証明書を作成できるようになると、それを使用して接続のもう一方の端 (ユーザーまたはクライアントマシン) のアイデンティティーを検証することで信頼関係を確立できるようになります。また、侵害された場合に使用を制限するために、証明書のライフサイクルを管理する必要もあります。

活用方法:

  • OpenShift Container Platform: クライアントが信頼済みエンドポイントと通信していることを確認するためのクラスター署名付き サービス証明書。これには、サービスが SSL/TLS を使用し、クライアントが クラスター CA を使用することが必要です。クライアントアイデンティティーは他の手段で提供する必要があります。
  • Red Hat Single Sign-On: エンタープライズユーザーディレクトリーまたはサードパーティーのアイデンティティープロバイダーとの要求認証インテグレーションを提供します。
  • Red Hat OpenShift Service Mesh: mTLS への接続の 透過的なアップグレード、自動ローテーション、カスタム証明書の有効期限、JSON Web トークン (JWT) による要求認証。
  • OpenShift cert-manager Operator: アプリケーションで使用する証明書の作成と管理。証明書は CRD により制御され、シークレットとしてマウントできます。また、cert-manager API と直接対話するようにアプリケーションを変更することもできます。

7.4. サービス間認可
リンクのコピー

リクエスト元のアイデンティティーに基づきサービスへのアクセスを制御できることが重要です。これはプラットフォームによって実行されるため、各アプリケーションで実装する必要はありません。これにより、ポリシーの監査と検査がより適切に行えるようになります。

活用方法:

  • OpenShift Container Platform: Kubernetes NetworkPolicy および AdminNetworkPolicy オブジェクトを使用して、プラットフォームのネットワーク層で分離を適用できます。
  • Red Hat OpenShift Service Mesh: 標準の Istio オブジェクトおよび mTLS を使用してトラフィックの送信元と宛先を識別し、その情報に基づきポリシーを適用する、高度な L4 および L7 の トラフィック制御。

7.5. トランザクションレベルの検証
リンクのコピー

接続の識別および認証機能に加えて、個々のトランザクションへのアクセスを制御するのにも役立ちます。これには、ソースによるレート制限、可観測性、トランザクションが適切に形成されていることのセマンティック検証などが含まれます。

活用方法:

7.6. リスク評価
リンクのコピー

クラスター内のセキュリティーポリシーの数が増えるにつれ、ポリシーが許可および拒否する内容の可視化がますます重要になります。これらのツールを使用すると、クラスターセキュリティーポリシーの作成、可視化、管理が容易になります。

活用方法:

7.7. サイト全体のポリシーの適用と配布
リンクのコピー

クラスターにアプリケーションをデプロイした後、セキュリティールールを構成するすべてのオブジェクトを管理することが困難になります。サイト全体にポリシーを適用し、デプロイしたオブジェクトがポリシーに準拠しているかどうかを監査することが重要になります。これにより、定義された範囲内でユーザーとクラスター管理者に一部の権限を委譲できるようになり、必要に応じてポリシーの例外も許可されるようになります。

活用方法:

7.8. 継続的かつ遡及的な評価のための可観測性
リンクのコピー

クラスターを実行した後は、トラフィックを観察し、トラフィックが定義したルールに準拠していることを確認する必要があります。これは侵入検知やフォレンジックのために重要であり、運用負荷管理にも役立ちます。

活用方法:

  • Network Observability Operator: クラスター内の Pod やノードへのネットワーク接続に関する検査、モニタリング、アラートを可能にします。
  • Red Hat Advanced Cluster Management (RHACM) for Kubernetes: プロセス実行、ネットワーク接続とフロー、権限昇格などのシステムレベルのイベントを監視、収集、評価します。クラスターのベースラインを決定し、異常なアクティビティーを検出して、それをユーザーに警告できます。
  • Red Hat OpenShift Service Mesh: Pod に出入りする トラフィックを監視 できます。
  • Red Hat OpenShift Distributed Tracing Platform: 適切に計装されたアプリケーションでは、特定のアクションがマイクロサービスへのサブリクエストに分割されるときに、そのアクションに関連するすべてのトラフィックを確認できます。これにより、分散アプリケーション内のボトルネックを特定できます。

7.9. エンドポイントセキュリティー
リンクのコピー

クラスター内のサービスを実行しているソフトウェアが侵害されていないことを確信できることが重要です。たとえば、認定されたイメージが信頼済みハードウェア上で実行されるようにし、エンドポイントの特性に基づいてエンドポイントとの間の接続のみを許可するポリシーを設定する必要がある場合があります。

活用方法:

  • OpenShift Container Platform: Secureboot を使用すると、クラスター内のノードが信頼済みのソフトウェアを実行していることを確認できるため、プラットフォーム自体 (コンテナーランタイムを含む) が改ざんされていないことを確認できます。OpenShift Container Platform を、特定の署名で署名された イメージのみを実行するように設定できます。
  • Red Hat Trusted Artifact Signer: 信頼済みビルドチェーンで使用でき、署名付きコンテナーイメージを生成できます。

7.10. クラスター外への信頼の拡張
リンクのコピー

クラスターによるサブドメインの CA 作成を許可することで、クラスター外部に信頼を拡張する必要がある場合があります。あるいは、クラスター内のワークロードアイデンティティーをリモートエンドポイントに証明する必要があることもあります。

活用方法:

  • OpenShift cert-manager Operator: cert-manager を使用して委譲された CA を管理し、クラスターをまたいで、もしくは組織全体で信頼を分散できます。
  • Red Hat OpenShift Service Mesh: SPIFFE を使用して、リモートまたはローカルクラスターで実行されているエンドポイントに、ワークロードのリモートアテステーションを提供できます。
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hatトップに戻る