ストレージ認証鍵と証明書をローテーションする

Google Distributed Cloud（GDC）エアギャップ アプライアンスは、ソフトウェア定義ストレージ ベンダーとして ONTAP Select（OTS）を採用しています。OTS には独自の認証システムがあり、各 ID（コアサービスまたはクライアント）には関連付けられた名前と鍵があります。

このドキュメントでは、次の対象に対して実行する必要がある認証鍵と証明書をローテーションする手順について説明します。

• デバイスのコンプライアンスと安全性を確保するための定期的な鍵のローテーション。
• キーの漏洩を防ぐことができます。公開されているキーはできるだけ早くローテーションする必要があります。

始める前に

次のアクセス権があることを確認します。

• ONTAP クラスタへの管理コンソール アクセス
• Management API サーバーの Kubeconfig

IPsec 認証情報（PSK）をローテーションする

ONTAP は、9.10.1 以降で IPsec の証明書ベースの認証をサポートしています。この GDC リリースは 9.14.1 で、事前共有キーを使用します。

アプライアンスの場合、IPsec は次の 2 種類の OTS トラフィックに実装されます。

• ベアメタル ホストと SVM 間の外部トラフィック。
• ワーカーノード間の内部トラフィック。

それぞれについて説明します。

前提条件

• ONTAP クラスタへの管理コンソール アクセス
• 新しい事前共有キー
• Management API サーバーの Kubeconfig
• StrongSwan 構成を更新するためのホストへのアクセス権

影響

IPsec ポリシーのローテーション中に、ホストでストレージ システムへの IP 接続が失われます。アプリケーションの動作によっては、接続が停止したり、失敗したりする可能性があります。可能であれば、ローテーション中にユーザー ワークロードを一時停止できますが、必須ではありません。シークレットがリセットされると、接続はすぐに復元されます。

OTS 外部トラフィックの鍵のローテーション

ローテーションを検証するには、次のコマンドを使用して出力を比較します。

export KUBECONFIG= #path to root-admin kubeconfig

kubectl get StorageEncryptionConnections -n gpc-system

出力:

NAME          INVENTORYMACHINE   STORAGEVIRTUALMACHINE   STORAGECIDR   PRESHAREDKEY                 READY   AGE
bm-1ba9796c   bm-1ba9796c        root-admin              10.4.4.0/24   bm-1ba9796c-pre-shared-key   True    6h16m
bm-96a5f32a   bm-96a5f32a        root-admin              10.4.4.0/24   bm-96a5f32a-pre-shared-key   True    16h
bm-e07f4a4f   bm-e07f4a4f        root-admin              10.4.4.0/24   bm-e07f4a4f-pre-shared-key   True    21h

スクリプトを以前に実行した特定のホストの READY フィールドが true であることを確認します。

検証中にエラーが見つかった場合は、PSK を手動でローテーションします。

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

   export KUBECONFIG= #path to root-admin kubeconfig
   

   mgmt_ip="$(kubectl get storagecluster -A -o jsonpath='{.items[0].spec.network.clusterManagement.ip}')"
   
   username="$(kubectl get secret storage-root-level1 -n gpc-system -o jsonpath='{.data.username}' | base64 -d)"
   
   password="$(kubectl get secret storage-root-level1 -n gpc-system -o jsonpath='{.data.password}' | base64 -d)"
   

2. パスワードを表示してクリップボードにコピーします。

   echo $password
   

3. ONTAP コンソールにログインします。

   ssh $username@$mgmt_ip
   

   パスワードの入力を求められたら、前の手順でコピーしたパスワードを貼り付けます。

4. 認証情報のローテーションには、次のスクリプトを使用します。

   export KUBECONFIG= #path to root-admin kubeconfig
   

   kubectl get StorageEncryptionConnections -n gpc-system
   

   出力:

   NAME          INVENTORYMACHINE   STORAGEVIRTUALMACHINE   STORAGECIDR   PRESHAREDKEY                 READY   AGE
   bm-1ba9796c   bm-1ba9796c        root-admin              10.4.4.0/24   bm-1ba9796c-pre-shared-key   True    6h16m
   bm-96a5f32a   bm-96a5f32a        root-admin              10.4.4.0/24   bm-96a5f32a-pre-shared-key   True    16h
   bm-e07f4a4f   bm-e07f4a4f        root-admin              10.4.4.0/24   bm-e07f4a4f-pre-shared-key   True    21h
   

   ローテーションするホストごとに、次のコマンドを実行できます。

   export bm_host= //name of bm-host from above
   export secret="${bm_host}-pre-shared-key"
   export job_name="os-policy-config-host-ipsec-${bm_host}"
   export ns="gpc-system"
   export svm="$(kubectl get storageencryptionconnections "${bm_host}" -n "${ns}" -o jsonpath='{.spec.storageVirtualMachineRef.name}')"
   

   ストレージ暗号化接続のすべてのコンポーネントが表示されていることを確認します。管理クラスタ接続（root-admin または organization-admin）の場合は、root-admin クラスタを使用する必要があります。

   kubectl get secrets -n "${ns}" "${secret}"
   kubectl get jobs -n "${ns}" "${job_name}"
   

   両方の項目が表示されている場合は、次の手順に進みます。そうでない場合は、停止して ipsec の変更を続行しないでください。テクニカル サポートにお問い合わせください。

   kubectl delete secrets -n "${ns}" "${secret}"
   kubectl delete jobs "${job_name}" -n "${ns}"
   

   Management API サーバーを使用して storageencryptionconnection を削除します。

   export KUBECONFIG= #path to root-admin kubeconfig
   

   kubectl delete storageencryptionconnections "${bm_host}"
   
   annotation_key="reconcile_annotation_key"
   annotation_value="reconcile_annotation_value"
   
   kubectl patch storagevirtualmachines "${svm}" -n "${ns}" --type=merge -p "{\"metadata\":{\"annotations\":{\"$annotation_key\":\"$annotation_value\"}}}"
   kubectl patch storagevirtualmachines "${svm}" -n "${ns}" --type=json -p="[{\"op\": \"remove\", \"path\": \"/metadata/annotations/$annotation_key\"}]"
   

   OTS 内部トラフィックの鍵のローテーション

