IBM Cloud Docs
デフォルトでセキュアなクラスタVPCネットワーキングを理解する

デフォルトでセキュアなクラスタ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ゲートウェイにアタッチされます。

VPCセキュリティ・グループ
この画像は、VPCとクラスタに適用されているVPCセキュリティ・グループを示しています

仮想プライベート・クラウドのセキュリティー・グループは、ハイパーバイザー・レベルでトラフィックをフィルタリングします。 セキュリティー・グループのルールは特定の順序で適用されるわけではありません。 ただし、ワーカー・ノードへの要求は、指定したルールのいずれかに一致した場合にのみ許可されます。 インバウンド・ルールまたはアウトバウンド・ルールを作成して、ある方向のトラフィックを許可すると、その反対方向の応答も許可されます。 セキュリティー・グループは追加式です。つまり、ワーカー・ノードに複数のセキュリティー・グループを関連付けると、それらのセキュリティー・グループに含まれているすべてのルールがワーカー・ノードに適用されます。 新しいクラスター・バージョンでは、古いクラスター・バージョンよりも多くのルールが 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 が割り当てられます。

共有VPEゲートウェイ

VPC クラスターを作成すると、以下の VPE ゲートウェイが自動的に作成されます。

共有VPEゲートウェイ
表に、VPCクラスタ用に作成されたVPEゲートウェイを示します。 最初の列には、ゲートウェイの名前が含まれています。 番目の欄には簡単な説明が書かれている。 3列目はDNS名。
VPE ゲートウェイ 説明 DNS 名
IBM Cloud Container Registry IBM Cloud Container Registry からコンテナイメージをクラスタ内で動作するアプリにプルする。 icr.io, *.icr.io
IBM Cloud Object Storage s3 ゲートウェイ IBM Cloud Object Storage APIにアクセスする。 s3.direct.<region>.cloud-object-storage.appdomain.cloud, *.s3.direct.<region>.cloud-object-storage.appdomain.cloud
IBM Cloud Object Storage 構成ゲートウェイ コンテナイメージのバックアップ先 IBM Cloud Object Storage config.direct.cloud-object-storage.cloud.ibm.com
Red Hat OpenShift on IBM Cloud (カモン、インチェ、インマム) Red Hat OpenShift on IBM Cloud API にアクセスして、クラスタの作成、ワーカープールの追加などを行います。 private.<region>.containers.cloud.ibm.com
Red Hat OpenShift on IBM Cloud (その他の地域) Red Hat OpenShift on IBM Cloud API にアクセスして、クラスタの作成、ワーカープールの追加などを行います。 api.<region>.containers.cloud.ibm.com
IBM Cloud VPC VPC APIにアクセスして、VPC Infrastructure as a Service ( IaaS ) の一部であるリソースをプロビジョニングおよび管理します。 <region>.private.iaas.cloud.ibm.com

非共有VPEゲートウェイ

サポートされるすべてのVPCクラスタには、クラスタの作成時にアカウント作成されるクラスタ・マスタ用のVPEゲートウェイがあります。

非共有VPEゲートウェイ
表に、VPCクラスタ用に作成されたVPEゲートウェイを示します。 最初の列には、ゲートウェイの名前が含まれています。 番目の欄には簡単な説明が書かれている。
VPE ゲートウェイ 説明
Red Hat OpenShift on IBM Cloud クラスタマスター この VPE ゲートウェイはクラスター・ワーカーによって使用され、VPC 内の他のものがクラスターのマスター API サーバーに接続するために使用できます。 この VPE ゲートウェイには、クラスタワーカーがいる各ゾーンから 1 つの Reserved IP が割り当てられ、この IP はクラスタワーカーがいるゾーンの VPC サブネットの 1 つに作成されます。†

