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

Virtual Private Cloud 1.30 and later

バージョン 1.30 で作成される新しい VPC クラスタから、 IBM Cloud Kubernetes Service、Secure by Default Cluster VPC Networking と呼ばれる新しいセキュリティ機能が導入されました。 Secure by Default を使用すると、VPC クラスターの作成時に自動的に作成される新しい VPC 設定 (管理対象セキュリティー・グループ、セキュリティー・グループ・ルール、仮想プライベート・エンドポイント・ゲートウェイ (VPE) など) があります。 バージョン 1.30 以降のクラスタを作成するときに作成および管理されるVPCコンポーネントについて、以下の詳細を確認してください。

概要

Secure by Default Networking を使用すると、バージョン 1.30 以降の新しい IBM Cloud Kubernetes Service VPC クラスターをプロビジョンするときに、クラスターが機能するために必要なトラフィックのみが許可され、その他のアクセスはすべてブロックされます。 Secure by Default Networking を実装するために、 IBM Cloud Kubernetes Service は、さまざまなセキュリティー・グループおよびセキュリティー・グループ・ルールを使用してクラスター・コンポーネントを保護します。 これらのセキュリティグループとルールは自動的に作成され、ワーカーノード、ロードバランサー、およびクラスター関連のVPEゲートウェイに割り当てられます。

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

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

仮想プライベートエンドポイント（VPE）ゲートウェイ