同様に、ローテーションを検証するには、次のコマンドを使用して出力を比較します。

export KUBECONFIG= #path to root-admin kubeconfig

kubectl get secret ots-internal-pre-shared-key -n gpc-system

出力:

NAME                          TYPE     DATA   AGE
ots-internal-pre-shared-key   Opaque   1      18m

kubectl get jobs -n gpc-system | grep os-policy-config-host-ipsec

出力:

os-policy-config-host-ipsec-bm-3d33bb857t5bh                Complete   1/1           17s        10m
os-policy-config-host-ipsec-bm-774fa8e6frgr7                Complete   1/1           30s        11m
os-policy-config-host-ipsec-bm-8e452fb29q5wd                Complete   1/1           23s        11m

すべてのジョブが Complete ステータスであることを確認します。

kubectl get StorageEncryptionConnections -n gpc-system

出力:

NAME          INVENTORYMACHINE   STORAGEVIRTUALMACHINE   STORAGECIDR   PRESHAREDKEY                 READY   AGE
bm-3d33bb85   bm-3d33bb85        root-admin              10.4.4.0/24   bm-3d33bb85-pre-shared-key   True    6h16m
bm-774fa8e6   bm-774fa8e6        root-admin              10.4.4.0/24   bm-774fa8e6-pre-shared-key   True    16h
bm-8e452fb2   bm-8e452fb2        root-admin              10.4.4.0/24   bm-8e452fb2-pre-shared-key   True    21h

すべてのホストで READY フィールドが true であることを確認します。

1. ステップ 2 のすべての CR をリストされた順序で削除します。

   • 内部トラフィックの Secret sh kubectl delete secret ots-internal-pre-shared-key -n gpc-system を削除する

   • 3 つの OS ポリシージョブをすべて削除します。 sh kubectl delete jobs os-policy-config-host-ipsec-bm-3d33bb857t5bh -n gpc-system kubectl delete jobs os-policy-config-host-ipsec-bm-774fa8e6frgr7 -n gpc-system kubectl delete jobs os-policy-config-host-ipsec-bm-8e452fb29q5wd -n gpc-system

   • 3 つの storageencryptionconnection sh kubectl delete StorageEncryptionConnections bm-3d33bb85-root-admin -n gpc-system kubectl delete StorageEncryptionConnections bm-774fa8e6-root-admin -n gpc-system kubectl delete StorageEncryptionConnections bm-8e452fb2-root-admin -n gpc-system をすべて削除します。

2. 数分間（3 ～ 5 分程度）待ちます。すべての CR が READY または Complete ステータスになるまで、ステップ 2 を繰り返します。

音量ボタンをローテーションする

このセクションでは、OTS ボリューム認証情報をローテーションする手動の手順について説明します。

始める前に

次の手順を行います。

1. ノートパソコンの前提条件を満たしていることを確認します。
2. BM01 または BM02 を介して OTS クラスタのコンソールにログインできることを確認します。

ボリューム鍵のローテーションを開始する

OTS コンソールで、1 回限りの鍵のローテーションをトリガーします。

volume encryption rekey start -vserver SVM_name -volume volume_name

次のコマンドは、SVMvs1 の vol1 の暗号鍵を変更します。

cluster1::> volume encryption rekey start -vserver vs1 -volume vol1

vserver とボリュームの名前を確認するには、show コマンドを使用します。

vserver show
volume show

音量キーのローテーションを確認する

鍵のローテーションが開始されたら、再キー設定のステータスを確認します。

volume encryption rekey show

再キー設定オペレーションのステータスを表示します。

cluster1::> volume encryption rekey show

