デフォルトでセキュアなクラスタVPCネットワーキングを理解する
仮想プライベートクラウド 4.15 その後
バージョン 4.15 で作成される新しい VPC クラスタから、 Red Hat OpenShift on IBM Cloud、Secure by Default Cluster VPC Networking と呼ばれる新しいセキュリティ機能が導入されました。 Secure by Default では、VPC クラスターの作成時に自動的に作成される新しい VPC 設定 (管理対象セキュリティー・グループ、セキュリティー・グループ・ルール、仮想プライベート・エンドポイント・ゲートウェイ (VPE) など) があります。 バージョン 4.15 以降のクラスタを作成するときに作成および管理されるVPCコンポーネントについて、以下の詳細を確認してください。
概要
Secure by Default Networking では、バージョン 4.15 以降の新しい Red Hat OpenShift on IBM Cloud VPC クラスターをプロビジョンすると、クラスターが機能するために必要なトラフィックのみが許可され、その他のアクセスはすべてブロックされます。 Secure by Default Networking を実装するために、 Red Hat OpenShift on IBM Cloud は、さまざまなセキュリティー・グループおよびセキュリティー・グループ・ルールを使用してクラスター・コンポーネントを保護します。 これらのセキュリティグループとルールは自動的に作成され、ワーカーノード、ロードバランサー、およびクラスタ関連のVPEゲートウェイにアタッチされます。
仮想プライベート・クラウドのセキュリティー・グループは、ハイパーバイザー・レベルでトラフィックをフィルタリングします。 セキュリティー・グループのルールは特定の順序で適用されるわけではありません。 ただし、ワーカー・ノードへの要求は、指定したルールのいずれかに一致した場合にのみ許可されます。 インバウンド・ルールまたはアウトバウンド・ルールを作成して、ある方向のトラフィックを許可すると、その反対方向の応答も許可されます。 セキュリティー・グループは追加式です。つまり、ワーカー・ノードに複数のセキュリティー・グループを関連付けると、それらのセキュリティー・グループに含まれているすべてのルールがワーカー・ノードに適用されます。
新しいクラスター・バージョンでは、古いクラスター・バージョンよりも多くのルールが kube-<clusterID> セキュリティー・グループに含まれている可能性があります。 サービスのセキュリティーを向上させるためにセキュリティー・グループ・ルールが追加されており、機能を損なうことはありません。
仮想プライベート・エンドポイント(VPE)ゲートウェイ
Red Hat OpenShift on IBM Cloud 4.14+ の最初の VPC クラスターが特定の VPC に作成されるか、その VPC 内のクラスターのマスターが 4.14+ に更新されると、さまざまな IBM Cloud サービス用に複数の共有 VPE ゲートウェイが作成されます。 これらの各タイプの共有 VPE ゲートウェイは、VPC ごとに 1 つのみ作成されます。 VPC 内のすべてのクラスターは、これらのサービスに対して同じ VPE ゲートウェイを共有します。 これらの共有 VPE ゲートウェイには、クラスター・ワーカーが存在する各ゾーンの単一の予約済み IP が割り当てられます。
管理対象セキュリティー・グループ
Red Hat OpenShift on IBM Cloud は、VPC クラスターの以下のセキュリティー・グループとルールを自動的に作成して更新します。
| セキュリティー・グループ | 命名規則 |
|---|---|
| 労働者セキュリティグループ | kube-<clusterID> |
| マスターVPEゲートウェイのセキュリティグループ | kube-vpegw-<clusterID> |
| 共有VPEゲートウェイのセキュリティグループ | kube-vpegw-<vpcID> |
| ロードバランサーサービスのセキュリティグループ | kube-lbaas-<clusterID> |
ワーカー・セキュリティー・グループ
Red Hat OpenShift on IBM Cloud VPC クラスタを作成すると、指定したクラスタのすべてのワーカー(ノード)に対してセキュリティグループが作成されます。
- セキュリティー・グループの名前は
kube-<clusterID>です。ここで、<clusterID>はクラスターの ID です。 - 後で新規ノードがクラスターに追加されると、それらのノードは自動的にクラスター・セキュリティー・グループに追加されます。
- ルールはロードバランサーによって必要に応じて動的に追加・削除される。
- ノード・ポート・レンジに追加されたルールは、必要なければ自動的に削除される。 ノード・ポート・サービスへの受信トラフィックを許可する場合は、ノード・ポート・サービスを作成した後でトラフィックを許可するルールを追加する必要があります。
kube-<clusterID>セキュリティー・グループ内のルールは変更しないでください。変更すると、クラスターのワーカーと制御クラスターの間のネットワーク接続が中断される可能性があります。
| 説明 | 方向 | プロトコル | ポートまたは値 | ソースまたは宛先 |
|---|---|---|---|---|
| ポッド・サブネットへのインバウンド・トラフィックを許可します。 | インバウンド | ICMP/ TCP / UDP | すべて | 172.17.0.0/18 (デフォルトのサブネット範囲) またはクラスターの作成時に指定したカスタム・サブネット範囲のいずれか。 |
| 自己へのインバウンド・アクセスを許可します。これにより、ワーカー間の通信が可能になります。 | インバウンド | ICMP/ TCP / UDP | すべて | kube-<clusterID> |
| インバウンド ICMP (ping) アクセスを許可します。 | インバウンド | ICMP | type=8 | 0.0.0.0/0 |
| ロードバランサー(ALB/NLB)によってオープンされたノードポートからのインバウンドトラフィックを許可します。 ロード・バランサーが追加または削除されると、ルールは動的に追加または削除されます。 | インバウンド | TCP | ロード・バランサー・ノードのポート。 | kube-lbaas-<clusterID> |
| ポッド・サブネットへのアウトバウンド・トラフィックを許可します。 | アウトバウンド | ICMP/ TCP / UDP | すべて | 172.17.0.0/18 (デフォルトのサブネット範囲) またはクラスターの作成時に指定したカスタム・サブネット範囲のいずれか。 |
| マスター・コントロール・プレーンへのアウトバウンド・トラフィックを許可します。これにより、ワーカーをプロビジョンできます。 | アウトバウンド | ICMP/ TCP / UDP | すべて | 161.26.0.0/16 |
| 自己へのアウトバウンド・アクセスを許可します。これにより、ワーカー間の通信が可能になります。 | アウトバウンド | ICMP/ TCP / UDP | すべて | kube-<clusterID> |
| マスター VPE ゲートウェイ・セキュリティー・グループへのアウトバウンド・トラフィックを許可します。 | アウトバウンド | ICMP/ TCP / UDP | すべて | kube-vpegw-<clusterID> |
| 共有 VPE ゲートウェイ・セキュリティー・グループへのアウトバウンド・トラフィックを許可します。 | アウトバウンド | ICMP/ TCP / UDP | すべて | kube-vpegw-<vpcID> |
クラスターが配置されている MZR のすべてのゾーンについて、OAuth ポートを介したパブリック・エンドポイントへのトラフィックを許可します。* |
アウトバウンド | TCP | Oauth ポート | MZR のすべてのゾーンのパブリック・エンドポイント IP。 |
| TCP トラフィックをイングレス ALB 経由で許可する | アウトバウンド | TCP | Ports:Min=443,Max=443 | ALB パブリック IP アドレス n |
n ゾーンのカスタム DNS リゾルバを介した TCP および UDP のトラフィックを許可する。** |
アウトバウンド | TCP/UDP | Min=53,Max=53 | ゾーン n 内の DNS リゾルバー IP アドレス。 |
| CSE サービス範囲全体へのトラフィックを許可します。 | アウトバウンド | ICMP/ TCP / UDP | すべて | 166.8.0.0/14 |
| すべてのゾーンの IAM プライベート・エンドポイントへのトラフィックを許可します。 IP は地域によって異なる場合があります。 クラスターが存在するゾーンごとに 1 つのルールが追加されます。 | アウトバウンド | ICMP/ TCP / UDP | すべて | すべてのゾーンの IAM プライベート・エンドポイント IP アドレス。 |
| インスタンス・メタデータAPIへのアウトバウンド・トラフィックを許可する。 | アウトバウンド | ICMP/ TCP / UDP | すべて | 169.254.169.254 |
| 4.18 以降 インスタンス・メタデータAPIへのアウトバウンド・トラフィックを許可する。 | アウトバウンド | ICMP/ TCP / UDP | すべて | 169.254.169.254 |
* これらのルールは、パブリック・サービス・エンドポイントが有効になっているクラスタにのみ追加され、 OpenShift Webコンソールとパブリック・エンドポイントへの、 OAuth ポートを介したアクセスを許可します。 クラスターが配置されているマルチゾーン・リージョン (MZR) のゾーンごとに 1 つのルールが追加されます。 クラスターが 3 つのゾーンを持つ MZR 内にある場合は、3 つのルールが作成されます。
** ハブおよびスポーク VPC は、VPC 上のカスタム DNS リゾルバーを使用します。 トラフィックは、各 DNS リゾルバーの IP アドレスを経由する必要があります。 ゾーンごとに2つのルールがある( TCP と UDP )。
マスター VPE ゲートウェイ・セキュリティー・グループ
VPC クラスターを作成すると、クラスターと同じ VPC に仮想プライベート・エンドポイント (VPE) ゲートウェイが作成されます。 セキュリティの名前は kube-vpegw-<clusterID> で、<clusterID> はクラスタのIDです。 このVPEゲートウェイの目的は、IBM Cloudが管理するクラスタ・マスターへのゲートウェイとして機能することです。 VPE ゲートウェイには、クラスターがワーカーを持つ
VPC 内の各ゾーンに単一の IP アドレスが割り当てられます。
クラスターのワーカー・ノードからのみクラスターのマスターへのアクセスを許可するために、クラスターのマスター VPE ゲートウェイごとにセキュリティー・グループが作成されます。 その後、クラスター・ワーカー・セキュリティー・グループからクラスター・マスター VPE ゲートウェイ上の必要なポートへの Ingress 接続を許可するリモート・ルールが作成されます。 VPC VPNを経由する接続を含むプライベート接続がクラスタのプライベートサービスエンドポイントVPEゲートウェイに接続する場合、 TCP、クラスタの各アクティブワーカープールのサブネットCIDRからのトラフィックが許可されます。
| 説明 | 方向 | プロトコル | ポートまたは値 | ソースまたは宛先 |
|---|---|---|---|---|
| クラスター・ワーカー・セキュリティー・グループからサーバー nodeport へのインバウンド・トラフィックを許可します。 | インバウンド | TCP | サーバー URL ノード・ポート | kube-<clusterID> |
| クラスター・ワーカー・セキュリティー・グループから openVPN または Konnectivity ポートへのインバウンド・トラフィックを許可します。 | インバウンド | TCP | コネクティビティ港 | kube-<clusterID> |
| クラスター・ワーカー・セキュリティー・グループから Oauth ポートへのインバウンド・トラフィックを許可します。 | インバウンド | TCP | Oauth ポート | kube-<clusterID> |
| CoreOS-enabledクラスタのみ。 クラスター・ワーカー・セキュリティー・グループから点火サーバー・ポートへのインバウンド・トラフィックを許可します | インバウンド | TCP | Ignition サーバー・ポート | kube-<clusterID> |
クラスタ内のすべてのアクティブなワーカープールのサブネットからのインバウンドトラフィックを許可します。* |
インバウンド | TCP | サーバー URL ノード・ポート | サブネット CIDR |
クラスタ内のすべてのアクティブなワーカープールのサブネットからのインバウンドトラフィックを許可します。* |
インバウンド | TCP | OAuth ポート | サブネット CIDR |
* すべてのアクティブなワーカー プールのサブネットに対して、1つのルールが追加される。 3つのゾーンにワーカーがいる場合、3つのルールが追加されます(ゾーン内の各サブネットに1つずつ)。
共有 VPE ゲートウェイ・セキュリティー・グループ
共有 VPE ゲートウェイは、VPC 内の最初のクラスタが provisioned.The 共有 VPE ゲートウェイ セキュリティ グループは、クラスタを作成するときに作成されます (以前のクラスタからまだ存在していない場合)。 セキュリティグループの名前は kube-vpegw-<vpcID> で、<vpcID> はVPCのIDです。 その後、指定されたクラスターのクラスター・ワーカー・セキュリティー・グループからの
Ingress 接続を許可するリモート・ルールが作成されます。 共有 VPE ゲートウェイ・セキュリティー・グループには、その VPC 内のすべてのクラスターによって共有される VPE ゲートウェイが含まれています。 共有 VPE ゲートウェイは、他の IBM Cloud サービスへの接続を可能にするために、後のバージョンで追加されるかもしれません。
クラスターのプロビジョン時にこの共有 VPE ゲートウェイ・セキュリティー・グループが既に存在する場合、その共有 VPE ゲートウェイ・セキュリティー・グループはプロビジョニング・プロセスによって認識され、再作成されません。 ただし、既存の共有 VPE ゲートウェイ・セキュリティー・グループと新規ワーカー・セキュリティー・グループの間には、引き続きリモート・ルールが追加されます。 これは、指定された VPC 内のすべてのクラスターからの接続が許可されるようにするためです。 VPC 内のクラスターごとに 1 つのルールが作成されます。
他のセキュリティー・グループをそのソースまたは宛先としてターゲットにすることができるルールは、最大 15 個です。 デフォルトでは、 Red Hat OpenShift on IBM Cloud は VPC 内の各クラスタに対して、 kube-<clusterID> セキュリティグループをターゲットとする 1 つのルールを適用します。 この割り当て量のため、1 つの VPC に作成できるクラスターは 15 個のみです。 詳しくは、
VPC 割り当て量 を参照してください。
| 説明 | 方向 | プロトコル | ソースまたは宛先 |
|---|---|---|---|
| 指定されたクラスターからのインバウンド・トラフィックを許可します。 | インバウンド | TCP | kube-<clusterID> |
ロード・バランサー・サービス・セキュリティー・グループ
すべてのロード・バランサー (ALB および NLB) に接続されているデフォルトのセキュリティー・グループ。
- 各クラスターは、クラスター内のすべてのロード・バランサーによって共有される独自の固有のセキュリティー・グループを取得します。
- セキュリティグループの名前は
kube-lbaas-<clusterID>で、<clusterID>はクラスタのIDです。 - このセキュリティー・グループのルールは、ロード・バランサーが追加、削除、または更新されると、動的に追加または削除されます。 SDNLB は、セキュリティー・グループの接続をサポートしていないことに注意してください。
- このセキュリティグループにルールを追加できる。 ただし、他のルールと互換性がない場合、あるいは機能を破壊する場合は、いくつかのルールが削除される可能性がある。
| 説明 | 方向 | プロトコル | ポートまたは値 | ソースまたは宛先 |
|---|---|---|---|---|
| ロード・バランサーによって開かれたノード・ポートへのアウトバウンド・アクセスを許可します。 ロード・バランサーによっては、複数のルールが存在する場合があります。 | アウトバウンド | TCP | ロード・バランサーによって開かれた Node ・ポート。 | kube-<clusterID> |
| ロード・バランサーは、ポート 80 で listen し、そのポートからのインバウンド・アクセスを許可します。 | インバウンド | TCP | パブリック LB ポート。 例 80 |
0.0.0.0/0 |
| ロード・バランサーは、ポート 443 で listen し、そのポートからのインバウンド・アクセスを許可します。 | インバウンド | TCP | パブリック LB ポート。 例 443 |
0.0.0.0/0 |
ユーザー提供 Security Groups
VPCクラスタを作成する際、所有するセキュリティ・グループを最大4つまで追加できます。
詳細については、 VPCセキュリティグループの作成と 管理を参照してください。
制限
- ワーカー・ノードのセキュリティー・グループ
- VPC クラスタのワーカー ノードはサービスアカウント存在し、VPC インフラストラクチャ ダッシュボードに表示されないため、セキュリティ グループを作成してワーカー ノード インスタンスに適用することはできません。 変更できるのは、既存の
kube-<clusterID>セキュリティグループのみです。 - ロギングおよびモニタリング
- 4.15 以降のクラスターでロギングとモニタリングをセットアップする場合は、クラスターにロギング・エージェントをインストールするときにプライベート・サービス・エンドポイントを使用する必要があります。 パブリック・エンドポイントが使用されている場合、ログ・データは保存されません。
- RHCOS ワーカー・ノードを使用したクラスターのモニター
- モニター・エージェントはオペレーティング・システムのカーネル・ヘッダーに依存していますが、RHCOS にはカーネル・ヘッダーがありません。 このシナリオでは、エージェントは
sysdig.comに戻り、プリコンパイルされたエージェントを使用します。 パブリック・ネットワーク・アクセスがないクラスターでは、このプロセスは失敗します。 RHCOS クラスターでのモニターを可能にするには、アウトバウンド・トラフィックを許可するか、 エアギャップ環境へのエージェントのインストールに関する Sysdig 資料を参照する必要があります。 - VPC クラスターの割り当て量
- 他のセキュリティー・グループをそのソースまたは宛先としてターゲットにすることができるルールは、最大 15 個です。 デフォルトでは、 Red Hat OpenShift on IBM Cloud は VPC 内の各クラスタに対して、
kube-<clusterID>セキュリティグループをターゲットとする 1 つのルールを適用します。 この割り当て量のため、1 つの VPC に作成できるクラスターは 15 個のみです。 詳しくは、 VPC 割り当て量 を参照してください。 - VPC File Storage。
- Secure by DefaultクラスタでEITを使用するには、
kube-<clusterID>セキュリティグループに以下の送信ルールを追加する必要があります。- プロトコル任意
- ソースの種類任意
- ソース 0.0.0.0/0
- 目的地 169.254.169.254.
- パブリック・ネットワークを介した通信のバックアップ
- VPC クラスター・ワーカーは、プライベート・ネットワークを使用してクラスター・マスターと通信します。 以前は、パブリック・サービス・エンドポイントが有効になっている VPC クラスターでは、プライベート・ネットワークがブロックまたは使用不可の場合、クラスター・ワーカーは、パブリック・ネットワークを使用してクラスター・マスターと通信するようにフォールバックできました。 Secure by Default クラスターでは、クラスター・ワーカーからのパブリック・アウトバウンド・トラフィックがブロックされるため、パブリック・ネットワークへのフォールバックはオプションではありません。
このパブリック・ネットワーク・バックアップ・オプションを許可するために、アウトバウンド・トラフィック保護を無効にすることをお勧めします。ただし、より適切な方法があります。 代わりに、プライベート・ネットワークを介したワーカーとマスターの間の接続に一時的な問題がある場合は、その時点で、
kube-clusterIDセキュリティー・グループに一時的なセキュリティー・グループ・ルールを追加して、クラスター・マスターのapiserverポートへのアウトバウンド・トラフィックを許可することができます。 後で問題が解決されたら、一時ルールを削除できます。 - OpenShift Data Foundation および Portworx の暗号化
- パブリック・ネットワーク・アクセス権限のないクラスターで OpenShift Data Foundation または Portworx を使用する予定で、 Hyper Protect Crypto Services または Key Protect を暗号化のために使用する場合は、仮想プライベート・プライベート・ゲートウェイを作成する必要があります。 VPC 内の各サブネットから少なくとも 1 つの IP アドレスを VPE にバインドしてください。