輪替儲存空間驗證金鑰和憑證

Google Distributed Cloud (GDC) 實體隔離設備採用 ONTAP Select (OTS) 做為軟體定義儲存空間供應商。OTS 有自己的驗證系統,每個身分 (核心服務或用戶端) 都有相關聯的名稱和金鑰。

本文說明輪替驗證金鑰和憑證的步驟,這些步驟必須為下列項目執行:

  • 定期排定金鑰輪替作業,確保裝置符合規定且安全無虞。
  • 重要曝光。請盡快輪替外洩的金鑰。

事前準備

請確認您具備下列存取權:

  • ONTAP 叢集的管理控制台存取權
  • 管理 API 伺服器的 Kubeconfig

輪替 IPsec 憑證 (PSK)

ONTAP 9.10.1 以上版本支援 IPsec 的憑證式驗證。這個版本的 GDC 為 9.14.1,並使用預先共用金鑰。

對於裝置,IPsec 會針對兩種 OTS 流量類型實作:

  • 裸機主機與 SVM 之間的外部流量。
  • 工作站節點之間的內部流量。

我們會分別說明。

必要條件

  • ONTAP 叢集的管理控制台存取權
  • 新的預先共用金鑰
  • 管理 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}')"
    

    現在請確認您看到儲存空間加密連線的所有元件。如要連線至管理員叢集 (根管理員或機構管理員),您必須使用根管理員叢集。

    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

    • 刪除內部流量的密鑰 sh kubectl delete secret ots-internal-pre-shared-key -n gpc-system

    • 刪除所有三項 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

    • 刪除所有三個儲存空間加密連線 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 分鐘)。重複步驟 2,直到每個 CR 都處於「READY」或「Complete」狀態。

旋轉音量鍵

本節說明手動輪替 OTS 磁碟區憑證的步驟。

事前準備

操作步驟如下:

  1. 確認符合筆電先決條件
  2. 確認您能透過 BM01 或 BM02 登入 OTS 叢集控制台。

啟動磁碟區金鑰輪替

在 OTS 控制台中,觸發一次性金鑰輪替:

volume encryption rekey start -vserver SVM_name -volume volume_name

下列指令會變更 SVMvs1vol1 的加密金鑰:

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

如要查看虛擬伺服器和磁碟區的名稱,可以使用 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 憑證密鑰:

    1. 複製舊的密鑰 YAML 檔案: sh cp external-hsm-creds-old.yaml external-hsm-creds-new.yaml

    2. 使用新的 HSM 憑證更新新的 external-hsm-creds-new.yaml 檔案,包括伺服器 CA 憑證、公開用戶端憑證和用戶端私密金鑰。

    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。這些憑證可做為 Management API 伺服器中的密碼。使用這些憑證後,就必須輪替。

設定期間會建立兩種密鑰,分別是第 1 級和第 2 級。第 1 級是 storage-root-level1 and storage-root-level1-backup。第 2 級是 storage-root-level2 and storage-root-level2-backup。第 2 級密碼必須儲存在保險箱中,每個等級都有兩個密碼,分別是正常密碼和備份密碼。雖然軟體會同時刪除一般和備份密鑰,但我們建議一次只輪替其中一個合作夥伴密鑰,以增加一層安全性。

第 1 級密鑰會在 90 天後自動輪替,但第 2 級密鑰不會。如果使用這兩種密鑰,都必須透過下列程序手動輪替。

必要條件

  • 必要存取權:Management API 伺服器

驗證

  1. 如要驗證密鑰輪替作業,請檢查密鑰是否仍標示為待刪除。如果不是,表示密鑰已輪替。按照下列操作說明的第一步檢查。
  2. 如果密碼為第 2 級密碼,請複製到實體媒體並存放在保險箱中。然後使用註解 "disk.gdc.goog/persisted" 將密碼標示為持續存在。

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