Vserver   Volume   Start Time           Status
-------   ------   ------------------   ---------------------------
vs1       vol1     9/18/2017 17:51:41   Phase 2 of 2 is in progress.

再キー設定オペレーションが完了したら、ボリュームで暗号化が有効になっていることを確認します。

volume show -is-encrypted true

暗号化されたボリュームを cluster1 に表示します。

cluster1::> volume show -is-encrypted true

Vserver  Volume  Aggregate  State  Type  Size  Available  Used
-------  ------  ---------  -----  ----  -----  --------- ----
vs1      vol1    aggr2     online    RW  200GB    160.0GB  20%

外部 HSM 証明書をローテーションする

このセクションでは、ONTAP の外部 HSM 証明書をローテーションして更新する方法について説明します。

前提条件

• ONTAP クラスタまたは関連する SVM への管理者アクセス権
• 現在のパスワード
• 適切なクラスタへの kubectl アクセス

手順

1. 古い HSM 証明書をバックアップします。

   kubectl get secret aa-aa-external-hsm-creds -n gpc-system -o yaml > external-hsm-creds-old.yaml
   

2. Kubernetes で HSM 証明書の Secret を更新します。

   1. 古いシークレット yaml ファイルをコピーします。 sh cp external-hsm-creds-old.yaml external-hsm-creds-new.yaml

   2. 新しい external-hsm-creds-new.yaml ファイルを、サーバー CA 証明書、公開クライアント証明書、クライアントの秘密鍵などの新しい HSM 認証情報で更新します。

   3. 変更を適用して、HSM シークレット オブジェクトを更新します。

      kubectl apply -f external-hsm-creds-new.yaml
      

3. ONTAP で HSM 証明書を更新します。

   1. ONTAP CLI にログインします。

   2. 新しいサーバー CA 証明書をインストールします。

      cluster::> security certificate install -type server-ca -vserver <>
      

   3. 新しいクライアント証明書をインストールします。

      cluster::> security certificate install -type client -vserver <>
      

   4. 新しくインストールした証明書を使用するように、キー マネージャーの構成を更新します。

      cluster::> security key-manager external modify -vserver <> -client-cert <> -server-ca-certs <>
      

検証

1. キーマネージャーのステータスで変更を確認します。

   cluster::> security key-manager external show-status
   

   キーサーバーが引き続き Available ステータスかどうかを確認します。

ストレージ管理者の認証情報をローテーションする

このセクションでは、ストレージ管理者のユーザーとパスワードをローテーションして設定する方法について説明します。

前提条件

• ONTAP クラスタまたは関連する SVM への管理者アクセス権
• 現在のパスワード
• 適切なクラスタへの kubectl アクセス

手順

1. 次のコマンドで開始し、表示されるプロンプトに従います。

   cluster::> security login password
   

2. シークレットを次のように更新します。

   • オプション 1（インタラクティブ）:

     kubectl edit secret -n <netapp_namespace> netapp_credential
     

     エディタを使用して、パスワードを新しい base64 エンコード値に変更します。

   • オプション 2（jq 依存関係を含むパッチ）:

     k get secret -n <netapp_namespace> netapp_credential -o json | jq '.data["password"]="<new-base64-encoded-password>"' | kubectl apply -f -
     

ONTAP 緊急アクセス認証情報をローテーションする

ファイル ストレージとブロック ストレージの設定時に、ONTAP に直接アクセスするために使用できる緊急アクセス ユーザー アカウントが 4 つ作成されます。これらの認証情報は、Management API サーバーのシークレットとして取得できます。これらの認証情報が使用されたら、ローテーションする必要があります。

設定時に、レベル 1 とレベル 2 の 2 種類のシークレットが作成されます。レベル 1 は storage-root-level1 and storage-root-level1-backup です。レベル 2 は storage-root-level2 and storage-root-level2-backup です。レベル 2 のシークレットはセーフに保存する必要があります。各レベルには、通常とバックアップの 2 つのシークレットがあります。ソフトウェアは通常のシークレットとバックアップ シークレットの両方の削除を同時に処理しますが、セキュリティを強化するために、一度にローテーションするパートナー シークレットは 1 つだけにすることをおすすめします。

レベル 1 のシークレットは 90 日後に自動的にローテーションされますが、レベル 2 のシークレットはローテーションされません。いずれのタイプのシークレットも、使用する場合は次の手順で手動でローテーションする必要があります。

前提条件

• 必要なアクセス権: Management API サーバー

検証

1. シークレットのローテーションは、シークレットが削除対象としてマークされたままかどうかを確認することで検証できます。そうでない場合、シークレットはローテーションされています。次の手順のステップ 1 に沿って確認します。

2. シークレットがレベル 2 のシークレットの場合は、物理メディアにコピーして金庫に保管します。次に、アノテーション "disk.gdc.goog/persisted" を使用して、シークレットを永続化済みとしてマークする必要があります。

    kubectl annotate secrets
    <secret_name> -n gpc-system disk.gdc.goog/persisted=''
   

