6.6. Egress ファイアウォール
6.6.1. プロジェクトの egress ファイアウォールの表示
クラスター管理者は、既存の 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 を使用できます。
6.6.1.1. EgressFirewall オブジェクトの表示
クラスターで EgressFirewall オブジェクトを表示できます。
前提条件
- OVN-Kubernetes ネットワークプラグインを使用するクラスター。
-
ocとして知られる OpenShift コマンドラインインターフェイス (CLI) のインストール。 - クラスターにログインすること。
手順
オプション: クラスターで定義された EgressFirewall オブジェクトの名前を表示するには、以下のコマンドを入力します。
$ oc get egressfirewall --all-namespaces
ポリシーを検査するには、以下のコマンドを入力します。
<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
6.6.2. プロジェクトの egress ファイアウォールの編集
クラスター管理者は、既存の egress ファイアウォールのネットワークトラフィックルールを変更できます。
6.6.2.1. EgressFirewall オブジェクトの編集
クラスター管理者は、プロジェクトの egress ファイアウォールを更新できます。
前提条件
- OVN-Kubernetes ネットワークプラグインを使用するクラスター。
-
OpenShift CLI (
oc) がインストールされている。 - クラスター管理者としてクラスターにログインする必要があります。
手順
プロジェクトの EgressFirewall オブジェクトの名前を検索します。
<project>をプロジェクトの名前に置き換えます。$ oc get -n <project> egressfirewall
オプション: egress ネットワークファイアウォールの作成時に EgressFirewall オブジェクトのコピーを保存しなかった場合には、以下のコマンドを入力してコピーを作成します。
$ oc get -n <project> egressfirewall <name> -o yaml > <filename>.yaml
<project>をプロジェクトの名前に置き換えます。<name>をオブジェクトの名前に置き換えます。<filename>をファイルの名前に置き換え、YAML を保存します。ポリシールールに変更を加えたら、以下のコマンドを実行して EgressFirewall オブジェクトを置き換えます。
<filename>を、更新された EgressFirewall オブジェクトを含むファイルの名前に置き換えます。$ oc replace -f <filename>.yaml
6.6.3. プロジェクトからの egress ファイアウォールの削除
クラスター管理者は、プロジェクトから egress ファイアウォールを削除して、OpenShift Container Platform クラスター外に出るプロジェクトからネットワークトラフィックについてのすべての制限を削除できます。
6.6.3.1. EgressFirewall オブジェクトの削除
クラスター管理者は、プロジェクトから Egress ファイアウォールを削除できます。
前提条件
- OVN-Kubernetes ネットワークプラグインを使用するクラスター。
-
OpenShift CLI (
oc) がインストールされている。 - クラスター管理者としてクラスターにログインする必要があります。
手順
プロジェクトの EgressFirewall オブジェクトの名前を検索します。
<project>をプロジェクトの名前に置き換えます。$ oc get -n <project> egressfirewall
以下のコマンドを入力し、EgressFirewall オブジェクトを削除します。
<project>をプロジェクトの名前に、<name>をオブジェクトの名前に置き換えます。$ oc delete -n <project> egressfirewall <name>
6.6.4. プロジェクトの egress ファイアウォールの設定
クラスター管理者は、OpenShift Container Platform クラスター外に出るプロジェクトのプロジェクについて、egress トラフィックを制限する egress ファイアウォールを作成できます。
6.6.4.1. egress ファイアウォールのプロジェクトでの機能
クラスター管理者は、Egress ファイアウォール を使用して、一部またはすべての Pod がクラスター内からアクセスできる外部ホストを制限できます。egress ファイアウォールポリシーは以下のシナリオをサポートします。
- Pod の接続を内部ホストに制限し、パブリックインターネットへの接続を開始できないようにする。
- Pod の接続をパブリックインターネットに制限し、OpenShift Container Platform クラスター外にある内部ホストへの接続を開始できないようにする。
- Pod は OpenShift Container Platform クラスター外の指定された内部サブネットまたはホストにアクセスできません。
- Pod は特定の外部ホストにのみ接続することができます。
たとえば、指定された IP 範囲へのあるプロジェクトへのアクセスを許可する一方で、別のプロジェクトへの同じアクセスを拒否することができます。または、アプリケーション開発者の (Python) pip mirror からの更新を制限したり、更新を承認されたソースからの更新のみに強制的に制限したりすることができます。
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
API サーバーの IP アドレスを見つけるには、oc get ep kubernetes -n default を実行します。
詳細は、BZ#1988324 を参照してください。
egress ファイアウォールルールは、ルーターを通過するトラフィックには適用されません。ルート CR オブジェクトを作成するパーミッションを持つユーザーは、禁止されている宛先を参照するルートを作成することにより、egress ファイアウォールポリシールールをバイパスできます。
6.6.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- プロジェクトで作成できます。
6.6.4.1.2. egress ポリシールールのマッチング順序
egress ファイアウォールポリシールールは、最初から最後へと定義された順序で評価されます。Pod からの egress 接続に一致する最初のルールが適用されます。この接続では、後続のルールは無視されます。
6.6.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 ファイアウォールルールを含める必要があります。
6.6.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
- 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 ファイアウォールの望ましくない動作が発生する可能性があります。
6.6.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 ...
6.6.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 ...
- 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
6.6.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- 1
- egress ファイアウォールポリシールールオブジェクトのコレクション。
以下の例では、トラフィックが TCP プロトコルおよび宛先ポート 80 または任意のプロトコルと宛先ポート 443 のいずれかを使用している場合に、IP アドレス 172.16.1.1 でホストへのトラフィックを拒否するポリシールールを定義します。
apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
name: default
spec:
egress:
- type: Deny
to:
cidrSelector: 172.16.1.1
ports:
- port: 80
protocol: TCP
- port: 4436.6.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ノード IP アドレスごとに手動でルールを追加する代わりに、ノードセレクターを使用して、egress ファイアウォールの背後にある Pod がホストネットワーク Pod にアクセスできるようにするラベルを作成します。
6.6.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>
以下の例では、新規の EgressFirewall オブジェクトが
project1という名前のプロジェクトに作成されます。$ oc create -f default.yaml -n project1
出力例
egressfirewall.k8s.ovn.org/v1 created
-
オプション: 後に変更できるように
<policy_name>.yamlファイルを保存します。
