クラスタのシークレットとワーカーノードのHPCSからの移行 Key Protect

仮想プライベートクラウド クラシック・インフラストラクチャー

Key Protect 移行ツールを使用して、 Hyper Protect Crypto Services (HPCS) から IBM® Key Protect for IBM Cloud® にクラスタ秘密暗号化、ワーカープール、およびワーカーノードディスク暗号化を移行できます。 このプロセスは、クラスタ・シークレット、暗号化ワーカー、ワーカー・プールの暗号化キーとインスタンス参照、使用状況を更新します。

移行に必要なリソースの数によっては、移行処理に1時間以上かかることもあります。 それなりの計画を立てるように。

開始前に

HPCS から Key Protect に移行する前に、以下の要件と考慮事項を確認してください。

  • Key Protect インスタンスとルート・キーが作成されている必要があります。 詳細については、 鍵管理サービス（KMS）プロバイダーの設定を 参照。
  • クラスターで KMS を有効にするには、 IBM Cloud （ Identity and Access Management、IAM）で適切な権限を持っている必要があります。 詳細については、 鍵管理サービス（KMS）プロバイダーの設定を 参照。
  • サービス間の認可ポリシーは、キー・リングやキー・レベルではなく、 Key Protect インスタンスまたはサービス・レベルで設定されなければならない。 これは現在の制限で、ワーカーノードとクラスタの秘密の暗号化の両方に適用されます。

移行が完了し、その成功が確認されるまで、HPCSルート・キーを削除しないでください。

ステップ 1. サービス間認可の設定

HPCS から Key Protect に移行する前に、 IBM Cloud IAM で必要なサービス間承認ポリシーを設定する必要があります。 このステップは、クラスタ・シークレットとワーカー・ノードについて個別に完了する必要があります。 なお、これらのポリシーはすでに導入されている可能性があり、その場合は作り直す必要はない。

クラスタ秘密暗号化の認可

クラスタ秘密暗号化を移行するには、 IBM Cloud Kubernetes Service から Key Protect インスタンスへのサービス認可ポリシーが必要です。

  1. IBM Cloud コンソールの サービス認可ページに移動する。
  2. 「作成」 をクリックします。
  3. クラスタが現在のアカウント存在する場合は、 ソースアカウント を このアカウント に設定します。 クラスタが別のアカウントある場合は、 その他のアカウント を選択し、 アカウント IDを入力します。
  4. **「ソース・サービス」を「Kubernetes Service」**に設定します。
  5. ターゲット・ サービスを Key Protect.
  6. Key Protect、 サービスまたはインスタンス・ レベルに認可の範囲を設定する。 特定のキーホルダーやキーに固定しないでください。
  7. **「リーダー」**以上のサービス・アクセス権限を含めます。
  8. ソース・サービスと依存サービスが許可を委任できるようにします。
  9. 「許可」 をクリックします。

ワーカーノードのディスク暗号化のための権限

VPC クラスタのワーカー・ノード・ディスク暗号化を移行するには、 IBM Cloud Kubernetes Service と Cloud Block Storage の両方のサービス承認ポリシーが Key Protect インスタンスに必要です。

IBM Cloud Kubernetes Service の認証を作成するには、以下の手順に従ってください。 これらのポリシーがすでに存在する場合は、再作成する必要はない。

  1. IBM Cloud コンソールの サービス認可ページに移動する。
  2. 「作成」 をクリックします。
  3. クラスタが現在のアカウント存在する場合は、 ソースアカウント を このアカウント に設定します。 クラスタが別のアカウントある場合は、 その他のアカウント を選択し、 アカウント IDを入力します。
  4. **「ソース・サービス」を「Kubernetes Service」**に設定します。
  5. ターゲット・ サービスを Key Protect.
  6. Key Protect、 サービスまたはインスタンス・ レベルに認可の範囲を設定する。 特定のキーホルダーやキーに固定しないでください。
  7. **「リーダー」**以上のサービス・アクセス権限を含めます。
  8. ソース・サービスと依存サービスが許可を委任できるようにします。
  9. 「許可」 をクリックします。

Cloud Block Storage の認証を作成するには、以下の手順に従ってください。

  1. IBM Cloud コンソールの サービス認可ページに移動する。
  2. 「作成」 をクリックします。
  3. クラスタが現在のアカウント存在する場合は、 ソースアカウント を このアカウント に設定します。 クラスタが別のアカウントある場合は、 その他のアカウント を選択し、 アカウント IDを入力します。
  4. **「ソース・サービス」を「Cloud Block Storage」**に設定します。 CLIでは、ソース・サービスは server-protectと呼ばれることに注意。
  5. ターゲット・ サービスを Key Protect.
  6. Key Protect、 サービスまたはインスタンス・ レベルに認可の範囲を設定する。 特定のキーホルダーやキーに固定しないでください。
  7. **「リーダー」**以上のサービス・アクセス権限を含めます。
  8. 「許可」 をクリックします。

Red Hat OpenShift on IBM Cloud は、 IBM-managedサービスアカウント Cloud Block Storage サービスに対して、 Key Protect インスタンスへの追加のサービス間委任ポリシーを自動的に作成します。 この委任ポリシーは、VPCインフラストラクチャがワーカーノードのブートボリュームを Key Protect ルートキーで暗号化できるようにするために必要です。 移行後に問題が発生した場合は、 IAM権限にこの委任された権限ポリシーが存在することを確認してください。

ステップ 2. 移行のための主要な使用法を特定する

アカウント内のどのリソースを HPCS から Key Protect に移行する必要があるかを確認します。 使用法を特定するためのさまざまな方法については、 Key Protect ドキュメントの 「使用法の検索 」を参照のこと。