検証中にエラーが見つかった場合は、次の手順に沿ってシークレットを手動でローテーションします。

手順

1. Secret が削除対象としてマークされているかどうかを確認します。

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

      kubectl get secret <secret_name> -n gpc-system -o yaml
      

   2. この例のように、deletionTimestamp フィールドがレスポンスに存在する場合、シークレットは削除対象としてマークされます。それ以外の場合は、そうではありません。

      apiVersion: v1
      data:
        password: KFZbQTJdYjIwSUtVVV1aNytJJVM=
        username: cm9vdC1sdmwy
      immutable: true
      kind: Secret
      metadata:
        annotations:
          cluster-name: aa-aa-stge01
        creationTimestamp: "2022-12-21T05:03:02Z"
        deletionGracePeriodSeconds: 0
        deletionTimestamp: "2022-12-21T14:42:13Z"
        finalizers:
        - ontap.storage.private.gdc.goog/breakglass-finalizer
        labels:
          breakglass-secret: "true"
        name: storage-root-level2
        namespace: gpc-system
        resourceVersion: "591897"
        uid: 6f331f8a-bf48-4d59-9725-6c99c5e766f7
      type: Opaque
      
      

2. ONTAP へのアクセスに使用した後にシークレットをローテーションします。

   1. パートナー認証情報が存在し、削除対象としてマークされていないかどうかを確認します。削除対象としてマークされている場合は、続行せずに、後でこの手順に戻ります。

   2. レベル 2 のシークレットがローテーションされている場合、disk.gdc.goog/persisted アノテーションを追加して、パートナー シークレットが永続化されていることをマークする必要があります。

      kubectl annotate secrets
      <secret_name> -n gpc-system disk.gdc.goog/persisted=''
      

   3. 次のコマンドを使用して、クラスタからシークレットを削除します。

      kubectl delete
      secret <secret_name> -n gpc-system
      

   4. この時点で、削除プロセスが開始されます（シークレットが削除対象としてマークされているかどうかを確認することで、削除プロセスが開始されたことを確認できます）。シークレットの削除と再生成には 1 時間近くかかることがあります。

ストレージ管理者と SVM 証明書をローテーションする

これらの証明書は、GDC によって ONTAP システムにインストールされたサーバー証明書です。

ストレージ管理者（クラスタ管理者）アカウント用の証明書が 1 つあります。名前の先頭には ONTAP システムのホスト名が付き、末尾には一意のハッシュが付きます。クラスタ管理 vserver にインストールされます。GDC は、管理タスクにこの証明書を内部的に使用します。

ONTAP SVM 用に定義されたサーバーサイド証明書もいくつかあります。これらは、SVM と通信するクライアントの信頼性を確立します。

すべての証明書は同じプロセスでローテーションできます。ルート管理クラスタのルート CA 証明書の不一致により、次の表に示されているクラスタ証明書と SVM 証明書のローテーションでは、それぞれのリスト内のすべての証明書をローテーションする必要があります。つまり、クラスタ証明書をローテーションする必要がある場合は、他のすべてのクラスタ証明書もローテーションする必要があります。SVM 証明書についても同様です。この制限は、自動証明書管理が実装されると解消されます。

前提条件

• ONTAP クラスタまたは関連する SVM への管理者アクセス権
• 適切な Kubernetes クラスタに対する kubectl アクセス権
• クライアント CA 証明書のインストール手順に沿って、クライアント CA 証明書を再インストールします。

証明書と Kubernetes Secret のマッピング

ONTAP にインストールされている証明書ごとに、証明書の詳細を含む対応する Kubernetes Secret が Management API サーバーにあります。GDC は証明書を生成します。証明書を置き換えるプロセスは簡単です。特定の証明書に対応する Secret を削除すると、証明書がすぐに再生成されます。新しい証明書は、古い証明書と置き換える形で ONTAP に手動でインストールできます。

kubectl get secrets -n <namespace> -s <secret> -o yaml を使用して Kubernetes の証明書を検査し、security certificate show -vserver <svm_name> から確認できる ONTAP の詳細と一致することを確認します。Namespace は常に「gpc-system」になります。Secret 名については、次の表をご覧ください。

証明書とシークレットのマッピングは、次の方法で確認することもできます。

kubectl get certificates -n <namespace>

関連するクラスタ証明書

ONTAP 共通名	Vserver	K8S 証明書名	Kubernetes Secret 名	説明
なし	<hostname>	<hostname>-admin-cert	<hostname>-admin-cert-secret	クラスタ管理者証明書
なし	<hostname>	<hostname>-server-cert	<hostname>-server-cert-secret	ONTAP サーバー証明書として使用される GDC 発行者によって署名されたサーバー証明書
なし	<hostname>	<hostname>-read-only-cert	<hostname>-read-only-cert-secret	読み取り専用のモニタリング アクセス

関連する SVM 証明書

