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

仮想プライベートクラウド 1.29 およびそれ以前

以下の手順では、 1.30 より前に作成されたクラスターにおいて、「デフォルトでセキュア」機能の導入に伴い追加されたセキュリティグループの設定を有効にする方法について説明します。 「デフォルトでセキュアなネットワーク」の導入により、 1.30 以降で新規にプロビジョニングされたVPCクラスターに対して、セキュリティグループの設定と動作が新たに導入されました。 1.29 以前のバージョンで作成されたクラスターは、 1.30 に更新した際、デフォルトでセキュアなセキュリティグループ設定が適用されませんでした。

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

「デフォルトでセキュリティを有効にする」設定の準備

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

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

  • クラスタがデフォルトでセキュアになっていないことを確認する。 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内のクラスター数は25未満でなければなりません。 クラスターを作成するたびにセキュリティグループが追加され、1つのVPCでサポートされるセキュリティグループの最大数は100個です。 この上限はおよそ33クラスターで達するため、VPCあたり25クラスターが推奨される最大数となります。
    • 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 内に1.30以降のデフォルトでセキュアなクラスタがある場合、これはすでに実行されている可能性があります。
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 ks vpc secure-by-default enable --cluster <CLUSTER ID> [--disable-outbound-traffic-protection][-f]

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

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

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

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