各クラスタについて、 ibmcloud kp registrations -i KMS_INSTNACE_ID KEY_ID コマンドでキー登録を表示できます。 出力は以下のキー登録を示す： - クラスターシークレットの登録は1つ - 暗号化されたワーカープールごとに 1つの登録 - 暗号化されたワーカー ごとに 1つの登録

登録内容は、次のようなものになるかもしれません：

"crn:v1:staging:public:containers-kubernetes:us-south:a/1152aa1c1ec54274ac42b8ad8507c90c:d70mi70206f7fchch5h0::
crn:v1:staging:public:containers-kubernetes:us-south:a/1152aa1c1ec54274ac42b8ad8507c90c:d79qqpt20aca2a0ii8v0:worker-pool:d79qqpt20aca2a0ii8v0-edea88a
crn:v1:staging:public:is:us-south-1:a/e2523561f3864f058711d94392c19e9b::volume:r134-799cdc60-c598-4a58-913b-b29ad312a143

オプション：Key Usage Reporterツールの使用

このツールはアカウントスキャンし、使用中のHPCSキーのレポートを提供します。 この検出ツールは、HPCSキーで秘密の暗号化が有効になっているクラスタと、HPCSキーでワーカー・ノードのディスク暗号化が有効になっているワーカー・プールを特定するのに役立ちます。 レポート出力には、クラスタ・シークレット、ワーカー、ワーカー・プールが、特定のHPCSキーとインスタンスに関連付けられた個別のリソースとして表示されます。 検出ツールの詳細な実行方法については、 Key Protect ドキュメントの「 HPCSキー使用の検出 」を参照してください。

KURツールは、すべてのHPCS利用ケースを表示するとは限らないので、利用を特定するためのすべての方法を確認することが重要である。 アカウントアカウントKMSインスタンスを使用する場合は、すべての関連アカウント KURツールを実行する必要があります。

ステップ 3. 移行ツールの実行

HPCSキーを使用するリソースを特定し、必要なサービス権限を設定したら、 Key Protect 移行ツールを使用して暗号化キーを移行します。 この手順を完了する前に、 必要なサービス間承認ポリシーが 作成されていることを確認してください。

マイグレーション・ツールの詳細な実行方法については、 Key Protect ドキュメントの「 Key Protect へのマイグレーション 」を参照。

移動中に起こること

移行ツールを実行すると、次のようなアクションが発生します：

クラスター秘密の暗号化
マイグレーションは、 Key Protect 鍵の登録作成をトリガーする。 その後、HPCS鍵の代わりに Key Protect 鍵を用いてデータ暗号鍵を再暗号化する。 その後、登録はHCPSキーから削除される。 操作中に予想されるダウンタイムはなく、クラスタは正常に機能し続けます。
ワーカー・ノードのディスク暗号化
  • 暗号化ワーカープールの場合 ：マイグレーションは、暗号化されたワーカーのワーカープールでのキー登録の作成をトリガーします。 HPCSインスタンスとキーへの参照は、 Key Protect インスタンスとキーを指すように更新される。 その後、登録はHPCSキーから削除される。 ワーカープールに追加された新しいワーカーは、更新されたキー情報を使用するようになりました。 作業中のダウンタイムは予想されず、ワーカープールは正常に機能し続けます。
  • 個々のワーカーの場合 ：マイグレーションは、 Key Protect キーにキー登録を作成するトリガーとなる。 その後、HPCS鍵の代わりに Key Protect 鍵を用いてデータ暗号鍵を再暗号化する。 その後、登録はHCPSキーから削除される。 手術中のダウンタイムは予想されず、労働者は通常通り機能し続ける。

移行中、 Red Hat OpenShift on IBM Cloud は、 IBM-managedサービスアカウント内の Cloud Block Storage サービスに対して、 Key Protect インスタンスへの追加のサービス間委譲ポリシーを自動的に作成する。 この委任ポリシーは、VPCインフラストラクチャがワーカーノードのブートボリュームを Key Protect ルートキーで暗号化できるようにするために必要です。 移行中または移行後に問題が発生した場合は、 IAM権限にこの委譲権限ポリシーが存在することを確認してください。

ステップ 4. 移行の検証

移行が完了したら、クラスタが Key Protect キーを使用していることを確認します。

  1. クラスタのステータスを確認し、マスターが準備できていることを確認する。

    ibmcloud oc cluster get -c CLUSTER_NAME_OR_ID

    出力で、 マスター・ステータスが Ready であること、および鍵管理サービスが Key Protect インスタンスのKMSインスタンスIDとKMSルート鍵IDを表示していることを確認する。

  2. ワーカー・ノードの暗号化では、ワーカー・プールが Key Protect キーを参照していることを確認する。

    ibmcloud oc worker-pool get --worker-pool WORKER_POOL_NAME_OR_ID --cluster CLUSTER_NAME_OR_ID

    出力の KMS フィールドと CRK フィールドを確認し、 Key Protect インスタンスとルート・キーを参照していることを確認する。

  3. クラスタ・シークレットにアクセスできることを確認します。

    oc get secrets --all-namespaces

  4. Key Protect、クラスタ、ワーカー、ワーカー・プールが新しいルート・キーに登録されていること、および古いHPCSキーにキー登録が存在しないことを確認します。 詳細については、 ルート・キーと暗号化された IBM Cloud ・リソースとの関連を表示するを 参照のこと。

次のステップ

Key Protect への移行に成功し、移行を確認した後：

  • クラスタに暗号化やキーアクセスに関する問題がないか監視する。
  • HPCSインスタンスを参照しているドキュメントやランブックを更新します。
  • セキュリティ・ポリシーに従って、 Key Protect ルート・キーをローテーションする ことを検討してください。