Vserver	K8S 証明書名	Kubernetes Secret 名	説明
root-admin	root-admin-server-cert	root-admin-server-cert-secret	SVM サーバー証明書として使用される GDC 発行元によって署名されたサーバー証明書
root-admin	root-admin-s3-server-cert	root-admin-s3-server-cert-secret	ONTAP S3 サーバー証明書として使用される GDC 発行者によって署名されたサーバー証明書
root-admin	root-admin-client-cert	root-admin-client-cert-secret	SVM 管理者アクセス
root-admin	root-admin-s3-identity-client-cert	root-admin-s3-identity-client-cert-secret	S3 ID アクセス

検証

Vserver 証明書

すべての証明書がローテーションされたら、ローテーションされたサーバー証明書に関連付けられているすべてのクラスタで、Trident バックエンドが正常に接続されていることを確認します。

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

   export KUBECONFIG= #path to root-admin kubeconfig
   

   kubectl get tridentbackendconfigs -n netapp-trident
   

   出力は次のようになります。

   NAME                                   BACKEND NAME   BACKEND UUID                           PHASE   STATUS
   netapp-trident-backend-tbc-ontap-san   iscsi-san      a46ce1c7-26da-42c9-b475-e5e37a0911f8   Bound   Success
   

2. PHASE が Bound で、Status が Success であることを確認します。

ルート管理者証明書

管理者証明書をテストするには、新しいテスト StorageVirtualMachine を作成し、GDC が適切に調整できることを確認します。手順は次のとおりです。

1. 既存の StorageVirtualMachine を一覧表示し、テストとして複製するものを選択します。
2. その Kubernetes 仕様を抽出します。
3. 定義を編集して名前を変更し、不要なフィールドを削除します。
4. テスト定義を適用します。
5. StorageVirtualMachine のステータスが Ready になるまで待ちます。
6. テスト StorageVirtualMachine を削除します。
7. ONTAP から実際の SVM を削除します。

例

この例では、GDC NetApp Namespace gpc-system を使用し、organization-root-user を新しい SVM（test-svm）に一時的に複製します。

1. SVM を一覧表示します。

   kubectl get storagevirtualmachines -n ngpc-system
   

   出力:

   NAME                      AGE
   organization-root-admin   13d
   

2. 仕様を抽出します。

   kubectl get storagevirtualmachines -n gpc-system -o yaml > svm.yaml
   

3. 次のように spec を編集します。

   apiVersion: system.gpc.gke.io/v1alpha1
   kind: StorageVirtualMachine
   metadata:
     labels:
       ontap.storage.gpc.gke.io/role: user
     name: test-svm
     namespace: netapp-alatl12-gpcstge02
   spec:
     aggregates:
     - alatl12-gpcstge02-c1-aggr1
     - alatl12-gpcstge02-c2-aggr1
     clusterName: alatl12-gpcstge02
     iscsiTarget:
       port: a0a-4
       subnetName: root-svm-data
     nasServer:
       port: a0a-4
       subnetName: root-svm-data
     svmNetwork:
       port: e0M
       subnetName: Default
   

4. クラスタに適用します。

   kubectl create -f svm.yaml
   

5. 新しい SVM の準備ができるまで待ちます。次の出力を定期的に確認します。

   kubectl get storagevirtualmachines -n gpc-system test-svm
   

   成功は次のように示されます。

     Conditions:
       Last Transition Time:  2022-03-30T21:30:27Z
       Message:
       Observed Generation:   1
       Reason:                SVMCreated
       Status:                True
       Type:                  Ready
   

   または AnsibleJobSucceed。

6. SVM リソースを削除します。

   kubectl delete storagevirtualmachines -n gpc-system test-svm
   

7. ONTAP から完全に削除します。リソースを削除しても、ONTAP からは削除されません。

   NetApp コンソールにログインして SVM を削除します。

   alatl12-gpcstge02::> vserver delete test-svm
   

   出力:

   Warning: When Vserver "test-svm" is deleted,
           the following objects are automatically removed as well:
           LIFs: 7
           Routes: 2
           Admin-created login accounts: 2
           Do you want to continue? {y|n}: y
   [Job 3633] Success
   

検証中にエラーが見つかった場合は、次の手順に沿って ONTAP 証明書を手動でローテーションします。

手順

上記の ONTAP 証明書名が該当しない場合は、ONTAP でローテーションする必要はありません。Kubernetes で証明書と Secret を検査し、Secret を削除します。

1. 前の表の Secret 名を参照して、新しい証明書を生成します。

   kubectl get certificates -n <namespace>
   

   $ kubectl patch Certificates <cert_name> -n gpc-system \
    --type=merge -p "{\"spec\":{\"privateKey\": {\"rotationPolicy\": \"Always\"}}}"
   $ kubectl delete secret -n <namespace> <secret_name>
   

2. 特定の vserver にインストールされている証明書（ONTAP にインストールされ、該当なしとマークされていない証明書）を表示します。

   cluster::> security certificate show -vserver <svm_name> -type server
   

3. Kubernetes で一致する Secret を検査します（前の表を参照）。

   kubectl get certificates -n <namespace>
   