例えば、クラスタが単一のゾーンリージョン(us-east-1)と単一のVPCサブネットのみにワーカーを持つ場合、そのサブネットに単一のIPが作成され、VPEゲートウェイに割り当てられます。 クラスターの 3 つのゾーンすべて ( us-east-1us-east-2us-east-3 など) にワーカーがあり、これらのワーカーが各ゾーンの 4 つの VPC サブネットに分散されている場合、12 個の VPC サブネットがまとめて作成され、各ゾーンに 1 つずつ、そのゾーンの 4 つの VPC サブネットの 1 つに 3 つの IP が作成されます。 サブネットはランダムに選択されることに注意してください。

管理対象セキュリティー・グループ

Red Hat OpenShift on IBM Cloud は、VPC クラスターの以下のセキュリティー・グループとルールを自動的に作成して更新します。

管理されたセキュリティ・グループ
表は、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> セキュリティー・グループ内のルールは変更しないでください。変更すると、クラスターのワーカーと制御クラスターの間のネットワーク接続が中断される可能性があります。
kube-clusterID セキュリティグループのルール
この表は、クラスタワーカーセキュリティグループに適用されるルールを示しています。 最初の列には、ルールのプロトコルが含まれています。 2 番目の列には、ポートとタイプが含まれています。 3 番目の列には、ルールのリモート宛先が含まれています。 4番目の欄には、ルールの簡単な説明が書かれている。
説明 方向 プロトコル ポートまたは値 ソースまたは宛先
ポッド・サブネットへのインバウンド・トラフィックを許可します。 インバウンド 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からのトラフィックが許可されます。

マスターVPEゲートウェイのセキュリティグループのインバウンドルール
この表は、クラスタワーカーセキュリティグループに適用される受信ルールを示しています。 最初の列には、ルールの目的が含まれています。 2 番目の列には、ルールの方向が含まれています。 3 番目の列にはプロトコルが含まれています。 4 番目の列には、ポートまたは値が含まれています。 5番目の列には、ルールのリモート宛先が含まれる。
説明 方向 プロトコル ポートまたは値 ソースまたは宛先
クラスター・ワーカー・セキュリティー・グループからサーバー 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 割り当て量 を参照してください。

共有VPEゲートウェイセキュリティグループのインバウンドルール
この表は、共有VPEゲートウェイのセキュリティグループに適用されるインバウンドルールを示しています。 最初の欄には、ルールの目的が書かれている。 2 番目の列には、ルールの方向が含まれています。 3 番目の列にはプロトコルが含まれています。 4列目には、ルールのリモート送信先が含まれる。
説明 方向 プロトコル ソースまたは宛先
指定されたクラスターからのインバウンド・トラフィックを許可します。 インバウンド TCP kube-<clusterID>

ロード・バランサー・サービス・セキュリティー・グループ

すべてのロード・バランサー (ALB および NLB) に接続されているデフォルトのセキュリティー・グループ。

  • 各クラスターは、クラスター内のすべてのロード・バランサーによって共有される独自の固有のセキュリティー・グループを取得します。
  • セキュリティグループの名前は kube-lbaas-<clusterID> で、<clusterID> はクラスタのIDです。
  • このセキュリティー・グループのルールは、ロード・バランサーが追加、削除、または更新されると、動的に追加または削除されます。 SDNLB は、セキュリティー・グループの接続をサポートしていないことに注意してください。
  • このセキュリティグループにルールを追加できる。 ただし、他のルールと互換性がない場合、あるいは機能を破壊する場合は、いくつかのルールが削除される可能性がある。
ロードバランサーのセキュリティグループルール
表は、ロードバランサーセキュリティグループに適用されるルールを示しています。 最初の列には、ルールの目的が含まれています。 2 番目の列には、ルールの方向が含まれています。 3 番目の列にはプロトコルが含まれています。 4 番目の列には、ポートまたは値が含まれています。 5番目の列には、ルールのリモート宛先が含まれる。
説明 方向 プロトコル ポートまたは値 ソースまたは宛先
ロード・バランサーによって開かれたノード・ポートへのアウトバウンド・アクセスを許可します。 ロード・バランサーによっては、複数のルールが存在する場合があります。 アウトバウンド 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 にバインドしてください。