如果在驗證期間發現任何錯誤,請按照下列操作說明手動輪替密鑰。

操作說明

  1. 檢查密鑰是否標示為待刪除:

    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. 此時,系統會開始刪除程序 (您可以檢查密鑰是否標示為待刪除,確認程序是否啟動)。系統可能需要近一小時才能刪除並重新產生密鑰。

輪替儲存空間管理員和 SVM 憑證

這些憑證是 GDC 安裝到 ONTAP 系統中的伺服器憑證。

儲存空間管理員 (又稱叢集管理員) 帳戶會使用一個憑證。其名稱開頭為 ONTAP 系統的主機名稱,結尾則為不重複的雜湊值。並安裝在叢集管理員 Vserver 中。GDC 會在內部使用這項憑證執行管理工作。

此外,ONTAP SVM 也定義了多個伺服器端憑證。 這些憑證可驗證與 SVM 通訊的用戶端。

所有憑證都可以透過相同程序輪替。由於根管理員叢集中的根 CA 憑證不符,因此如要輪替下列表格列出的叢集和 SVM 憑證,必須輪替相應清單中的所有憑證。也就是說,如果需要輪替任何叢集憑證,所有其他叢集憑證也必須輪替。SVM 憑證也適用相同規定。實作自動化憑證管理後,這項限制就會解除。

必要條件

  • ONTAP 叢集或相關 SVM 的管理員存取權
  • 適當 Kubernetes 叢集的 kubectl 存取權
  • 按照用戶端 CA 憑證安裝步驟重新安裝用戶端 CA 憑證。

憑證與 Kubernetes Secret 之間的對應

ONTAP 中安裝的每個憑證,在 Management API 伺服器中都有對應的 Kubernetes 密鑰,內含憑證詳細資料。GDC 會產生憑證,而更換憑證的程序很簡單:刪除與特定憑證對應的密鑰,系統就會立即重新產生憑證。然後手動將新憑證安裝到 ONTAP,取代舊憑證。

使用 kubectl get secrets -n <namespace> -s <secret> -o yaml 檢查 Kubernetes 中的憑證,並確認憑證與 security certificate show -vserver <svm_name> 中 ONTAP 顯示的詳細資料相符。命名空間一律為「gpc-system」,如需密鑰名稱,請參閱下表。

您也可以查看下列項目,瞭解憑證與密鑰的對應關係:

kubectl get certificates -n <namespace>

相關叢集憑證

ONTAP Common Name Vserver K8S 憑證名稱 Kubernetes Secret 名稱 說明
不適用 <hostname> <hostname>-admin-cert <hostname>-admin-cert-secret 叢集管理員憑證
不適用 <hostname> <hostname>-server-cert <hostname>-server-cert-secret 由 GDC 簽署的伺服器憑證,做為 ONTAP 伺服器憑證
不適用 <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 由 GDC 核發者簽署的伺服器憑證,做為 SVM 伺服器憑證
root-admin root-admin-s3-server-cert root-admin-s3-server-cert-secret 由 GDC 簽署的伺服器憑證,用做 ONTAP S3 伺服器憑證
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 身分識別存取權

驗證

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 為「已繫結」,且 Status 為「成功」

根管理員憑證

如要測試管理員憑證,我們可以建立新的測試 StorageVirtualMachine,並確認 GDC 能適當調解。步驟如下:

  1. 列出現有的 StorageVirtualMachine,並選取要複製的項目做為測試。
  2. 擷取 Kubernetes 規格。
  3. 編輯定義,即可變更名稱及刪除不必要的欄位。
  4. 套用測試定義。
  5. 等待 StorageVirtualMachine 狀態變為 Ready
  6. 刪除測試 StorageVirtualMachine。
  7. 從 ONTAP 刪除實際的 SVM。

範例