4. 一致に満足したら、シークレットを削除して新しい証明書を生成します。

   kubectl delete secret -n <namespace> <secret_name>
   

5. シークレットを再検査して、新しい証明書が再生成されたことを確認します。確認が完了したら、ONTAP で新しいサーバー証明書を作成します。次の手順は、接尾辞が「server-cert」の前の証明書に対してのみ実行します。

6. kubectl などのツールを使用して新しい TLS 証明書の本文を直接抽出し、ONTAP にインストールします。

   $ gdch_cert_details -n <namespace> -s <secret_name>
   
   cluster::> security certificate install -vserver <svm_name> -type server
   

   最初のプロンプトは次のようになります。

   Please enter Certificate: Press <Enter> when done

   tls.crt と入力します。tls.crt に複数の証明書ブロックがある場合は、最初のブロックを入力し、残りの証明書ブロックを中間証明書として保持して、次の手順で参照します。

7. システムから Please enter Private Key: Press <Enter> when done というプロンプトが表示されます。tls.key ファイルの内容を貼り付けて、Enter キーを押します。

   次に、Do you want to continue entering root and/or intermediate certificates {y|n}: というプロンプトが表示されます。tls.crt ファイルに証明書が 1 つだけ含まれている場合は、N と入力して Enter キーを押します。それ以外の場合は、「Y」と入力して Enter キーを押します。

   Y と入力した場合: 中間証明書の入力を求めるプロンプトが表示されます。tls.crt ファイルから 1 つずつ貼り付け、そのたびに Enter キーを押します。最後に、ca.crt ファイルからルート証明書を貼り付けて、Enter キーを押します。

   N と入力した場合:（このプロンプトで証明書に関する対応は不要です）

   ONTAP はシリアル番号を返します。この番号は新しい証明書と CA のシリアル番号を表すため、記録しておきます。このシリアル番号は、以降のステップで <new\_server\_serial> および <new\_ca> として参照されます。S3 サーバー証明書を構成する場合は、これらの証明書の手順に従わないでください。

8. vserver とクラスタの SSL 構成の現在の状態を表示します。サーバー証明書の発行 CA、サーバー証明書の共通名、サーバー証明書のシリアル番号をメモしておきます。これらはそれぞれ <old\_server\_common\_name>、<old\_ca>、<old\_server\_serial> として参照されます。

   cluster::> security ssl show -vserver <vserver>
   

   これにより、古いサーバー証明書情報を含む SSL 情報が返されます。SSL 構成を変更した後、この情報を参照して、更新されていることを確認できます。

9. SSL 構成を変更します。

   cluster::> security ssl modify -server-enabled -client-enabled true -vserver <svm_name> -serial <new_server_serial> -ca <new_ca>
   

10. vserver とクラスタの SSL 構成の新しい状態を表示します。これで、インストールされたサーバー証明書のシリアル番号が更新されているはずです。

    cluster::> security ssl show -vserver <vserver>
    

11. 前の手順を確認したら、古いサーバー証明書を削除します。

    cluster::> security certificate delete -vserver <svm_name> -common-name <old_server_common_name> -ca <old_ca> -type server -serial <old_server_serial>
    

クライアント CA 証明書

1. 次のコマンドを使用して、gpc-system Namespace の trust-store-internal-only ConfigMap からすべての CA 証明書を取得します。

   kubectl get cm -n gpc-system trust-store-internal-only -o jsonpath='{.data.ca\.crt}'
   

2. 前の手順で取得した CA 証明書ごとに、ONTAP クラスタで次のコマンドを実行します。

   cluster::> security certificate install -vserver <svm_name> -type client-ca
   

   次のプロンプトが表示されます。 Please enter Certificate: Press <Enter> when done. 手順 1 で取得した各証明書ブロックを貼り付けて、Enter キーを押します。CA 証明書ごとにこのインストール コマンドを繰り返します。

Harvest 証明書をローテーションする

ハーベスト証明書の生成は <hostname>-read-only-cert-secret に依存します。続行する前に、<hostname>-read-only-cert-secret がローテーションされていることを確認します。

1. Harvest Pod にインストールされている証明書を表示します。

   export KUBECONFIG= #path to root-admin kubeconfig
   

   cluster_name="$(kubectl get storagecluster -A -o jsonpath='{.items[0].metadata.name}')"
   secret_name="$cluster_name"-read-only-cert-secret
   

   export TLS_CRT="$(kubectl get secret -n gpc-system $secret_name -o jsonpath='{.data.tls\.crt}')"
   

   export TLS_KEY="$(kubectl get secret -n gpc-system $secret_name -o jsonpath='{.data.tls\.key}')"
   

   export CA_CRT="$(kubectl get secret -n gpc-system $secret_name -o jsonpath='{.data.ca\.crt}')"
   

