4.14以前のバージョンで作成されたクラスタに対してデフォルトでセキュアを有効にする

Virtual Private Cloud 4.4.14以前

以下の手順では、4.15より前に作成されたクラスタでsecure by defaultとともに導入されたセキュリティ・グループ設定を有効にする方法を説明します。 Secure by default networkingでは、4.15以降で新たにプロビジョニングされたVPCクラスタに対して、新しいセキュリティグループ構成と動作が導入されました。 バージョン4.14およびそれ以前のバージョンで作成されたクラスタが、4.15に更新されたときにデフォルトのセキュリティグループ構成でセキュアになりませんでした。

クラスター上でデフォルトでセキュアを有効にすると、永続的に設定され、元に戻せません。 有効化プロセスでは、クラスタ内のすべてのワーカーノードを交換する必要があります。 デフォルトで保護を有効にすることが有益な場合にのみ、これを行ってください。 ワーカーをすべて置き換えるまで、ロード・バランサーにアクセスできない可能性があることに注意してください。 詳しくは、「デフォルトでセキュア」 を参照してください。

デフォルトでセキュアを有効にする準備

クラスタでセキュアをデフォルトで有効にすると、クラスタが機能するために必要なトラフィックのみが許可され、それ以外のアクセスはすべてブロックされることを理解してほしい。

  • クラスタがデフォルトでセキュアをサポートするバージョンであることを確認してください。 クラスターを少なくとも 4.15 に更新してください。

  • クラスタがデフォルトでセキュアになっていないことを確認する。 ibmcloud ks cluster get 実行し、その出力を確認すればわかる。

  • どのワーカーノードも現在プロビジョニング状態でないことを確認します。

    Retrieving cluster CLUSTER...
OK

Name:                           CLUSTER
ID:                             CLUSTER
State:                          normal
Status:                         All Workers Normal
...
Secure By Default Networking:   enabled
Outbound Traffic Protection:    enabled

  • 以下のノルマを超えないことを確認してください。 以下のクォータを超えた場合、イネーブルメントプロセスは失敗します。 詳細については、VPCクォータ を参照してください。

    • VPC内のクラスタ数が15以下である必要があります。 他のセキュリティグループを送信元または宛先とするルールは最大15個まで。 デフォルトでは、Red Hat OpenShift on IBM CloudはVPC内の各クラスタに対して「kube-<clusterID> セキュリティグループをターゲットとするルールを1つ適用します。 このクォータのため、特定のVPCには15クラスタしか作成できません。
    • VPC内のセキュリティグループは95個以下でなければなりません。 VPCには最大100のセキュリティグループを設定できます。 デフォルトでセキュアを有効にすると、4つのセキュリティグループが作成される。 セキュリティ・グループがすでに100近くある場合は、セキュリティ・グループを減らすか統合することを検討してから進めてください。
    • クラスターワーカーのセキュリティグループは4つ以下でなければなりません。 クラスターワーカーは最大5つのセキュリティグループを持つことができます。 デフォルトでセキュアを有効にすると、ワーカーにセキュリティグループが1つ追加されます。

  • 既存のクラスタワーカーセキュリティグループ（kube-<clusterID>）にカスタムセキュリティグループルールがある場合、それらは有効化中に削除されます。 これらのルールを維持したい場合は、前もってメモしておき、イネーブルメント後に追加する。

デフォルトでセキュアを有効にするとどうなりますか？

デフォルトでセキュア」を有効にすると、以下の「デフォルトでセキュア」セキュリティグループのセットが作成または更新されます。

デフォルトでセキュアを有効にした場合のセキュリティグループの変更
セキュリティー・グループ 変更内容
kube-<clusterID> クラスタワーカーセキュリティグループ(kube-<clusterID>)がリセットされました。 このセキュリティグループはクラスタワーカーにアタッチされます。 通常、このグループはすでに存在している。 しかし、現在ワーカーがユーザー定義のカスタムセキュリティグループのみを使用している場合、このセキュリティグループはクラスタの初期作成時に作成されていないはずです。 この場合、このグループが作成される。 既存のルールはすべて削除され、デフォルトで安全な新しいセキュリティグループルールがこのセキュリティグループに追加される。 ロードバランサはクラスタワーカーとロードバランサのセキュリティグループの両方にルールを適用します。
kube-vpegw-<clusterID> マスターVPEゲートウェイの新しいセキュリティグループが作成される。 既存のルールはすべて削除される。 新しいグループだから、ルールがないことがほとんどだろう。
kube-vpegw-<vpcID> 共有VPEゲートウェイ用の新しいセキュリティグループ。 VPC内にデフォルトでセキュアなクラスタが存在する場合、このセキュリティ・グループがすでに存在する可能性があります。 このグループはすべてのクラスタで共有されるため、作成は1回のみです。 以前の VPE ゲートウェイのセキュリティグループ (kube-<vpcID>) は、IBMすべての共有 VPE ゲートウェイから削除され、新しい共有 VPE ゲートウェイのセキュリティグループ (kube-vpegw-<vpcID>) に置き換えられます。VPC 内に4.15以降のデフォルトでセキュアなクラスタがある場合、これはすでに実行されている可能性があります。
kube-lbaas-<clusterID> ロードバランサー用の新しいセキュリティグループ。 ロードバランサー（NLBとALB）に接続されているセキュリティグループが更新されます。 以前のロードバランサのセキュリティグループ (kube-<vpcID>) はロードバランサから削除され、 新しいロードバランサのセキュリティグループ (kube-lbaas-<clusterID>) に置き換えられます。前のセキュリティグループがロードバランサに存在しない場合は、何もしません。 IBMロードバランサーとセキュリティグループのみが影響を受けます。 カスタムセキュリティグループは削除されない。
kube-<vpcID> 以前の VPE ゲートウェイのセキュリティグループ (kube-<vpcID>) がマスター VPE ゲートウェイから削除され、新しいマスター VPE ゲートウェイのセキュリティグループ (kube-vpegw-<clusterID>) に置き換えられます。
デフォルトのVPCセキュリティグループ デフォルトのVPCセキュリティグループは使用されなくなりました。
カスタム・セキュリティ・グループ クラスタワーカーノードにアタッチされているユーザー定義のセキュリティグループは、すべて新しいワーカーにアタッチされます。 カスタムセキュリティグループは削除されない。

