概要

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 クラスターの以下のセキュリティー・グループとルールを自動的に作成して更新します。

ユーザー提供 Security Groups

VPCクラスタを作成する際、所有するセキュリティ・グループを最大4つまで追加できます。

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

制限

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

VPC クラスタのワーカーノードはサービスアカウント存在し、VPC インフラストラクチャのダッシュボードには表示されないため、セキュリティグループを作成してワーカーノードインスタンスに適用することはできません。 変更できるのは、既存の kube-<clusterID> セキュリティグループのみです。

ロギングおよびモニタリング

4.15 以降のクラスターでロギングとモニタリングをセットアップする場合は、クラスターにロギング・エージェントをインストールするときにプライベート・サービス・エンドポイントを使用する必要があります。 パブリック・エンドポイントが使用されている場合、ログ・データは保存されません。

RHCOS ワーカー・ノードを使用したクラスターのモニター

モニター・エージェントはオペレーティング・システムのカーネル・ヘッダーに依存していますが、RHCOS にはカーネル・ヘッダーがありません。 このシナリオでは、エージェントは sysdig.com に戻り、プリコンパイルされたエージェントを使用します。 パブリック・ネットワーク・アクセスがないクラスタでは、このプロセスは失敗します。 eBPF は、新しい Sysdig のデプロイメントでデフォルトで有効になりました。 ただし、既存のクラスタで問題が発生している場合は、 eBPF が有効になっているかどうかを確認し、必要に応じて有効にして ください。 あるいは、アウトバウンドトラフィックを許可するか、 エアギャップ環境にエージェントをインストールするための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 にバインドしてください。