2. Harvest 認証情報 Secret にパッチを適用して、更新された証明書を提供します。

   $ kubectl patch secret \
   -n gpc-system netapp-harvest-configuration-credential \
   -p "{\"data\":{\"tls.crt\":\"${TLS_CRT:?}\",\"tls.key\":\"${TLS_KEY:?}\",\"ca.crt\":\"${CA_CRT:?}\"}}"
   

3. Harvest サービスを再起動して、更新された構成を読み込みます。

   kubectl delete pod -n gpc-system -l 'app=harvest.netapp.io'
   

ファイル システム証明書をローテーションする

次のコマンドを実行して、file-storage-webhooks-serving-cert と file-observability-backend-target-cert の証明書を再生成します。

kubectl delete secret file-storage-webhooks-serving-cert -n file-system
kubectl delete secret file-observability-backend-target-cert -n file-system

Pod を再起動して、更新された構成を読み込みます。

kubectl delete pod -n file-system -l 'app=file-observability-backend-controller'
kubectl delete pod file-storage-backend-controller -n file-system

Trident と ONTAP の証明書をローテーションする

Trident は ONTAP と通信する必要があります。これは、先ほど定義したクライアント証明書 <svm\_name>-client-cert-secret> を使用する Trident バックエンドで構成されます。クライアント証明書のローテーションは Trident の一部ではありませんが、Trident はこの証明書の一部に依存しているため、更新する必要があります。

手順

CA 証明書の更新の場合:

1. KUBECONFIG をエクスポートして、問題の Trident コンポーネントに固有のクラスタの kubeconfig を指定します。各クラスタには Trident が構成されます。

2. client-cert シークレットから base64 でエンコードされた CA 証明書を取得し、変数として保存します。

   ca_cert=$(kubectl get secrets -n "${ns}" "${secret}" -o jsonpath='{.data.ca\.crt}')
   

3. tridentBackendConfig オブジェクトにパッチを適用します。

   kubectl patch tridentBackendConfigs netapp-trident-backend-tbc-ontap-san -n netapp-trident --type=merge -p "{\"spec\":{\"trustedCACertificate\":\"$ca_cert\"}}"
   

実際のクライアント証明書と鍵の場合:

1. client-cert シークレットから base64 エンコードされた TLS 証明書を取得し、変数として保存します。

   tls_cert=$(kubectl get secrets -n "${ns}" "${secret}" -o jsonpath='{.data.tls\.crt}')
   

2. client-cert シークレットから base64 で二重エンコードされた TLS 鍵を取得し、変数として保存します。

   tls_key=$(kubectl get secrets -n "${ns}" "${secret}" -o jsonpath='{.data.tls\.key}' | base64 -w 0)
   

3. 秘密鍵を使用してバックエンド シークレットを更新します。

   kubectl patch secrets netapp-trident-backend-tbc-ontap -n netapp-trident --type=merge -p "{\"data\":{\"clientPrivateKey\": \"$tls_key\"}}"
   

4. TLS 証明書を使用してバックエンド構成をパッチ適用します。

   kubectl patch tridentBackendConfigs netapp-trident-backend-tbc-ontap-san -n netapp-trident --type=merge -p "{\"spec\":{\"clientCertificate\":\"$tls_cert\"}}"
   

Trident コントローラ証明書をローテーションする

Trident コンテナは Trident Operator と通信する必要があります。この通信は HTTPS 経由で行われ、サーバー証明書とクライアント証明書をこの一部として管理する必要があります。

検証

daemonset と Deployment（該当する場合）の両方が正常な状態で起動していることを確認します。

検証中にエラーが見つかった場合は、次の手順に沿ってサーバー証明書とクライアント証明書を手動でローテーションします。

手順

サーバー証明書とクライアント証明書の両方に、ONTAP 側に対応する証明書がありません。これらはクラスタに厳密に含まれています。

1. 有効期限が切れる証明書に対応するシークレットを削除します。

   kubectl delete secret -n netapp-trident <secret_name>
   

2. netapp-trident-csi daemonset を再起動します。

   kubectl rollout restart daemonset netapp-trident-csi -n netapp-trident
   

3. サーバー証明書のローテーションでは、netapp-trident-csi デプロイも再起動する必要があります。

   kubectl rollout restart deployments netapp-trident-csi -n netapp-trident
   

Trident CA 証明書

CA 証明書は、Trident サーバーとクライアントの証明書に署名するための認証局を提供するために使用されます。

証明書名	Namespace	シークレット	説明
netapp-trident-csi-cert	netapp-trident	netapp-trident-csi-cert	Trident CA 証明書

検証

シークレットが再生成されたことを確認できます。クライアント証明書とサーバー証明書を有効にするには、この証明書のローテーション後に、前述の手順に沿って Trident コントローラの証明書をローテーションすることもできます。

検証中にエラーが見つかった場合は、次の手順に沿って CA 証明書を手動でローテーションします。

手順

この鍵をローテーションするには、Kubernetes から Secret を削除するだけで済みます。

kubectl delete secret -n netapp-trident <secret_name>

