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

21.3. プロジェクトの Egress ファイアウォールの設定

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

注記

OpenShift SDN CNI は、OpenShift Container Platform 4.14 以降非推奨になりました。OpenShift Container Platform 4.15 以降の新規インストールでは、ネットワークプラグインというオプションはなくなりました。今後のリリースでは、OpenShift SDN ネットワークプラグインは削除され、サポートされなくなる予定です。Red Hat は、この機能が削除されるまでバグ修正とサポートを提供しますが、この機能は拡張されなくなります。OpenShift SDN CNI の代わりに、OVN Kubernetes CNI を使用できます。詳細は、OpenShift SDN CNI の削除 を参照してください。

21.3.1. Egress ファイアウォールのプロジェクトでの機能

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

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

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

注記

Egress ファイアウォールは、ホストネットワークの namespace には適用されません。ホストネットワークが有効になっている Pod は、Egress ファイアウォールルールの影響を受けません。

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

  • CIDR 形式の IP アドレス範囲。
  • IP アドレスに解決する DNS 名
重要

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

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

apiVersion: network.openshift.io/v1
kind: EgressNetworkPolicy
metadata:
  name: default
  namespace: <namespace> 1
spec:
  egress:
  - to:
      cidrSelector: <api_server_address_range> 2
    type: Allow
# ...
  - to:
      cidrSelector: 0.0.0.0/0 3
    type: Deny
1
Egress ファイアウォールの namespace。
2
OpenShift Container Platform API サーバーを含む IP アドレス範囲。
3
グローバル拒否ルールにより、OpenShift Container Platform API サーバーへのアクセスが阻止されます。

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

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

重要

Egress ファイアウォールを設定するには、ネットワークポリシーまたはマルチテナントモードのいずれかを使用するように OpenShift SDN を設定する必要があります。

ネットワークポリシーモードを使用している場合、Egress ファイアウォールは namespace ごとに 1 つのポリシーとのみ互換性を持ち、グローバルプロジェクトなどのネットワークを共有するプロジェクトでは機能しません。

警告

Egress ファイアウォールルールは、ルーターを通過するトラフィックには適用されません。ルート CR オブジェクトを作成するパーミッションを持つユーザーは、禁止されている宛先を参照するルートを作成することにより、Egress ファイアウォールポリシールールをバイパスできます。

21.3.1.1. Egress ファイアウォールの制限

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

  • いずれのプロジェクトも複数の EgressNetworkPolicy オブジェクトを持つことができません。

    重要

    複数の EgressNetworkPolicy オブジェクトの作成は可能ですが、作成するべきではありません。複数の EgressNetworkPolicy オブジェクトを作成すると、dropping all rules というメッセージが返されます。実際には、すべての外部トラフィックがドロップされるため、組織にセキュリティーリスクが生じる可能性があります。

  • 最大 1,000 のルールを持つ最大 1 つの EgressNetworkPolicy オブジェクトはプロジェクトごとに定義できます。
  • default プロジェクトは Egress ファイアウォールを使用できません。

  • マルチテナントモードで OpenShift SDN ネットワークプラグインを使用する場合、以下の制限が適用されます。

    • グローバルプロジェクトは Egress ファイアウォールを使用できません。oc adm pod-network make-projects-global コマンドを使用して、プロジェクトをグローバルにすることができます。
    • oc adm pod-network join-projects コマンドを使用してマージされるプロジェクトでは、結合されたプロジェクトのいずれでも Egress ファイアウォールを使用することはできません。
  • セレクターレスサービスを作成し、外部 IP を参照するエンドポイントまたは EndpointSlices を手動で定義すると、EgressNetworkPolicy がすべての Egress トラフィックを拒否するように設定されている場合でも、サービス IP へのトラフィックが引き続き許可される可能性があります。これは、OpenShift SDN がこのような外部エンドポイントに対して Egress ネットワークポリシーを完全に適用していないために発生します。その結果、外部サービスへの予期しないアクセスが発生する可能性があります。

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

Egress ファイアウォールリソースは、kube-node-lease、kube-public、kube-system、openshift、openshift- プロジェクトで作成できます。

21.3.1.2. Egress ポリシールールのマッチング順序

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

21.3.1.3. DNS (Domain Name Server) 解決の仕組み

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

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

Egress ファイアウォールポリシーで DNS 名を使用しても、CoreDNS を介したローカル DNS 解決には影響しません。

ただし、Egress ファイアウォールポリシーでドメイン名を使用し、外部 DNS サーバーで関連する Pod の DNS 解決を処理する場合は、DNS サーバーの IP アドレスへのアクセスを許可する Egress ファイアウォールルールを含める必要があります。

21.3.2. EgressNetworkPolicy カスタムリソース (CR) オブジェクト

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

以下の YAML は EgressNetworkPolicy CR オブジェクトを説明しています。

EgressNetworkPolicy オブジェクト

apiVersion: network.openshift.io/v1
kind: EgressNetworkPolicy
metadata:
  name: <name> 1
spec:
  egress: 2
    ...

1
Egress ファイアウォールポリシーの名前。
2
以下のセクションで説明されているように、Egress ネットワークポリシールールのコレクション。

21.3.2.1. EgressNetworkPolicy ルール

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

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

egress:
- type: <type> 1
  to: 2
    cidrSelector: <cidr> 3
    dnsName: <dns_name> 4

1
ルールのタイプ。値には Allow または Deny のいずれかを指定する必要があります。
2
Egress トラフィックのマッチングルールを記述するスタンザ。ルールの cidrSelector フィールドまたは dnsName フィールドのいずれかの値。同じルールで両方のフィールドを使用することはできません。
3
CIDR 形式の IP アドレス範囲。
4
ドメイン名。

21.3.2.2. EgressNetworkPolicy CR オブジェクトの例

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

apiVersion: network.openshift.io/v1
kind: EgressNetworkPolicy
metadata:
  name: default
spec:
  egress: 1
  - type: Allow
    to:
      cidrSelector: 1.2.3.0/24
  - type: Allow
    to:
      dnsName: www.example.com
  - type: Deny
    to:
      cidrSelector: 0.0.0.0/0
1
Egress ファイアウォールポリシールールオブジェクトのコレクション。

21.3.3. Egress ファイアウォールポリシーオブジェクトの作成

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

重要

プロジェクトに EgressNetworkPolicy オブジェクトがすでに定義されている場合、既存のポリシーを編集して Egress ファイアウォールルールを変更する必要があります。

前提条件

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

手順

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

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

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

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

    以下の例では、新規の EgressNetworkPolicy オブジェクトが project1 という名前のプロジェクトに作成されます。 

    $ oc create -f default.yaml -n project1

    出力例

    egressnetworkpolicy.network.openshift.io/v1 created

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

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.