本範例使用 GDC NetApp 命名空間 gpc-system,並將 organization-root-user 暫時複製到名為 test-svm 的新 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. 編輯規格,使其類似下列內容:

    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 中的憑證和密鑰,然後刪除密鑰。

  1. 產生新憑證,並參照上表取得密鑰名稱:

    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. 查看特定虛擬伺服器已安裝的憑證,以及 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 檔案只包含單一憑證,請輸入 N 並按下 Enter 鍵。否則,請輸入 Y 並按下 Enter 鍵。

    如果輸入 Y系統會提示你輸入中繼憑證。從 tls.crt 檔案逐一貼上,每貼上一個就按 Enter 鍵。最後,從 ca.crt 檔案貼上根憑證,然後按 Enter 鍵。

    如果您輸入 N (系統會顯示這個提示,表示您不必採取進一步行動)

    ONTAP 隨後會傳回序號。請記下這個號碼,因為這是新憑證和 CA 的序號。這個序號在後續步驟中會稱為 <new\_server\_serial><new\_ca>。如果您要設定 S3 伺服器憑證,請不要按照這些憑證步驟操作。

  8. 查看虛擬伺服器和叢集的 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. 查看虛擬伺服器和叢集 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 命名空間的 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 憑證密鑰,以提供更新後的憑證:

    $ 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-certfile-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 通訊。這是透過 Trident 後端設定,後端會使用先前定義的用戶端憑證 <svm\_name>-client-cert-secret>。用戶端憑證輪替並非 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 運算子通訊。 這項通訊是透過 HTTPS 進行,因此伺服器和用戶端憑證必須一併管理。

驗證

確認 DaemonSet 和部署 (如適用) 都處於正常運作狀態。

如果在驗證期間發現任何錯誤,請按照下列說明手動輪替伺服器和用戶端憑證。

操作說明

伺服器和用戶端憑證在 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 伺服器和用戶端憑證。

認證名稱 命名空間 Secret 說明
netapp-trident-csi-cert netapp-trident netapp-trident-csi-cert Trident CA 憑證

驗證

您會看到密鑰已重新產生。如要讓用戶端和伺服器憑證生效,您也可以在輪替這個憑證後,按照上述操作說明輪替 Trident 控制器憑證。

如果在驗證期間發現任何錯誤,請按照下列操作說明手動輪替 CA 憑證。

操作說明

如要輪替這個金鑰,您只需要從 Kubernetes 刪除密鑰:

kubectl delete secret -n netapp-trident <secret_name>

Trident CSI 節點和 SVM (資料)

這是 SVM 範圍的 iSCSI CHAP 憑證集,可啟用資料平面存取權,以進行區塊存取。這項限制不適用於檔案通訊協定。

Management API 伺服器

命名空間 Secret 說明
gpc-system <organization>-<type>-svm-credential Trident 設定需要 SVM 設定

機構管理員和 Management API 伺服器

命名空間 Secret 說明
gpc-system <organization>-<type>-svm-credential Trident 設定需要 SVM 設定
netapp-trident netapp-trident-backend-tbc-ontap 管理 Trident 後端所需的 Secret

驗證

  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 金鑰

Trident 會在內部使用 AES 金鑰,加密 iSCSI CHAP 憑證供 Trident 內部使用。這是隨機字元序列,長度必須為 32 個位元組。

執行 Trident 的叢集 (可以是根/機構管理員/使用者/系統叢集)

命名空間 Secret 說明
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. 建立 YAML 檔案,其中包含 PVC 資訊:

      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. 確認 CSI 記錄中沒有因 iSCSI 加密而導致的錯誤:

    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
    

如果在驗證期間發現任何錯誤,請按照下列操作說明手動輪替金鑰。

操作說明

輪替這項金鑰前,請先確認叢集中沒有任何待處理的 Pod (含 PV)。如有,請等待完全佈建後再輪替金鑰。

產生長度為 32 的新隨機字串,且不含特殊字元,做為 aesKey:

#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. 重新執行驗證步驟