どのような順番で変更が適用されるのですか？

デフォルトでは、クラスタをセキュアに更新すると以下の操作が実行されます。

  1. デフォルトでセキュアなセキュリティー・グループが存在しない場合は、以下のセキュリティー・グループが作成される。

    • kube-<clusterID>
    • kube-vpegw-<clusterID
    • kube-vpegw-<vpcID>
    • kube-lbaas-<clusterID>

  2. VPEゲートウェイに接続されているセキュリティグループが更新される。 IBMゲートウェイとセキュリティグループのみが影響を受けます。 カスタムのセキュリティグループには影響はない。 以前のセキュリティグループがゲートウェイに存在しない場合は、何もしない。

  3. 以前の VPE ゲートウェイのセキュリティグループ (kube-<vpcID>) がマスター VPE ゲートウェイから削除され、新しいマスター VPE ゲートウェイのセキュリティグループ (kube-vpegw-<clusterID>) に置き換えられます。

  4. 以前の VPE ゲートウェイのセキュリティ・グループ (kube-<vpcID>) は、IBMすべての共有 VPE ゲートウェイから削除され、新しい共有 VPE ゲートウェイのセキュリティ・グループ (kube-vpegw-<vpcID>) に置き換えられます。VPC 内にデフォルトでセキュアな他のクラスタがある場合、これはすでに発生している可能性があります。

  5. ロードバランサー（NLBとALB）にアタッチされているセキュリティグループが更新されます。 IBMロードバランサーとセキュリティグループのみが更新されます。 カスタムのセキュリティグループには影響はない。 前のセキュリティグループがロードバランサーに存在しない場合は、何もしません。

  6. 以前のロードバランサのセキュリティグループ (kube-<vpcID>) がロードバランサから削除され、 新しいロードバランサのセキュリティグループ (kube-lbaas-<clusterID>) に置き換わります

  7. クラスタワーカーセキュリティグループ(kube-<clusterID>)がリセットされました。

    • 既存のルールはすべて削除される。
    • 新しいセキュア・バイ・デフォルト・セキュリティー・グループ・ルールが追加されました。

  8. ロードバランサーのルールはクラスターワーカーとロードバランサーのセキュリティグループの両方に適用されます。

  9. マスターVPEゲートウェイのセキュリティグループがリセットされる。

    • 既存のルールはすべて削除される。 しかし、これは（ステップ1で）新しく作成されたものなので、通常はルールはない。
    • 新しいセキュア・バイ・デフォルト・セキュリティー・グループ・ルールが追加された。

前のステップは自動的に処理される。 ただし、セキュア以前に作成されたクラスタは、デフォルトでワーカーにデフォルトのVPCセキュリティ・グループがアタッチされています。 このセキュリティグループは削除しなければならないが、IBMが提供するオートメーションでは削除できない。 そのため、手動で作業員を入れ替えて更新作業を完了させる必要があります。 ワーカーの交代中に、次のようなアップデートが行われる。

  1. クラスタワーカーのセキュリティグループ (kube-<clusterID>) と、以前に追加されたユーザー定義のセキュリティグループが、新しいワーカーにアタッチされます。

  2. デフォルトのVPCセキュリティグループは使用されなくなりました。

デフォルトでセキュアを有効にする

以下の手順を実行して、デフォルトで安全なセキュリティ・グループ設定をクラスタに適用します。

  1. 次のコマンドを実行します。

    ibmcloud oc vpc secure-by-default enable --cluster <CLUSTER ID> [--disable-outbound-traffic-protection][-f]

  2. プロセスが完了するまで待ってください。 クラスタがデフォルトでセキュアになるまでの時間は、さまざまな要因によって左右されます。 通常は5分以内に終わる。 新しいセキュリティーグループを検査することで、プロセスが終了したことを確認できます。

    • マスターVPEゲートウェイのセキュリティグループ kube-vpegw-CLUSTERID にはルールが含まれています。
    • ロードバランサーのセキュリティグループ kube-lbaas-CLUSTERID はルールを含んでいます。

  3. クラスタ内のすべてのワーカーノードを交換します。

    ibmcloud oc worker replace --cluster CLUSTER --worker WORKER -f