3.5. Egress ファイアウォール
3.5.1. プロジェクトの Egress ファイアウォールの表示 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、既存の egress ファイアウォールの名前をリスト表示し、特定の egress ファイアウォールのトラフィックルールを表示できます。
3.5.1.1. EgressFirewall オブジェクトの表示 リンクのコピーリンクがクリップボードにコピーされました!
クラスターで EgressFirewall オブジェクトを表示できます。
前提条件
- OVN-Kubernetes ネットワークプラグインを使用するクラスター。
-
oc
として知られる OpenShift コマンドラインインターフェイス (CLI) のインストール。 - クラスターにログインすること。
手順
オプション: クラスターで定義された EgressFirewall オブジェクトの名前を表示するには、以下のコマンドを入力します。
oc get egressfirewall --all-namespaces
$ oc get egressfirewall --all-namespaces
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ポリシーを検査するには、以下のコマンドを入力します。
<policy_name>
を検査するポリシーの名前に置き換えます。oc describe egressfirewall <policy_name>
$ oc describe egressfirewall <policy_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.5.2. プロジェクトの Egress ファイアウォールの編集 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、既存の Egress ファイアウォールのネットワークトラフィックルールを変更できます。
3.5.2.1. EgressFirewall オブジェクトの編集 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、プロジェクトの Egress ファイアウォールを更新できます。
前提条件
- OVN-Kubernetes ネットワークプラグインを使用するクラスター。
-
OpenShift CLI (
oc
) がインストールされている。 - クラスター管理者としてクラスターにログインする必要があります。
手順
プロジェクトの EgressFirewall オブジェクトの名前を検索します。
<project>
をプロジェクトの名前に置き換えます。oc get -n <project> egressfirewall
$ oc get -n <project> egressfirewall
Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: Egress ネットワークファイアウォールの作成時に EgressFirewall オブジェクトのコピーを保存しなかった場合には、以下のコマンドを入力してコピーを作成します。
oc get -n <project> egressfirewall <name> -o yaml > <filename>.yaml
$ oc get -n <project> egressfirewall <name> -o yaml > <filename>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <project>
をプロジェクトの名前に置き換えます。<name>
をオブジェクトの名前に置き換えます。<filename>
をファイルの名前に置き換え、YAML を保存します。ポリシールールに変更を加えたら、以下のコマンドを実行して EgressFirewall オブジェクトを置き換えます。
<filename>
を、更新された EgressFirewall オブジェクトを含むファイルの名前に置き換えます。oc replace -f <filename>.yaml
$ oc replace -f <filename>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.5.3. プロジェクトからの Egress ファイアウォールの削除 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、プロジェクトから Egress ファイアウォールを削除して、OpenShift Container Platform クラスター外に出るプロジェクトからネットワークトラフィックに対するすべての制限を削除できます。
3.5.3.1. EgressFirewall オブジェクトの削除 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、プロジェクトから Egress ファイアウォールを削除できます。
前提条件
- OVN-Kubernetes ネットワークプラグインを使用するクラスター。
-
OpenShift CLI (
oc
) がインストールされている。 - クラスター管理者としてクラスターにログインする必要があります。
手順
プロジェクトの EgressFirewall オブジェクトの名前を検索します。
<project>
をプロジェクトの名前に置き換えます。oc get -n <project> egressfirewall
$ oc get -n <project> egressfirewall
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを入力し、EgressFirewall オブジェクトを削除します。
<project>
をプロジェクトの名前に、<name>
をオブジェクトの名前に置き換えます。oc delete -n <project> egressfirewall <name>
$ oc delete -n <project> egressfirewall <name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.5.4. プロジェクトの Egress ファイアウォールの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、OpenShift Container Platform クラスター外に出るプロジェクトのプロジェクについて、Egress トラフィックを制限する Egress ファイアウォールを作成できます。
3.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 ファイアウォールルールの順序を示しています。
API サーバーの IP アドレスを見つけるには、oc get ep kubernetes -n default
を実行します。
詳細は、BZ#1988324 を参照してください。
Egress ファイアウォールルールは、ルーターを通過するトラフィックには適用されません。ルート CR オブジェクトを作成するパーミッションを持つユーザーは、禁止されている宛先を参照するルートを作成することにより、Egress ファイアウォールポリシールールをバイパスできます。
3.5.4.1.1. Egress ファイアウォールの制限 リンクのコピーリンクがクリップボードにコピーされました!
Egress ファイアウォールには以下の制限があります。
- 複数の EgressFirewall オブジェクトを持つプロジェクトはありません。
- 最大 8,000 のルールを持つ最大 1 つの EgressFirewall オブジェクトはプロジェクトごとに定義できます。
- Red Hat OpenShift Networking の共有ゲートウェイモードで OVN-Kubernetes ネットワークプラグインを使用している場合に、リターン Ingress 応答は Egress ファイアウォールルールの影響を受けます。送信ファイアウォールルールが受信応答宛先 IP をドロップすると、トラフィックはドロップされます。
これらの制限のいずれかに違反すると、プロジェクトの Egress ファイアウォールが壊れます。その結果、すべての外部ネットワークトラフィックがドロップされ、組織にセキュリティーリスクが生じる可能性があります。
Egress ファイアウォールリソースは、kube-node-lease
、kube-public
、kube-system
、openshift
、openshift-
プロジェクトで作成できます。
3.5.4.1.2. Egress ポリシールールのマッチング順序 リンクのコピーリンクがクリップボードにコピーされました!
Egress ファイアウォールポリシールールは、最初から最後へと定義された順序で評価されます。Pod からの Egress 接続に一致する最初のルールが適用されます。この接続では、後続のルールは無視されます。
3.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 ファイアウォールルールを含める必要があります。
3.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 定義の例
- 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 ファイアウォールの望ましくない動作が発生する可能性があります。
3.5.4.2. EgressFirewall カスタムリソース (CR) オブジェクト リンクのコピーリンクがクリップボードにコピーされました!
Egress ファイアウォールのルールを 1 つ以上定義できます。ルールは、ルールが適用されるトラフィックを指定して Allow
ルールまたは Deny
ルールのいずれかになります。
以下の YAML は EgressFirewall CR オブジェクトを説明しています。
EgressFirewall オブジェクト
3.5.4.2.1. EgressFirewall ルール リンクのコピーリンクがクリップボードにコピーされました!
以下の YAML は Egress ファイアウォールルールオブジェクトを説明しています。ユーザーは、CIDR 形式の IP アドレス範囲またはドメイン名を選択するか、nodeSelector
を使用して、送信トラフィックを許可または拒否できます。egress
スタンザは、単一または複数のオブジェクトの配列を予想します。
Egress ポリシールールのスタンザ
- 1
- ルールのタイプ。値には
Allow
またはDeny
のいずれかを指定する必要があります。 - 2
cidrSelector
フィールドまたはdnsName
フィールドを指定する Egress トラフィックのマッチングルールを記述するスタンザ。同じルールで両方のフィールドを使用することはできません。- 3
- CIDR 形式の IP アドレス範囲。
- 4
- DNS ドメイン名。
- 5
- ラベルは、ユーザーが定義するキーと値のペアです。ラベルは Pod などのオブジェクトに添付されます。
nodeSelector
を使用すると、1 つ以上のノードラベルを選択して、Pod に添付できます。 - 6
- オプション: ルールのネットワークポートおよびプロトコルのコレクションを記述するスタンザ。
ポートスタンザ
ports: - port: <port> protocol: <protocol>
ports:
- port: <port>
protocol: <protocol>
3.5.4.2.2. EgressFirewall CR オブジェクトの例 リンクのコピーリンクがクリップボードにコピーされました!
以下の例では、複数の Egress ファイアウォールポリシールールを定義します。
- 1
- Egress ファイアウォールポリシールールオブジェクトのコレクション。
次の例では、トラフィックが TCP プロトコルおよび宛先ポート 80
または任意のプロトコルおよび宛先ポート 443
のいずれかを使用している場合に、IP アドレス 172.16.1.1/32
のホストへのトラフィックを拒否するポリシールールを定義します。
3.5.4.2.3. EgressFirewall の nodeSelector の例 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、nodeSelector
を使用して、ラベルを指定することにより、クラスター内のノードへの Egress トラフィックを許可または拒否できます。ラベルは、1 つ以上のノードに適用できます。以下は、region=east
ラベルを使用した例です。
ノード IP アドレスごとに手動でルールを追加する代わりに、ノードセレクターを使用して、Egress ファイアウォールの背後にある Pod がホストネットワーク Pod にアクセスできるようにするラベルを作成します。
3.5.4.3. Egress ファイアウォールポリシーオブジェクトの作成 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、プロジェクトの Egress ファイアウォールポリシーオブジェクトを作成できます。
プロジェクトに EgressFirewall オブジェクトがすでに定義されている場合、既存のポリシーを編集して Egress ファイアウォールルールを変更する必要があります。
前提条件
- OVN-Kubernetes ネットワークプラグインを使用するクラスター。
-
OpenShift CLI (
oc
) がインストールされている。 - クラスター管理者としてクラスターにログインする必要があります。
手順
ポリシールールを作成します。
-
<policy_name>.yaml
ファイルを作成します。この場合、<policy_name>
は Egress ポリシールールを記述します。 - 作成したファイルで、Egress ポリシーオブジェクトを定義します。
-
以下のコマンドを入力してポリシーオブジェクトを作成します。
<policy_name>
をポリシーの名前に、<project>
をルールが適用されるプロジェクトに置き換えます。oc create -f <policy_name>.yaml -n <project>
$ oc create -f <policy_name>.yaml -n <project>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の例では、新規の EgressFirewall オブジェクトが
project1
という名前のプロジェクトに作成されます。oc create -f default.yaml -n project1
$ oc create -f default.yaml -n project1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
egressfirewall.k8s.ovn.org/v1 created
egressfirewall.k8s.ovn.org/v1 created
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
オプション: 後に変更できるように
<policy_name>.yaml
ファイルを保存します。