Trident CSI ノードと SVM（データ）

これは、ブロック アクセスのデータプレーンへのアクセスを有効にするための、SVM 全体の iSCSI CHAP 認証情報セットです。これはファイル プロトコルには適用されません。

Management API サーバー

Namespace	シークレット	説明
gpc-system	<organization>-<type>-svm-credential	Trident の設定に必要な SVM 構成

組織管理者と Management API サーバー

Namespace	シークレット	説明
gpc-system	<organization>-<type>-svm-credential	Trident の設定に必要な SVM 構成
netapp-trident	netapp-trident-backend-tbc-ontap	Trident バックエンドの管理に必要なシークレット

検証

1. バックエンドが正常に構成されていることを確認します。

   #export kubeconfig of org cluster
   export KUBECONFIG= #path to root-admin kubeconfig
   
   kubectl get tridentBackendConfigs -n netapp-trident
   

2. バックエンドのステータスが Success であることを確認します。

検証中にエラーが見つかった場合は、次の手順でシークレットを手動でローテーションします。

手順

イニシエータ シークレットとターゲット イニシエータ シークレットの両方について、特殊文字を含まない長さ 16 の新しいランダム文字列を生成します。

#export kubeconfig of Management API server
export KUBECONFIG= #path to root-admin kubeconfig

initiator_secret=$(head /dev/random | tr -dc A-Za-z0-9 | head -c16 | base64)

target_secret=$(head /dev/random | tr -dc A-Za-z0-9 | head -c16 | base64)

kubectl patch secrets -n gpc-system "$org-$type-svm-credential" --type=merge -p "{\"data\":{\"initiatorSecret\": \"$initiator_secret\", \"targetSecret\": \"$target_secret\"}}"

#export kubeconfig of org cluster
export KUBECONFIG= #path to root-admin kubeconfig

kubectl patch secrets -n netapp-trident netapp-trident-backend-tbc-ontap --type=merge -p "{\"data\":{\"chapInitiatorSecret\": \"$initiator_secret\", \"chapTargetInitiatorSecret\": \"$target_secret\"}}"

Trident AES 鍵

AES 鍵は、Trident の内部使用のために iSCSI CHAP 認証情報を暗号化するために Trident によって内部的に使用されます。これは 32 バイトの長さでなければならないランダムな文字シーケンスです。

Trident を実行しているクラスタ（root/org-admin/user/system クラスタ）

Namespace	シークレット	説明
netapp-trident	netapp-trident-aes-key	Trident が iSCSI CHAP 認証情報を暗号化するために必要な AES 鍵

検証

1. バックエンドが正常に構成されていることを確認します。

   #export kubeconfig of org cluster
   export KUBECONFIG= #path to root-admin kubeconfig
   
   kubectl get tridentBackendConfigs -n netapp-trident
   

2. バックエンドのステータスが Success であることを確認します。

3. テスト ボリュームを作成しようとする:

   1. pvc 情報を含む YAML ファイルを作成します。

      echo "
      kind: PersistentVolumeClaim
      apiVersion: v1
      metadata:
        name: block-pvc
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 5Gi
        storageClassName: standard-rwo" > pvc.yaml
      

   2. Kubernetes クラスタに適用します。

      kubectl apply -f pvc.yaml
      

4. iSCSI 暗号化による CSI ログのエラーがないことを確認します。

   kubectl logs deploy/netapp-trident-csi -n netapp-trident -c trident-main | grep "Error encrypting"
   

   エラーがなかった場合、ログは返されません。

5. ファイルと PVC をクリーンアップします。

   kubectl delete -f pvc.yaml
   rm -f pvc.yaml
   

検証中にエラーが見つかった場合は、次の手順に沿って鍵を手動でローテーションします。

手順

このキーをローテーションする前に、クラスタに PV を含む保留中の Pod がないことを確認してください。ある場合は、完全にプロビジョニングされるまで待ってから鍵をローテーションします。

aesKey の特殊文字を含まない 32 文字の新しいランダム文字列を生成します。

#export kubeconfig of org cluster
export KUBECONFIG= #path to root-admin kubeconfig

aes_key=$(head /dev/random | tr -dc A-Za-z0-9 | head -c32 | base64)

#save old key just in case of errors
old_key=$(kubectl get secrets -n netapp-trident "netapp-trident-aes-key" -o jsonpath='{.data.aesKey}')

kubectl patch secrets -n netapp-trident "netapp-trident-aes-key" --type=merge -p "{\"data\":{\"aesKey\": \"$aes_key\"}}"

kubectl rollout restart deployment netapp-trident-csi -n netapp-trident

ロールバック

1. エラーが発生した場合は、最後に使用した認証情報にロールバックします。

   kubectl patch secrets -n netapp-trident "netapp-trident-aes-key" --type=merge -p "{\"data\":{\"aesKey\": \"$old_key\"}}"
   
   kubectl rollout restart deployment netapp-trident-csi -n netapp-trident
   

2. 確認手順をやり直します。