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。
執行下列指令:
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)"
查看密碼並複製到剪貼簿:
echo $password
登入 ONTAP 控制台:
ssh $username@$mgmt_ip
系統提示輸入密碼時,請貼上上一個步驟複製的密碼。
請使用下列指令碼輪替憑證:
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。
按照步驟 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
請稍候幾分鐘 (約 3 到 5 分鐘)。重複步驟 2,直到每個 CR 都處於「READY」或「Complete」狀態。
旋轉音量鍵
本節說明手動輪替 OTS 磁碟區憑證的步驟。
事前準備
操作步驟如下:
- 確認符合筆電先決條件。
- 確認您能透過 BM01 或 BM02 登入 OTS 叢集控制台。
啟動磁碟區金鑰輪替
在 OTS 控制台中,觸發一次性金鑰輪替:
volume encryption rekey start -vserver SVM_name -volume volume_name
下列指令會變更 SVMvs1
上 vol1
的加密金鑰:
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 存取適當的叢集
操作說明
備份舊的 HSM 憑證:
kubectl get secret aa-aa-external-hsm-creds -n gpc-system -o yaml > external-hsm-creds-old.yaml
更新 Kubernetes 中的 HSM 憑證密鑰:
複製舊的密鑰 YAML 檔案:
sh cp external-hsm-creds-old.yaml external-hsm-creds-new.yaml
使用新的 HSM 憑證更新新的
external-hsm-creds-new.yaml
檔案,包括伺服器 CA 憑證、公開用戶端憑證和用戶端私密金鑰。套用變更並更新 HSM 密鑰物件。
kubectl apply -f external-hsm-creds-new.yaml
在 ONTAP 中更新 HSM 憑證:
登入 ONTAP CLI。
安裝新的伺服器 CA 憑證:
cluster::> security certificate install -type server-ca -vserver <>
安裝新的用戶端憑證:
cluster::> security certificate install -type client -vserver <>
更新金鑰管理員設定,使用新安裝的憑證:
cluster::> security key-manager external modify -vserver <> -client-cert <> -server-ca-certs <>
驗證
使用金鑰管理員狀態驗證變更:
cluster::> security key-manager external show-status
檢查金鑰伺服器是否仍處於
Available
狀態。
輪替儲存空間管理員憑證
本節說明如何輪替及設定儲存空間管理員使用者和密碼。
必要條件
- ONTAP 叢集或相關 SVM 的管理員存取權
- 目前的密碼
- kubectl 存取適當的叢集
操作說明
首先執行下列指令,然後按照產生的提示操作:
cluster::> security login password
更新密鑰,使其與下列項目相符:
選項 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 伺服器
驗證
- 如要驗證密鑰輪替作業,請檢查密鑰是否仍標示為待刪除。如果不是,表示密鑰已輪替。按照下列操作說明的第一步檢查。
如果密碼為第 2 級密碼,請複製到實體媒體並存放在保險箱中。然後使用註解
"disk.gdc.goog/persisted"
將密碼標示為持續存在。kubectl annotate secrets <secret_name> -n gpc-system disk.gdc.goog/persisted=''
如果在驗證期間發現任何錯誤,請按照下列操作說明手動輪替密鑰。
操作說明
檢查密鑰是否標示為待刪除:
執行下列指令:
kubectl get secret <secret_name> -n gpc-system -o yaml
如果回應中出現
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
使用密鑰存取 ONTAP 後,請輪替密鑰:
- 檢查合作夥伴憑證是否存在,且未標示為刪除項目。 如果標示為刪除,請勿繼續操作,並在日後返回這些步驟。
如果第 2 級密鑰正在輪替,則必須新增
disk.gdc.goog/persisted
註解,將合作夥伴密鑰標示為持續存在:kubectl annotate secrets <secret_name> -n gpc-system disk.gdc.goog/persisted=''
使用下列指令從叢集刪除密鑰:
kubectl delete secret <secret_name> -n gpc-system
此時,系統會開始刪除程序 (您可以檢查密鑰是否標示為待刪除,確認程序是否啟動)。系統可能需要近一小時才能刪除並重新產生密鑰。
輪替儲存空間管理員和 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 後端。
執行下列指令:
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
確認
PHASE
為「已繫結」,且Status
為「成功」。
根管理員憑證
如要測試管理員憑證,我們可以建立新的測試 StorageVirtualMachine,並確認 GDC 能適當調解。步驟如下:
- 列出現有的 StorageVirtualMachine,並選取要複製的項目做為測試。
- 擷取 Kubernetes 規格。
- 編輯定義,即可變更名稱及刪除不必要的欄位。
- 套用測試定義。
- 等待 StorageVirtualMachine 狀態變為
Ready
。 - 刪除測試 StorageVirtualMachine。
- 從 ONTAP 刪除實際的 SVM。
範例
本範例使用 GDC NetApp 命名空間 gpc-system
,並將 organization-root-user
暫時複製到名為 test-svm
的新 SVM。
列出 SVM:
kubectl get storagevirtualmachines -n ngpc-system
輸出:
NAME AGE organization-root-admin 13d
擷取規格:
kubectl get storagevirtualmachines -n gpc-system -o yaml > svm.yaml
編輯規格,使其類似下列內容:
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
將其套用至叢集:
kubectl create -f svm.yaml
等待新的 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
。刪除 SVM 資源:
kubectl delete storagevirtualmachines -n gpc-system test-svm
從 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 中的憑證和密鑰,然後刪除密鑰。
產生新憑證,並參照上表取得密鑰名稱:
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>
查看特定虛擬伺服器已安裝的憑證,以及 ONTAP 中已安裝的憑證 (未標示為不適用):
cluster::> security certificate show -vserver <svm_name> -type server
檢查 Kubernetes 中相符的 Secret (請參閱上表):
kubectl get certificates -n <namespace>
如果對比對結果感到滿意,請刪除密鑰來產生新憑證:
kubectl delete secret -n <namespace> <secret_name>
重新檢查密鑰,確認系統已重新產生新憑證。 確認後,請在 ONTAP 中建立新的伺服器憑證。僅針對前述憑證執行下列步驟,並加上「server-cert」後置字元。
使用
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
中有多個憑證區塊,請輸入第一個區塊,並保留其餘憑證區塊做為中繼憑證,以供下一步參考。系統會提示:
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 伺服器憑證,請不要按照這些憑證步驟操作。查看虛擬伺服器和叢集的 SSL 設定目前狀態。請準備好伺服器憑證核發 CA、伺服器憑證通用名稱和伺服器憑證序號,這些名稱將分別稱為
<old\_server\_common\_name>
、<old\_ca>
和<old\_server\_serial>
:cluster::> security ssl show -vserver <vserver>
這會傳回 SSL 資訊,包括舊的伺服器憑證資訊。修改 SSL 設定後,您可以參考這項資訊,確認設定是否已更新。
修改 SSL 設定:
cluster::> security ssl modify -server-enabled -client-enabled true -vserver <svm_name> -serial <new_server_serial> -ca <new_ca>
查看虛擬伺服器和叢集 SSL 設定的新狀態。這應該會顯示已安裝伺服器憑證的更新序號:
cluster::> security ssl show -vserver <vserver>
確認上一個步驟後,刪除舊的伺服器憑證:
cluster::> security certificate delete -vserver <svm_name> -common-name <old_server_common_name> -ca <old_ca> -type server -serial <old_server_serial>
用戶端 CA 憑證
使用下列指令,從
gpc-system
命名空間的trust-store-internal-only
ConfigMap 擷取所有 CA 憑證:kubectl get cm -n gpc-system trust-store-internal-only -o jsonpath='{.data.ca\.crt}'
針對上一個步驟中擷取的每個 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
已旋轉,再繼續操作。
查看 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}')"
修補 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:?}\"}}"
重新啟動 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 通訊。這是透過 Trident 後端設定,後端會使用先前定義的用戶端憑證 <svm\_name>-client-cert-secret>
。用戶端憑證輪替並非 Trident 的一部分,但 Trident 依賴這項憑證的部分內容,因此需要更新。
操作說明
更新 CA 憑證:
匯出
KUBECONFIG
,指向與相關 Trident 元件對應的叢集 kubeconfig。每個叢集都會設定 Trident。從 client-cert 密鑰擷取 base64 編碼的 CA 憑證,並儲存為變數:
ca_cert=$(kubectl get secrets -n "${ns}" "${secret}" -o jsonpath='{.data.ca\.crt}')
修補 tridentBackendConfig 物件:
kubectl patch tridentBackendConfigs netapp-trident-backend-tbc-ontap-san -n netapp-trident --type=merge -p "{\"spec\":{\"trustedCACertificate\":\"$ca_cert\"}}"
實際的用戶端憑證和金鑰:
從 client-cert 密鑰擷取以 Base64 編碼的 TLS 憑證,並儲存為變數:
tls_cert=$(kubectl get secrets -n "${ns}" "${secret}" -o jsonpath='{.data.tls\.crt}')
從 client-cert 密鑰擷取以 base64 雙重編碼的 TLS 金鑰,並儲存為變數:
tls_key=$(kubectl get secrets -n "${ns}" "${secret}" -o jsonpath='{.data.tls\.key}' | base64 -w 0)
使用私密金鑰更新後端密鑰:
kubectl patch secrets netapp-trident-backend-tbc-ontap -n netapp-trident --type=merge -p "{\"data\":{\"clientPrivateKey\": \"$tls_key\"}}"
使用傳輸層安全標準 (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 端都沒有對應的憑證。 這些資料嚴格來說都包含在叢集中。
刪除即將過期的憑證對應的密鑰。
kubectl delete secret -n netapp-trident <secret_name>
重新啟動 netapp-trident-csi Daemonset:
kubectl rollout restart daemonset netapp-trident-csi -n netapp-trident
如要輪替伺服器憑證,您也需要重新啟動 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 |
驗證
確認後端仍設定成功:
#export kubeconfig of org cluster export KUBECONFIG= #path to root-admin kubeconfig kubectl get tridentBackendConfigs -n netapp-trident
確認後端狀態為
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 金鑰 |
驗證
確認後端仍設定成功:
#export kubeconfig of org cluster export KUBECONFIG= #path to root-admin kubeconfig kubectl get tridentBackendConfigs -n netapp-trident
確認後端狀態為
Success
。嘗試建立測試磁碟區:
建立 YAML 檔案,其中包含 PVC 資訊:
echo " kind: PersistentVolumeClaim apiVersion: v1 metadata: name: block-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 5Gi storageClassName: standard-rwo" > pvc.yaml
將其套用至 Kubernetes 叢集:
kubectl apply -f pvc.yaml
確認 CSI 記錄中沒有因 iSCSI 加密而導致的錯誤:
kubectl logs deploy/netapp-trident-csi -n netapp-trident -c trident-main | grep "Error encrypting"
如果沒有任何錯誤,系統就不會傳回記錄。
清理檔案和 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
復原
如有錯誤,請還原為上次使用的憑證:
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
重新執行驗證步驟。