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

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

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

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

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

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

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

注記

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

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

  • CIDR 形式の IP アドレス範囲。
  • IP アドレスに解決する DNS 名
  • ポート番号
  • プロトコル。TCP、UDP、および SCTP のいずれかになります。
重要

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>
1 

spec:
  egress:
  - to:
      cidrSelector: <api_server_address_range>
2 

    type: Allow
# ...
  - to:
      cidrSelector: 0.0.0.0/0
3 

    type: Deny
Copy to Clipboard Toggle word wrap
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 ファイアウォールルールは、ルーターを通過するトラフィックには適用されません。ルート CR オブジェクトを作成するパーミッションを持つユーザーは、禁止されている宛先を参照するルートを作成することにより、Egress ファイアウォールポリシールールをバイパスできます。

5.4.1.1. Egress ファイアウォールの制限
リンクのコピー

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

  • 複数の EgressFirewall オブジェクトを持つプロジェクトはありません。
  • プロジェクトごとに、最大 8,000 個のルールを持つ EgressFirewall オブジェクトを最大 1 つ定義できます。
  • Red Hat OpenShift Networking の共有ゲートウェイモードで OVN-Kubernetes ネットワークプラグインを使用している場合に、リターン Ingress 応答は Egress ファイアウォールルールの影響を受けます。送信ファイアウォールルールが受信応答宛先 IP をドロップすると、トラフィックはドロップされます。

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

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

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

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 アドレスの変更が頻繁に生じないドメインの場合にのみ推奨されます。
注記

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

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

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.
1 

status:
  resolvedNames:
  - dnsName: www.example.com.
2 

    resolvedAddress:
    - ip: "1.2.3.4"
3 

      ttlSeconds: 60
4 

      lastLookupTime: "2023-08-08T15:07:04Z"
5
Copy to Clipboard Toggle word wrap

1
DNS 名。これは、標準の DNS 名またはワイルドカード DNS 名のいずれかになります。ワイルドカード DNS 名の場合、DNS 名解決情報には、ワイルドカード DNS 名に一致するすべての DNS 名が含まれます。
2
spec.name フィールドに一致する解決された DNS 名。spec.name フィールドにワイルドカード DNS 名が含まれている場合、解決時にワイルドカード DNS 名と一致する標準 DNS 名を含む複数の dnsName エントリーが作成されます。ワイルドカード DNS 名も正常に解決できる場合は、このフィールドにはワイルドカード DNS 名も保存されます。
3
DNS 名に関連付けられている現在の IP アドレス。
4
最後の Time-to-Live (TTL) 期間。
5
最後のルックアップ時刻。

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: <name>
1 

spec:
  egress:
2 

    ...
Copy to Clipboard Toggle word wrap

1
オブジェクトの名前は default である必要があります。
2
以下のセクションで説明されているように、Egress ネットワークポリシールールのコレクション。

5.4.2.1. EgressFirewall ルール
リンクのコピー

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

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

egress:
- type: <type>
1 

  to:
2 

    cidrSelector: <cidr>
3 

    dnsName: <dns_name>
4 

    nodeSelector: <label_name>: <label_value>
5 

  ports:
6 

      ...
Copy to Clipboard Toggle word wrap

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

ポートスタンザ

ports:
- port: <port>
1 

  protocol: <protocol>
2
Copy to Clipboard Toggle word wrap

1
80 や 443 などのネットワークポート。このフィールドの値を指定する場合は、protocol の値も指定する必要があります。
2
ネットワークプロトコル。値は 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
Copy to Clipboard Toggle word wrap
1
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
Copy to Clipboard Toggle word wrap

5.4.2.3. EgressFirewall の nodeSelector の例
リンクのコピー

クラスター管理者は、nodeSelector を使用して、ラベルを指定することにより、クラスター内のノードへの Egress トラフィックを許可または拒否できます。ラベルは、1 つ以上のノードに適用できます。以下は、region=east ラベルを使用した例です。 

apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: default
spec:
    egress:
    - to:
        nodeSelector:
          matchLabels:
            region: east
      type: Allow
Copy to Clipboard Toggle word wrap
ヒント

ノード IP アドレスごとに手動でルールを追加する代わりに、ノードセレクターを使用して、Egress ファイアウォールの背後にある Pod がホストネットワーク Pod にアクセスできるようにするラベルを作成します。

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

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

重要

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

前提条件

  • OVN-Kubernetes ネットワークプラグインを使用するクラスター。
  • 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>
    Copy to Clipboard Toggle word wrap

    成功した出力には、egressfirewall.k8s.ovn.org/v1 の名前と created ステータスがリスト表示されます。

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

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat