COS の Hyper Protect Crypto Services から Key Protect への移行
IBM Cloud Object Storage s3fs プラグイン用の Hyper Protect Crypto Services (HPCS) 暗号化を、代わりに Key Protect (KP) を使用するように移行します。
開始前に
作業を始める前に、以下の手順に従って、COSプラグインをHPCSの代わりに Key Protect を使用するように移行する必要があるかどうかを判断してください。
-
HPCSとKPインスタンスのCRNを取得します。 各インスタンスに対して以下のコマンドを実行する。
ibmcloud resource service-instance <instance-name>出力例。
Name: my-hpcs-instance ID: crn:v1:bluemix:public:kms:us-south:a/1ab234cd5e678fgh9a0123bc4de567:f89gh01a-bcd2-3456-e789-f0g1234h5ab6:: -
ibm/ibmc-s3fsタイプのクラスタ内のすべてのシークレットをリストします。kubectl get secrets --field-selector type=ibm/ibmc-s3fs -
それぞれの
ibm/ibmc-s3fs秘密について、 秘密の内容を確認し、dataセクションでkp-root-key-crnルートキーを見つける。 文字列hs-cryptoを含むkp-root-key-crn値を持つ秘密鍵は、HPCSルート鍵であり、移行が必要であることを示す。 移行する秘密のリストを保存する。hs-cryptoを含むkp-root-key-crnの値がない場合は、移行の手順を実行する必要はありません。
移行の前提条件
始める前に、以下のステップを完了してください。
- クラスタにCOS helm chartがインストールされている場合は、それが 最新バージョンで動作していることを確認してください。
- まだ持っていない場合は、新しい Key Protect インスタンスと暗号化用の Key Protect キーのセットを作成する。 Key Protect インスタンスがクラスタと同じリージョンに作成されていることを確認してください。 これは、 Key Protect インスタンスがCOSリソースにアクセスするために必要です。
- Key Protect、COSリソースにアクセスするための サービス間認可を作成 します。 ソースサービスを Key Protect、 ターゲットサービスをCOSに設定し、アクセスレベルを少なくともリーダーに設定する。
マイグレーション手順
COS プラグインを Key Protect に移行するには、以下の手順に従ってください。
すべてのCOSシークレットとPVCが特定のネームスペースにある場合、以下の手順をそのネームスペースにスコープできます。 そうでない場合は、クラスタ上のすべてのnamesapcesを検索する。
ステップ 1. 移行するPVCのリスト
どのPVCを移行しなければならないかを決定する。
- クラスタまたは関連するネームスペースにあるすべてのPVCをリストします。
oc get pvc [-n <namespace>] - それぞれのPVCについて説明してください。
oc describe pvc <pvc-name> - PVCの出力で Annotations セクションを見つけ、
volume.kubernetes.io/storage-provisioner: ibm.io/ibmc-s3fs。 - 注釈がリストアップされている場合は、
ibm.io/secret-name注釈を探す。 volume.kubernetes.io/storage-provisioner: ibm.io/ibmc-s3fs注釈がリストされ、ibm.io/secret-name値が HPCS ルート・キーを持つことが判明したシークレットのいずれかと一致する場合、その PVC を移行する必要があります。 PVC名に注意。- 各PVCに対してこの手順を繰り返す。 移行するPVCのリストを保存する。
ステップ 2 移行するポッドをリストする
移行するポッドを決定します。
- クラスターまたは関連するネームスペースにあるすべてのポッドをリストします。
oc get pods [-n <namespace>] - それぞれのポッドについて説明してください。
oc describe pod <pod-name> - 出力で、 Volumes セクションを見つけ、それぞれの名前をチェックする。 PersistentVolumeClaim. 出力されたポリ塩化ビニールのいずれかが、移行するポリ塩化ビニールのリストにも含まれている場合、そのポッドは移行されなければならない。 ポッドの名前に注意してください。
- ポッドごとにこの手順を繰り返す。 移行するポッドのリストを保存します。
ステップ 3。 新しい秘密を作る
HPCSルート・キーの代わりに Key Protect ルート・キーを使用する新しい秘密を作成する。
-
Key Protect インスタンスの CRN を取得し、 base64 にエンコードする。
ibmcloud resource service-instance <kp-instance-name>echo -n "<root_key_CRN>" | base64 -
移行しなければならない各秘密について、秘密のyamlを取得する。
oc get secret <secret-name> -o yaml -
yamlをファイルにコピーして、新しいシークレットを作成する。 代わりに Key Protect インスタンスの base64 エンコードされた CRN を指すように
kp-root-key-crnを変更する。 新しいシークレットと古いシークレットを区別するために、シークレット名の最後に文字列を追加する。PVCの再作成時には、PVCで使用されるシークレットの新しいコピーを指定する必要があります。 新しいシークレットの名前は、古いシークレットに対応するもので、なおかつ2つのシークレットを区別できるものにしてください。
-
秘訣を適用する。
kubectl apply -f <secret-file-name> -
移行が必要なシークレットごとにこの手順を繰り返す。
ステップ 4: PVCの再現
PVCが新しい秘密を指すように作り直す。
-
移行するPVCごとに、PVC yamlを取得します。
oc get PVC <pvc-name> -o yaml -
yamlをファイルにコピーして、新しいPVCを作成する。
ibm.io/secret-name、ibm.io/secret-namespaceの注釈を変更し、先に挙げたシークレットに対応する新しいシークレットを指すようにする。 PVC名の末尾に文字列を追加し、古いPVCとの区別を容易にする。 -
新しいPVCを貼る。
oc apply -f <pvc-file-name> -
PVCの詳細を入手し、 バウンド状態であることを確認する。
oc get PVC <pvc> -
移行が必要なPVCごとに、これらの手順を繰り返します。
ステップ 5. ポッドの更新
新しいPVCを指すようにポッドを更新する。
- 使用されたリソースの種類を決定する。 出力から ownerReferences セクションを見つけ、リソースの種類とリソースの名前をメモする。
oc describe pod <pod-name> - セクションに記載されているリソースに基づく更新戦略に従ってください。 ownerReferences セクションに記載されているリソースに基づいた更新戦略に従ってください。
DaemonSet: ローリング・アップデート DaemonSetDeployment: 配置の更新StatefulSet: アップデート戦略 StatefulSets- リソースが表示されていない:リソースが表示されていない場合、ポッドはスタンドアローン・ポッドであり、新しいPVC名で手動で再作成する必要があります。 手動でポッドを再作成する 」の手順に従ってください。
手動でポッドを再作成する
-
pod yamlを取得する。
oc describe <resource-type> <resource-name> -o yaml -
yamlをファイルにコピーして、新しいポッドを作成する。 yamlのボリューム・ セクションの PersistentVolumeClaim を変更して、先にリストしたPVCに対応する新しいPVCを指すようにします。 古いリソースと区別するために、新しいリソース名の最後に文字列を追加する。
-
新しいyamlファイルを適用する。
oc apply -f <pod-yaml-file> -
ポッドが実行中であることを確認します。
oc get pods -
手動で移行する必要がある各ポッドについて、この手順を繰り返します。