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 ファイアウォールには以下の制限があります。
-
複数の
EgressFirewallCR を持つプロジェクトはありません。 -
Egress ファイアウォールルールは、ルーターを通過するトラフィックには適用されません。
RouteCR オブジェクトを作成するパーミッションを持つユーザーは、禁止されている宛先を参照するルートを作成することにより、egress ファイアウォールポリシールールをバイパスできます。 - Egress ファイアウォールは、ホストネットワークの namespace には適用されません。ホストネットワークが有効になっている Pod は、Egress ファイアウォールルールの影響を受けません。
Egress ファイアウォールに
0.0.0.0/0の拒否ルールが含まれる場合、OpenShift Container Platform API サーバーへのアクセスはブロックされます。API サーバーに接続するには、IP アドレスごとに許可ルールを追加するか、Egress ポリシールールでnodeSelectorタイプの許可ルールを使用する必要があります。次の例は、API サーバーへのアクセスを確保するために必要な Egress ファイアウォールルールの順序を示しています。
EgressFirewallAPI サーバーアクセスの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
- <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 のルールを持つ最大 1 つの
EgressFirewallオブジェクトはプロジェクトごとに定義できます。 - Red Hat OpenShift Networking の共有ゲートウェイモードで OVN-Kubernetes ネットワークプラグインを使用している場合、リターン Ingress 応答は egress ファイアウォールルールの影響を受けます。Egress ファイアウォールルールによって Ingress 応答の宛先 IP がドロップされると、トラフィックがドロップされます。
- 通常、egress ファイアウォールポリシーで Domain Name Server (DNS)名を使用しても、CoreDNS によるローカル DNS 解決には影響しません。ただし、egress ファイアウォールポリシーがドメイン名を使用し、外部 DNS サーバーが影響を受ける Pod の 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 定義の例
ここでは、以下のようになります。
- <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 オブジェクト
ここでは、以下のようになります。
- <OVN>
-
オブジェクトの名前は
defaultである必要があります。 - <egress_rules>
- 以下のセクションで説明されているように、egress ネットワークポリシールールのコレクションを指定します。
5.4.2.1. EgressFirewall ルール リンクのコピーリンクがクリップボードにコピーされました!
以下の YAML は、EgressFirewall リソースのルールについて説明しています。ユーザーは、CIDR 形式の IP アドレス範囲またはドメイン名を選択するか、nodeSelector フィールドを使用して egress トラフィックを許可または拒否できます。egress スタンザは、単一または複数のオブジェクトの配列を予想します。
Egress ポリシールールのスタンザ
ここでは、以下のようになります。
- <type>
-
ルールの種類を指定します。値には
AllowまたはDenyのいずれかを指定する必要があります。 - <to>
-
cidrSelectorフィールドまたはdnsNameフィールドを指定する egress トラフィック一致ルールを記述するスタンザを指定します。同じルールで両方のフィールドを使用することはできません。 - <cidr_range>
- CIDR 形式の IP アドレス範囲を指定します。
- <DNS_NAME>
- DNS ドメイン名を指定します。
- <nodeSelector>
-
ユーザーが定義するキーと値のペアであるラベルを指定します。ラベルは Pod などのオブジェクトに添付されます。
nodeSelectorを使用すると、1 つ以上のノードラベルを選択して、Pod に添付できます。 - <ports>
- ルールのネットワークポートとプロトコルのコレクションを記述する任意のフィールドを指定します。
ポートスタンザ
ports: - port: protocol:
ports:
- port:
protocol:
ここでは、以下のようになります。
- <port>
-
80や443などのネットワークポートを指定します。このフィールドの値を指定する場合は、protocolフィールドの値も指定する必要があります。 - <protocol>
-
ネットワークプロトコルを指定します。値は
TCP、UDP、またはSCTPのいずれかである必要があります。
5.4.2.2. EgressFirewall CR の例 リンクのコピーリンクがクリップボードにコピーされました!
以下の例では、複数の Egress ファイアウォールポリシールールを定義します。
ここでは、以下のようになります。
- <egress>
- egress ファイアウォールポリシールールオブジェクトのコレクションを指定します。
次の例では、トラフィックが TCP プロトコルおよび宛先ポート 80 または任意のプロトコルおよび宛先ポート 443 のいずれかを使用している場合に、IP アドレス 172.16.1.1/32 のホストへのトラフィックを拒否するポリシールールを定義します。
5.4.2.3. nodeSelector を使用した EgressFirewall CR の例 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、nodeSelector フィールドを使用してラベルを指定することにより、クラスター内のノードへのエグレストラフィックを許可または拒否できます。ラベルは、1 つ以上のノードに適用できます。ラベルは、ノード IP アドレスごとに手動でルールを追加する代わりに、ノードセレクターを使用して、egress ファイアウォールの背後にある Pod がホストネットワーク Pod にアクセスできるようにラベルを作成することができるからです。以下は、region=east ラベルを使用した例です。
5.4.3. EgressFirewall カスタムリソース(CR)の作成 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、プロジェクトの Egress ファイアウォールポリシーオブジェクトを作成できます。
プロジェクトに EgressFirewall リソースがすでにある場合は、既存のポリシーを編集して egress ファイアウォールルールを変更する必要があります。
前提条件
- OVN-Kubernetes ネットワークプラグインを使用するクラスター。
-
OpenShift CLI (
oc) がインストールされている。 - クラスター管理者としてクラスターにログインする必要があります。
手順
ポリシールールを作成します。
-
<policy_name>.yamlファイルを作成します。この場合、<policy_name>は Egress ポリシールールを記述します。 -
ファイルに
EgressFirewallオブジェクトを定義します。
-
次のコマンドを入力して、ポリシーオブジェクトを作成します。
<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.k8s.ovn.org/v1名と作成されたステータスが一覧表示されます。-
オプション: 後に変更できるように
<policy_name>.yamlファイルを保存します。