独自のネットワーク セキュリティ グループ (NSG) を Azure Red Hat OpenShift (ARO) クラスターに導入する

通常、ARO クラスターを設定するときは、ARO クラスター オブジェクトをデプロイするためのリソース グループ (次の図ではベース リソース グループと記載されています) を指定する必要があります。 このようなシナリオでは、仮想ネットワーク (VNET) とクラスターの両方に同じリソース グループを使うか、VNET 専用に別のリソース グループを選ぶことができます。 これらのリソース グループはどちらも 1 つの ARO クラスターに直接対応していないため、それらを完全に制御できます。 つまり、これらのリソース グループ内のリソースを自由に作成、変更、削除できます。

クラスターの作成プロセス中に、ARO リソース プロバイダー (RP) は、クラスターのニーズに合わせた専用のリソース グループを確立します。 このグループには、次の図の管理対象リソース グループで示されているように、ノード VM、ロード バランサー、ネットワーク セキュリティ グループ (NSG) などのクラスター固有のさまざまなリソースが含まれています。 管理対象リソース グループは厳重にセキュリティで保護されており、クラスターの作成時に指定した VNET サブネットにリンクされた NSG を含め、その内容の変更は禁止されています。 状況によっては、ARO RP によって生成された NSG が特定の組織のセキュリティ ポリシーに準拠していない可能性があります。

この記事では、"独自の" ネットワーク セキュリティ グループ (NSG) 機能を使って、ベース/VNET リソース グループ (RG) に存在する独自の事前構成済み NSG (次の図では BYO-NSG と記載されています) を ARO クラスター サブネットにアタッチする方法について説明します。 あなたはこの事前構成済み NSG を所有しているため、ARO クラスターの有効期間中に規則を追加または削除できます。

一般的な機能と制限事項

• クラスターを作成する前に、事前構成済み NSG をマスター サブネットとワーカー サブネットの両方にアタッチする必要があります。 事前構成済み NSG を両方のサブネットにアタッチしないと、エラーが発生します。

• マスター サブネットとワーカー サブネットには、同じまたは異なる事前構成済み NSG を使うことができます。

• 独自の NSG を使う場合、ARO RP は管理対象リソース グループ (既定値 NSG) に NSG を作成しますが、その NSG はワーカー サブネットまたはマスター サブネットにアタッチされません。

• 既存の ARO クラスターで事前構成済み NSG 機能を有効にすることはできません。 現在、この機能はクラスターの作成時にのみ有効にできます。

• 事前構成済み NSG オプションは、Azure portal からは構成できません。

• プレビュー段階でこの機能を使った場合、既存の事前構成済みクラスターが完全にサポートされるようになりました。

Note

"Bring Your Own" NSG 機能を使用していて、NSG フロー ログを使用する必要がある場合は、ARO 固有のフロー ログ ドキュメントではなく (これは Bring Your Own NSG 機能では機能しません)、Azure Network Watcher ドキュメントの「ネットワーク セキュリティ グループのフローのログ記録」を参照してください。

規則の使用

警告

ARO クラスター内に Kubernetes LoadBalancer 型のサービスまたは OpenShift ルートを作成する場合、規則を使って事前構成済み NSG を自動的に更新することはできません。 そのため、必要に応じてこれらの規則を手動で更新する必要があります。 この動作は、そのような状況で既定の NSG がプログラムによって更新される元の ARO の動作とは異なります。

• 既定の ARO クラスター NSG (この機能の使用中はサブネットにアタッチされていません) は、ARO クラスター内に Kubernetes LoadBalancer 型のサービスまたは OpenShift ルートを作成するときに規則で更新されます。

• この機能を使って作成されたクラスターのサブネットから、事前構成済み NSG をデタッチできます。 その結果、NSG のないサブネットを持つクラスターが作成されます。 その後、事前構成済み NSG の別のセットをクラスターにアタッチできます。 または、ARO の既定の NSG をクラスターのサブネットにアタッチすることもできます (この時点で、クラスターはこの機能を使っていない他のクラスターと同様になります)。

• 事前構成済み NSG には、次の種類の INBOUND/OUTBOUND DENY 規則を含めないでください。クラスターの操作に干渉したり、ARO サポートまたは SRE チームのサポートや管理の提供の妨げになったりする可能性があります (ここで、サブネットは、サブネット内の任意またはすべての IP アドレス、そのサブネットに対応するすべてのポートを示します)。

  • マスター サブネット ←→ マスター サブネット

  • worker サブネット ←→ worker サブネット

  • マスター サブネット ←→ worker サブネット

  • 規則が正しく構成されていないと、Azure Monitor によって使われるシグナルが生成されます。これは事前構成済み NSG のトラブルシューティングに役立ちます。

• ARO パブリック クラスターへの受信トラフィックを許可するには、NSG で次の INBOUND ALLOW 規則 (または同等のもの) を設定します。 具体的な詳細についてはクラスターの既定の NSG と、「デプロイ」に示されている NSG の例を参照してください。 NSG にそのような規則がなくてもクラスターを作成できます。

  • API サーバー アクセスの場合 → インターネット (または優先ソース IP) からマスター サブネットのポート 6443 へ。
  • OpenShift ルーター (したがって OpenShift コンソールと OpenShift ルート) へのアクセスの場合 → インターネット (または優先ソース IP) から、クラスターのパブリック ロードバランサー上の既定の v4 パブリック IP のポート 80 と 443 へ。
  • 任意のロード バランサー型 Kubernetes サービスへのアクセスの場合 → インターネット (または優先ソース IP) から、クラスターのパブリック ロードバランサー上のサービスに対応するパブリック IP 上のサービス ポートへ。

展開

VNET を作成し、事前構成済み NSG を作成および構成する

1. VNET を作成してから、その中にマスター サブネットとワーカー サブネットを作成します。

2. 既定の規則を含む (または規則をまったく含まない) 事前構成済み NSG を作成し、それらをマスター サブネットとワーカー サブネットにアタッチします。

ARO クラスターを作成し、事前構成済み NSG を更新する

1. クラスターを作成します。

   az aro create \
   --resource-group BASE_RESOURCE_GROUP_NAME \
   --name CLSUTER_NAME \
   --vnet VNET_NAME \
   --master-subnet MASTER_SUBNET_NAME \
   --worker-subnet WORKER_SUBNET_NAME \
   --client-id CLUSTER_SERVICE_PRINCIPAL_ID \
   --client-secret CLUSTER_SERVICE_PRINCIPAL_SECRET \
   --enable-preconfigured-nsg
   

2. 機能と制限事項に関する記事で説明されている点も考慮しながら、要件に応じた規則で事前構成済み NSG を更新します。

   次の例には、スクリーンショットまたは CLI 出力に示されているように、クラスター パブリック ロードバランサーが含まれています。

   

   $ oc get svc | grep tools
   tools LoadBalancer 172.30.182.7 20.141.176.3 80:30520/TCP 143m
   $ $ oc get svc -n openshift-ingress | grep Load
   router-default LoadBalancer 172.30.105.218 20.159.139.208 80:31157/TCP,443:31177/TCP 
   5d20