18.3. プロジェクトの egress ファイアウォールの設定
クラスター管理者は、OpenShift Container Platform クラスター外に出るプロジェクトのプロジェクについて、egress トラフィックを制限する egress ファイアウォールを作成できます。
18.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 サーバーへのアクセスはブロックされます。Pod が OpenShift Container Platform API サーバーにアクセスできるようにするには、Open Virtual Network (OVN) のビルトイン結合ネットワーク 100.64.0.0/16 を含めて、ノードポートを EgressFirewall と一緒に使用するときにアクセスできるようにする必要があります。次の例のように、API サーバーがリッスンする IP アドレス範囲も 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
API サーバーの IP アドレスを見つけるには、oc get ep kubernetes -n default を実行します。
詳細は、BZ#1988324 を参照してください。
egress ファイアウォールを設定するには、ネットワークポリシーまたはマルチテナントモードのいずれかを使用するように OpenShift SDN を設定する必要があります。
ネットワークポリシーモードを使用している場合、egress ファイアウォールは namespace ごとに 1 つのポリシーとのみ互換性を持ち、グローバルプロジェクトなどのネットワークを共有するプロジェクトでは機能しません。
egress ファイアウォールルールは、ルーターを通過するトラフィックには適用されません。ルート CR オブジェクトを作成するパーミッションを持つユーザーは、禁止されている宛先を参照するルートを作成することにより、egress ファイアウォールポリシールールをバイパスできます。
18.3.1.1. egress ファイアウォールの制限
egress ファイアウォールには以下の制限があります。
- いずれのプロジェクトも複数の EgressNetworkPolicy オブジェクトを持つことができません。
- 最大 1,000 のルールを持つ最大 1 つの EgressNetworkPolicy オブジェクトはプロジェクトごとに定義できます。
-
defaultプロジェクトは egress ファイアウォールを使用できません。 マルチテナントモードで OpenShift SDN デフォルト Container Network Interface (CNI) ネットワークプロバイダーを使用する場合、以下の制限が適用されます。
-
グローバルプロジェクトは egress ファイアウォールを使用できません。
oc adm pod-network make-projects-globalコマンドを使用して、プロジェクトをグローバルにすることができます。 -
oc adm pod-network join-projectsコマンドを使用してマージされるプロジェクトでは、結合されたプロジェクトのいずれでも egress ファイアウォールを使用することはできません。
-
グローバルプロジェクトは egress ファイアウォールを使用できません。
上記の制限のいずれかに違反すると、プロジェクトの egress ファイアウォールに障害が発生し、すべての外部ネットワークトラフィックがドロップされる可能性があります。
egress ファイアウォールリソースは、kube-node-lease、kube-public、kube-system、openshift、openshift- プロジェクトで作成できます。
18.3.1.2. egress ポリシールールのマッチング順序
egress ファイアウォールポリシールールは、最初から最後へと定義された順序で評価されます。Pod からの egress 接続に一致する最初のルールが適用されます。この接続では、後続のルールは無視されます。
18.3.1.3. DNS (Domain Name Server) 解決の仕組み
egress ファイアウォールポリシールールのいずれかで DNS 名を使用する場合、ドメイン名の適切な解決には、以下の制限が適用されます。
- ドメイン名の更新は、TTL (Time-to-live) 期間に基づいてポーリングされます。デフォルトの期間は 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 解決用に Pod が置かれるノードの外部インターフェイスに Pod が常にアクセスできるようにします。
ドメイン名を egress ファイアウォールで使用し、DNS 解決がローカルノード上の DNS サーバーによって処理されない場合は、Pod でドメイン名を使用している場合には DNS サーバーの IP アドレスへのアクセスを許可する egress ファイアウォールを追加する必要があります。
18.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 ...
18.3.2.1. EgressNetworkPolicy ルール
以下の YAML は egress ファイアウォールルールオブジェクトについて説明しています。egress スタンザは、単一または複数のオブジェクトの配列を予想します。
Egress ポリシールールのスタンザ
egress: - type: <type> 1 to: 2 cidrSelector: <cidr> 3 dnsName: <dns_name> 4
18.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 ファイアウォールポリシールールオブジェクトのコレクション。
18.3.3. egress ファイアウォールポリシーオブジェクトの作成
クラスター管理者は、プロジェクトの egress ファイアウォールポリシーオブジェクトを作成できます。
プロジェクトに EgressNetworkPolicy オブジェクトがすでに定義されている場合、既存のポリシーを編集して egress ファイアウォールルールを変更する必要があります。
前提条件
- OpenShift SDN デフォルト Container Network Interface (CNI) ネットワークプロバイダープラグインを使用するクラスター。
-
OpenShift CLI (
oc) がインストールされている。 - クラスター管理者としてクラスターにログインする必要があります。
手順
ポリシールールを作成します。
-
<policy_name>.yamlファイルを作成します。この場合、<policy_name>は egress ポリシールールを記述します。 - 作成したファイルで、egress ポリシーオブジェクトを定義します。
-
以下のコマンドを入力してポリシーオブジェクトを作成します。
<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
-
オプション: 後に変更できるように
<policy_name>.yamlファイルを保存します。