IBM Cloud Kubernetes Service 1.28+ の最初の VPC クラスターが特定の VPC に作成されるか、その VPC 内のクラスターのマスターが 1.28+ に更新されると、さまざまな 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
IBM Cloud Kubernetes Service (カモン、インチェ、インマム) IBM Cloud Kubernetes Service API にアクセスして、クラスタの作成、ワーカープールの追加などを行います。 private.<region>.containers.cloud.ibm.com
IBM Cloud Kubernetes Service (その他の地域） IBM Cloud Kubernetes Service 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 ゲートウェイ 説明
IBM Cloud Kubernetes Service クラスタマスター この VPE ゲートウェイはクラスター・ワーカーによって使用され、VPC 内の他のものがクラスターのマスター API サーバーに接続するために使用できます。 この VPE ゲートウェイには、クラスタワーカーがいる各ゾーンから 1 つの Reserved IP が割り当てられ、この IP はクラスタワーカーがいるゾーンの VPC サブネットの 1 つに作成されます。†

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

別のVPCからクラスタマスターVPEゲートウェイにアクセスする

クラスタマスターのVPEゲートウェイは、クラスタワーカーや同じVPC内のあらゆるリソースが、プライベートネットワーク経由でクラスタマスターAPIサーバーにアクセスするために使用されます。 アカウント別のVPCからクラスタマスターにプライベート接続する必要がある場合は、その別のVPC内に、同じクラスタマスターを宛先とする追加のVPEゲートウェイを作成することができます。

これを行うには、 IBM Cloud Kubernetes Service によって作成されたクラスタマスターVPEゲートウェイのターゲットCRNを使用してください。 新しいゲートウェイには、ご自身で予約済みIPアドレスを用意する必要があります。また、セキュリティグループとそのルールを自ら作成・管理する必要があります。 VPEゲートウェイの送信ルールは適用されず、受信ルールのみが評価されます。 IBM Cloud Kubernetes Service は、ユーザーが作成したVPEゲートウェイやセキュリティグループを管理・変更することはありません。

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

IBM Cloud Kubernetes Service は、VPC クラスターの以下のセキュリティー・グループおよびルールを自動的に作成して更新します。

管理されたセキュリティ・グループ
表は、VPCクラスタ用に作成された管理対象セキュリティグループを示しています。 最初の列にはセキュリティグループ名が含まれます。 番目の欄には、命名規則が記載されている。
セキュリティー・グループ 命名規則
労働者セキュリティグループ kube-<clusterID>
マスターVPEゲートウェイのセキュリティグループ kube-vpegw-<clusterID>
共有VPEゲートウェイのセキュリティグループ kube-vpegw-<vpcID>
ロードバランサーサービスのセキュリティグループ kube-lbaas-<clusterID>

ワーカー・セキュリティー・グループ

IBM Cloud Kubernetes Service VPC クラスタを作成すると、指定したクラスタのすべてのワーカー（ノード）に対してセキュリティグループが作成されます。

  • セキュリティー・グループの名前は kube-<clusterID> です。ここで、 <clusterID> はクラスターの ID です。
  • 後で新規ノードがクラスターに追加されると、それらのノードは自動的にクラスター・セキュリティー・グループに追加されます。
  • ルールはロードバランサーによって必要に応じて動的に追加・削除される。
  • IBM Cloud Kubernetes Service kube-<clusterID> のセキュリティグループにおいて、ノードポート範囲内の および へのインバウンドルールのみを監視します。 TCP UDP IBM Cloud Kubernetes Service がノードポート範囲内にルールを検出し、それに対応するノードポートサービスが存在しない場合、そのルールを削除します。 ノードポートサービスへの着信トラフィックを許可するには、ノードポートサービスの作成後（作成前ではなく）に、 kube-<clusterID> セキュリティグループに必要なルールを追加してください。
  • kube-<clusterID> セキュリティグループに、ノードポートの範囲外で追加した追加ルールは、 IBM Cloud Kubernetes Service によって無視され、そのまま残されます。
  • kube-<clusterID> セキュリティグループ内のデフォルトルールを変更または削除しないでください。変更または削除すると、クラスタのワーカーとコントロールプレーン間のネットワーク接続に支障をきたす可能性があります。
kube-clusterID セキュリティグループのルール
この表は、クラスタワーカーセキュリティグループに適用されるルールを示しています。 最初の列には、ルールのプロトコルが含まれています。 2 番目の列には、ポートとタイプが含まれています。 3 番目の列には、ルールのリモート宛先が含まれています。 4番目の欄には、ルールの簡単な説明が書かれている。
説明 方向 プロトコル ポートまたは値 送信元 IP または宛先 IP
ポッド・サブネットへのインバウンド・トラフィックを許可します。 インバウンド 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>
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 アドレス。
1.33 and later インスタンスのメタデータ API への送信トラフィックを許可します。 アウトバウンド ICMP/ TCP / UDP すべて 169.254.169.254
4.18 and later インスタンスのメタデータ API への送信トラフィックを許可します。 アウトバウンド ICMP/ TCP / UDP すべて 169.254.169.254

** ハブおよびスポーク 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ゲートウェイのセキュリティグループのインバウンドルール
この表は、マスターVPEゲートウェイのセキュリティグループに適用されるインバウンドルールを示しています。 最初の列には、ルールのプロトコルが含まれています。 2 番目の列には、ポートとタイプが含まれています。 3 番目の列には、ルールのリモート宛先が含まれています。 4番目の欄には、ルールの簡単な説明が書かれている。
説明 方向 プロトコル ポートまたは値 送信元 IP または宛先 IP
クラスター・ワーカー・セキュリティー・グループからサーバー nodeport へのインバウンド・トラフィックを許可します。 インバウンド TCP サーバー URL ノード・ポート kube-<clusterID>
クラスター・ワーカー・セキュリティー・グループから Konnectivity ポートへのインバウンド・トラフィックを許可します。 インバウンド TCP コネクティビティ港 kube-<clusterID>
クラスタ内のすべてのアクティブなワーカープールのサブネットからのインバウンドトラフィックを許可します。* インバウンド TCP サーバー URL ノード・ポート サブネット CIDR

* すべてのアクティブなワーカー プールのサブネットに対して、1つのルールが追加される。 3つのゾーンにワーカーがいる場合、3つのルールが追加されます（ゾーン内の各サブネットに1つずつ）。

共有 VPE ゲートウェイ・セキュリティー・グループ

VPC内で最初のクラスターをプロビジョニングすると、共有VPEゲートウェイのセキュリティグループが作成されます。 セキュリティグループの名前は「 kube-vpegw-<vpcID> 」です。ここで、「 <vpcID> 」はお客様のVPCのIDです。 このセキュリティグループは、VPC内のすべての共有VPEゲートウェイに割り当てられており、どのリソースがそれらのゲートウェイを経由してトラフィックを送信できるかを制御します。

同じVPC内にクラスターが追加でプロビジョニングされるたびに、このセキュリティグループに1つのインバウンドリモートルールが追加され、新しいクラスターの kube-<clusterID> ワーカーセキュリティグループからのトラフィックが許可されるようになります。 VPC 内のクラスターごとに 1 つのルールが作成されます。 クラスタのプロビジョニング時に「 kube-vpegw-<vpcID> 」セキュリティグループがすでに存在する場合、そのグループは認識され、再利用されます。新たに作成されることはありません。

クラスターを作成するたびにセキュリティグループも追加され、1つのVPCでサポートされるセキュリティグループの最大数は100個です。 この制限はおよそ33クラスターで到達するため、VPCあたり最大25クラスターを推奨します。 詳細については、「 VPC クォータ 」を参照してください。

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

「 kube-vpegw-<vpcID> 」セキュリティグループにインバウンドルールを追加できます。たとえば、VPC内のVSIやその他のリソースが共有VPEゲートウェイにアクセスできるようにする場合などです。 IBM Cloud Kubernetes Service は、通常のクラスタ運用中に追加されたルール（VPC内で追加のクラスタがプロビジョニングされた場合を含む）を削除することはありません。 VSIが共有VPEゲートウェイにアクセスできるようにするための手順については、「 VSIがVPEゲートウェイにアクセスできないのはなぜですか？」 を参照してください。

ibmcloud ks security-group reset を実行すると、セキュリティグループ内のすべてのルール（追加したルールも含む）が削除され、 IBM Cloud Kubernetes Service のデフォルトルールのみが復元されます。

VPC内に、クラスタのプロビジョニングが行われる前に共有クラウドサービスエンドポイント（ icr.io や s3.direct など）へのアクセスを必要とするVSIやその他のリソースが含まれている場合は、「 kube-vpegw-<vpcID> 」セキュリティグループと共有VPEゲートウェイを自分で作成することができます。 後で VPC 内に IBM Cloud Kubernetes Service クラスターがプロビジョニングされると、そのクラスターは既存のセキュリティグループを検出してそれを再利用し、新しいクラスターのワーカー用セキュリティグループに対して新しいインバウンドルールを追加します。

共有VPEゲートウェイを自分で作成する場合は、そのゲートウェイに「 kube-vpegw-<vpcID> 」セキュリティグループを割り当ててください。 IBM Cloud Kubernetes Service は、自身が作成していないゲートウェイに対して、そのセキュリティグループを自動的に割り当てることはありません。

IBM Cloud Kubernetes Service 管理対象の共有VPEゲートウェイを、その名称のプレフィックスによって識別します。 IBM Cloud Kubernetes Service によって作成されたゲートウェイは、 iks- という命名規則に従います。 クラスターがVPCから削除されても、共有VPEゲートウェイおよび「 kube-vpegw-<vpcID> 」セキュリティグループは削除されません。 IBM Cloud Kubernetes Service は、自身が作成していない共有VPEゲートウェイの予約済みIPアドレスを変更することはありません。 IBM Cloud Kubernetes Service によって作成されたゲートウェイの名前を変更した場合（ iks- というプレフィックスを削除した場合）、 IBM Cloud Kubernetes Service はそのゲートウェイの予約済みIPアドレスの管理を停止します。 これは、 IBM Cloud Kubernetes Service によって作成されたゲートウェイの所有権を取得する際、既存の接続を中断することなく行うための、サポートされている方法です。

ハブ・アンド・スポーク型のVPC構成において、スポークVPCがDNS解決をハブVPCに委任している場合、スポークVPCにクラスターがプロビジョニングされると、 IBM Cloud Kubernetes Service は常にそのスポークVPC内に共有VPEゲートウェイを作成します。 これにより、スポークがハブから外れてしまった場合でも、接続が確保されます。 DNSの委任により、スポークのエンドポイントがハブを経由してルーティングされる場合、スポークのゲートウェイはDNS解決に使用されません。 スポークVPCサブネットからの着信トラフィックを許可するには、ハブの共有VPEゲートウェイのセキュリティグループを設定する必要があります。 詳細については、 「アウトバウンドトラフィック保護機能を備えたハブ・アンド・スポーク型VPCに関する考慮事項 」を参照してください。

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

各クラスターには、そのすべてのロードバランサー（ALBおよびNLB）にアタッチされている「 kube-lbaas-<clusterID> 」というセキュリティグループが1つあります。 プライベートパス NLB では、セキュリティグループの割り当てはサポートされていません。

このセキュリティグループのルールは、ロードバランサーが追加、更新、または削除されるたびに動的に生成および更新されます。 IBM Cloud Kubernetes Service は、このセキュリティグループ内のすべての受信および送信ルールを監視し、必要と認識されない余分なルールを自動的に削除します。 ibmcloud ks security-group reset を実行すると、すべてのルールが削除され、 IBM Cloud Kubernetes Service のデフォルトルールのみが復元されます。

このセキュリティグループのアウトバウンドルールは、外部ポート（ポート80や443など）がマッピングされているワーカーノードのポートへトラフィックをルーティングします。 「 kube-lbaas-<clusterID> 」セキュリティグループ内の送信ルールを一切変更または削除しないでください。

パブリックロードバランサーへのインバウンドトラフィックの制限

よくあるシナリオとして、パブリックロードバランサーへのトラフィックを送信できる送信元IPアドレスを制限することが挙げられます。 特定のポート（ TCP のポート443など）への着信トラフィックを制限するには：

  1. そのポートに対して、 kube-lbaas-<clusterID> セキュリティグループに、許可する送信元 IP アドレスまたは CIDR ブロックを指定した受信ルールを追加します。 複数のルールを作成して、複数の送信元IPアドレスを許可することができます。
  2. 許可された送信元IPアドレスのルールを作成したら、そのポートですべてのIPアドレスを許可するデフォルトの受信ルール（0.0.0.0/0 ）を削除してください。

ロードバランサーによって公開されるすべてのインバウンドポートには、少なくとも1つのルールが設定されている必要があります。そのルールは、すべてのIPアドレスを許可するデフォルトルール、または1つ以上のカスタム送信元IPルールのいずれかです。 そのポートに対して許可する送信元IPのルールを事前に追加せずに、デフォルトの「すべてのIPを許可」ルールを削除すると、 IBM Cloud Kubernetes Service は自動的に「すべてのIPを許可」ルールを再作成します。

LBaaS のカスタムセキュリティグループ

パブリックロードバランサーとプライベートロードバランサーの両方があり、それぞれに異なるファイアウォールルールを適用したい場合（たとえば、パブリックロードバランサーでは送信元IPを制限し、プライベートロードバランサーではすべてのトラフィックを許可するなど）、クラスターのデフォルト設定を使用する代わりに、 service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-security-group アノテーションを使用して、特定のロードバランサーにカスタムセキュリティグループを割り当てることができます。

カスタム LBaaS セキュリティグループを使用する場合：

  • IBM Cloud Kubernetes Service それでも、不足している必要なインバウンドルールは自動的に作成されます。
  • IBM Cloud Kubernetes Service カスタムセキュリティグループに追加したルールは、決して削除されません。
ロードバランサーのセキュリティグループルール
表は、ロードバランサーセキュリティグループに適用されるルールを示しています。 最初の列には、ルールの目的が含まれています。 2 番目の列には、ルールの方向が含まれています。 3 番目の列にはプロトコルが含まれています。 4 番目の列には、ポートまたは値が含まれています。 5列目には、ルールのリモート送信先が含まれる。
説明 方向 プロトコル ポートまたは値 送信元 IP または宛先 IP
ロード・バランサーによって開かれたノード・ポートへのアウトバウンド・アクセスを許可します。 ロード・バランサーによっては、複数のルールが存在する場合があります。 アウトバウンド 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つまで追加できます。

また、ロードバランサーのリソースに service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-security-group アノテーションを追加することで、カスタムセキュリティグループをロードバランサーに割り当てることもできます。 これは、パブリック向けとプライベート向けの両方のロードバランサーがあり、パブリック向けロードバランサーにトラフィックを送信できる対象を制限したい場合に役立ちます。 LBaaS のカスタムセキュリティグループを使用する場合、 IBM Cloud Kubernetes Service は着信トラフィック用のルールを自動的に作成しますが、ユーザーが追加した余分なルールは自動的に削除されません。 詳細については、「 LBaaS のカスタムセキュリティグループ 」を参照してください。

詳細については、 VPCセキュリティグループの作成と 管理を参照してください。

制限

ワーカー・ノードのセキュリティー・グループ
VPC クラスタ内のワーカーノードはサービスアカウント内に存在し、VPC インフラストラクチャ ダッシュボードには表示されないため、セキュリティグループを作成してワーカーノードのインスタンスに適用することはできません。 既存の「 kube-<clusterID> 」セキュリティグループのみを変更できます。
ロギングおよびモニタリング
1.30 以降のクラスターでロギングおよびモニタリングをセットアップする場合は、クラスターにロギング・エージェントをインストールするときにプライベート・サービス・エンドポイントを使用する必要があります。 パブリック・エンドポイントが使用されている場合、ログ・データは保存されません。
RHCOS ワーカー・ノードを使用したクラスターのモニター
モニター・エージェントはオペレーティング・システムのカーネル・ヘッダーに依存していますが、RHCOS にはカーネル・ヘッダーがありません。 このシナリオでは、エージェントは sysdig.com に戻り、プリコンパイルされたエージェントを使用します。 パブリック・ネットワーク・アクセスがないクラスタでは、このプロセスは失敗します。 eBPF は、新しい Sysdig のデプロイメントでデフォルトで有効になりました。 ただし、既存のクラスタで問題が発生している場合は、 eBPF が有効になっているかどうかを確認し、必要に応じて有効にして ください。 あるいは、アウトバウンドトラフィックを許可するか、 エアギャップ環境にエージェントをインストールするためのSysdigのドキュメントを参照してください。
VPC クラスターの割り当て量
クラスタを作成するたびに、VPCにセキュリティグループが追加されます。VPCに作成できるセキュリティグループの最大数は100個です。 この制限はおよそ33クラスターで到達するため、VPCあたり最大25クラスターを推奨します。 詳細については、「 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 にバインドしてください。