Merotasi kunci dan sertifikat autentikasi penyimpanan

Perangkat Google Distributed Cloud (GDC) dengan air gap mengadopsi ONTAP Select (OTS) sebagai vendor penyimpanan software-defined. OTS memiliki sistem autentikasinya sendiri di mana setiap identitas (layanan inti atau klien) memiliki nama dan kunci terkait.

Dokumen ini menjelaskan langkah-langkah untuk mengganti kunci dan sertifikat autentikasi yang harus dilakukan untuk:

• rotasi kunci yang dijadwalkan secara rutin untuk memastikan bahwa perangkat tersebut mematuhi dan aman.
• paparan kunci. Anda harus merotasi kunci yang terekspos sesegera mungkin.

Sebelum memulai

Pastikan Anda memiliki akses berikut:

• Akses konsol Admin ke cluster ONTAP
• Kubeconfig untuk server Management API

Merotasi kredensial IPsec (PSK)

ONTAP mendukung autentikasi berbasis sertifikat untuk IPsec mulai dari 9.10.1. Rilis GDC ini menggunakan 9.14.1 dan menggunakan pre-shared key.

Untuk Appliance, IPsec diimplementasikan untuk dua jenis traffic OTS:

• Traffic eksternal antara host bare metal dan SVM.
• Traffic internal antar-node pekerja.

Kita akan membahasnya secara terpisah.

Prasyarat

• Akses konsol Admin ke cluster ONTAP
• Pre-shared key baru
• Kubeconfig untuk server Management API
• Akses ke host untuk memperbarui konfigurasi StrongSwan

Dampak

Saat kebijakan IPsec dirotasi, host akan mengalami hilangnya konektivitas IP ke sistem penyimpanan. Koneksi akan terhenti atau mungkin gagal bergantung pada perilaku aplikasi. Anda dapat menjeda beban kerja pengguna selama rotasi jika memungkinkan, tetapi hal ini tidak wajib. Koneksi akan pulih segera setelah secret direset.

Rotasi Kunci untuk Traffic Eksternal OTS

Untuk memvalidasi rotasi, gunakan perintah berikut dan bandingkan output Anda:

export KUBECONFIG= #path to root-admin kubeconfig

kubectl get StorageEncryptionConnections -n gpc-system

Output:

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

Pastikan kolom READY bernilai benar untuk host tertentu tempat Anda menjalankan skrip sebelumnya.

Putar PSK secara manual jika Anda menemukan error selama validasi.

1. Jalankan perintah berikut:

   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. Lihat sandi dan salin ke papan klip:

   echo $password
   

3. Login ke konsol ONTAP:

   ssh $username@$mgmt_ip
   

   Saat diminta memasukkan sandi, tempel sandi yang disalin dari langkah sebelumnya.

4. Gunakan skrip berikut untuk rotasi kredensial:

   export KUBECONFIG= #path to root-admin kubeconfig
   

   kubectl get StorageEncryptionConnections -n gpc-system
   

   Output:

   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
   

   Untuk setiap host yang ingin Anda ganti, Anda dapat menjalankan perintah berikut:

   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}')"
   

   Sekarang, pastikan Anda melihat semua komponen koneksi enkripsi penyimpanan. Untuk koneksi cluster admin, baik root-admin maupun organization-admin, Anda harus menggunakan cluster root-admin.

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

   Jika kedua item ini ada, Anda dapat melanjutkan ke langkah berikutnya. Jika tidak, hentikan dan jangan lanjutkan dengan mengubah ipsec. Hubungi dukungan teknis.

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

   Sekarang gunakan server Management API untuk menghapus 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\"}]"
   

   Rotasi Kunci untuk Traffic Internal OTS

Demikian pula, untuk memvalidasi rotasi, gunakan perintah berikut dan bandingkan output Anda:

export KUBECONFIG= #path to root-admin kubeconfig

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

Output:

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

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

Output:

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

Pastikan semua tugas berstatus Complete.

kubectl get StorageEncryptionConnections -n gpc-system

Output:

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

Pastikan kolom READY bernilai benar untuk semua host.

1. Hapus semua CR di langkah 2 dengan urutan yang tercantum

   • Hapus secret untuk traffic internal sh kubectl delete secret ots-internal-pre-shared-key -n gpc-system

   • Hapus ketiga tugas kebijakan 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

   • Hapus semua 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. Tunggu beberapa menit (~3-5 menit). Ulangi langkah 2 hingga setiap CR berstatus SIAP atau Selesai.

Merotasi tombol volume

Bagian ini menjelaskan langkah-langkah manual untuk mengganti kredensial volume OTS.

Sebelum memulai

Selesaikan langkah-langkah berikut:

1. Pastikan Anda memenuhi prasyarat laptop.
2. Pastikan Anda dapat login ke konsol cluster OTS melalui BM01 atau BM02.

Memulai rotasi tombol volume

Di konsol OTS, picu rotasi kunci satu kali:

volume encryption rekey start -vserver SVM_name -volume volume_name

Perintah berikut mengubah kunci enkripsi untuk vol1 di SVMvs1:

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

Untuk melihat nama vserver dan volume, Anda dapat menggunakan perintah show:

vserver show
volume show

Memverifikasi rotasi tombol volume

Setelah rotasi kunci dimulai, periksa status penggantian kunci:

volume encryption rekey show

Menampilkan status operasi penggantian kunci:

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.

Setelah operasi penggantian kunci selesai, pastikan volume diaktifkan untuk enkripsi:

volume show -is-encrypted true

Tampilkan volume terenkripsi di cluster1:

cluster1::> volume show -is-encrypted true

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

Merotasi sertifikat HSM eksternal

Bagian ini menjelaskan cara mengganti dan mengupdate sertifikat HSM eksternal untuk ONTAP.

Prasyarat

• Akses admin ke cluster ONTAP atau SVM yang relevan
• Sandi saat ini
• Akses kubectl ke cluster yang sesuai

Petunjuk

1. Mencadangkan sertifikat HSM lama:

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

2. Perbarui secret sertifikat HSM di Kubernetes:

   1. Salin file yaml secret lama: sh cp external-hsm-creds-old.yaml external-hsm-creds-new.yaml

   2. Perbarui file external-hsm-creds-new.yaml baru dengan kredensial HSM baru, termasuk sertifikat CA server, sertifikat klien publik, dan kunci pribadi untuk klien.

   3. Terapkan perubahan dan perbarui objek rahasia HSM.

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

3. Perbarui sertifikat HSM di ONTAP:

   1. Login ke ONTAP CLI.

   2. Instal sertifikat CA server baru:

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

   3. Instal sertifikat klien baru:

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

   4. Perbarui konfigurasi pengelola kunci untuk menggunakan sertifikat yang baru diinstal:

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

Validasi

1. Verifikasi perubahan dengan status pengelola kunci:

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

   Periksa apakah server kunci masih dalam status Available.

Merotasi kredensial admin penyimpanan

Bagian ini menjelaskan cara mengganti dan menetapkan pengguna serta sandi admin penyimpanan.

Prasyarat

• Akses admin ke cluster ONTAP atau SVM yang relevan
• Sandi saat ini
• Akses kubectl ke cluster yang sesuai

Petunjuk

1. Mulai dengan perintah berikut, lalu ikuti perintah yang dihasilkan:

   cluster::> security login password
   

2. Perbarui secret agar cocok:

   • Opsi 1 (Interaktif):

     kubectl edit secret -n <netapp_namespace> netapp_credential
     

     Gunakan editor untuk mengubah sandi ke nilai baru yang dienkode base64.

   • Opsi 2 (Patch dengan dependensi jq):

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

Merotasi kredensial akses darurat ONTAP

Selama penyiapan penyimpanan file dan blok, empat akun pengguna akses darurat dibuat yang dapat digunakan untuk mengakses ONTAP secara langsung. Kredensial ini dapat diperoleh sebagai secret di server Management API. Setelah kredensial tersebut digunakan, kredensial tersebut harus diubah.

Dua jenis rahasia dibuat selama penyiapan, tingkat 1 dan tingkat 2. Level 1 adalah storage-root-level1 and storage-root-level1-backup. Level 2 adalah storage-root-level2 and storage-root-level2-backup. Secret level 2 perlu disimpan di safe dan setiap level memiliki dua secret, yaitu normal dan cadangan. Meskipun software menangani penghapusan rahasia normal dan cadangan secara bersamaan, kami merekomendasikan untuk mengganti hanya salah satu rahasia partner ini dalam satu waktu sebagai lapisan keamanan tambahan.

Meskipun secret level 1 dirotasi secara otomatis setelah jangka waktu 90 hari, secret level 2 tidak. Kedua jenis rahasia harus diubah secara manual menggunakan proses berikut jika digunakan.

Prasyarat

• Akses yang diperlukan: Server Management API

Validasi

1. Rotasi rahasia dapat divalidasi dengan memeriksa apakah rahasia masih ditandai untuk dihapus. Jika tidak, rahasia telah diubah. Ikuti langkah pertama dalam petunjuk berikut untuk memeriksa.

2. Jika rahasia adalah rahasia tingkat 2, salin rahasia tersebut ke media fisik dan simpan di brankas. Kemudian, rahasia harus ditandai sebagai persisten menggunakan anotasi "disk.gdc.goog/persisted".

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

Gunakan petunjuk berikut untuk memutar rahasia secara manual jika Anda menemukan error selama validasi.

Petunjuk

1. Periksa apakah secret ditandai untuk dihapus:

   1. Jalankan perintah berikut:

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

   2. Jika kolom deletionTimestamp ada dalam respons seperti dalam contoh ini, secret akan ditandai untuk dihapus. Jika tidak, maka tidak.

      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. Ganti sandi setelah menggunakannya untuk mengakses ONTAP:

   1. Periksa apakah kredensial partner ada dan tidak ditandai untuk dihapus. Jangan lanjutkan dan kembali ke langkah-langkah ini pada masa mendatang jika ditandai untuk dihapus.

   2. Jika secret level 2 sedang dirotasi, secret partner harus ditandai sebagai persisten dengan menambahkan anotasi disk.gdc.goog/persisted:

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

   3. Hapus secret dari cluster menggunakan perintah berikut:

      kubectl delete
      secret <secret_name> -n gpc-system
      

   4. Pada tahap ini, proses penghapusan akan dimulai (dan dapat dikonfirmasi dengan memeriksa apakah secret ditandai untuk dihapus). Penghapusan dan pembuatan ulang rahasia dapat memerlukan waktu hampir satu jam.

Merotasi sertifikat admin penyimpanan dan SVM

Sertifikat ini adalah sertifikat server yang diinstal ke dalam sistem ONTAP oleh GDC.

Ada satu sertifikat untuk admin penyimpanan, yang juga dikenal sebagai akun admin cluster. Namanya diawali dengan nama host sistem ONTAP, dan memiliki hash unik di bagian akhir. Alat ini diinstal di vserver admin cluster. GDC menggunakan sertifikat ini secara internal untuk tugas administratif.

Ada juga beberapa sertifikat sisi server yang ditentukan untuk SVM ONTAP. Kredensial ini menetapkan keaslian untuk klien yang berkomunikasi dengan SVM.

Semua sertifikat dapat dirotasi menggunakan proses yang sama. Karena ketidakcocokan sertifikat CA root di cluster root-admin, untuk sertifikat cluster dan SVM, yang tercantum dalam tabel berikut, rotasi memerlukan rotasi semua sertifikat dalam daftar masing-masing. Artinya, jika ada sertifikat cluster yang perlu dirotasi, semua sertifikat cluster lainnya juga harus dirotasi. Hal yang sama berlaku untuk sertifikat SVM. Batasan ini akan diatasi setelah pengelolaan sertifikat otomatis diterapkan.

Prasyarat

• Akses admin ke cluster ONTAP atau SVM yang relevan
• Akses kubectl ke cluster Kubernetes yang sesuai
• menginstal ulang sertifikat client-ca yang diuraikan dalam langkah penginstalan sertifikat client-ca.

Pemetaan antara sertifikat dan secret Kubernetes

Untuk setiap sertifikat yang diinstal di ONTAP, ada secret Kubernetes yang sesuai di server Management API yang berisi detail sertifikat. GDC membuat sertifikat, dan proses penggantian sertifikat sangat sederhana: hapus secret yang sesuai dengan sertifikat tertentu, dan sertifikat akan segera dibuat ulang. Sertifikat baru tersebut kemudian dapat diinstal ke ONTAP secara manual, menggantikan sertifikat lama.

Gunakan kubectl get secrets -n <namespace> -s <secret> -o yaml untuk memeriksa sertifikat di Kubernetes dan memverifikasi bahwa sertifikat tersebut cocok dengan detail di ONTAP yang terlihat dari security certificate show -vserver <svm_name>. Namespace akan selalu berupa "gpc-system" dan Anda dapat merujuk ke tabel berikutnya untuk mengetahui nama rahasia.

Anda juga dapat melihat pemetaan Sertifikat ke Rahasia dengan memeriksa:

kubectl get certificates -n <namespace>

Sertifikat Cluster yang Relevan

Nama Umum ONTAP	Vserver	Nama Sertifikat K8S	Nama Secret Kubernetes	Deskripsi
T/A	<hostname>	<hostname>-admin-cert	<hostname>-admin-cert-secret	Sertifikat admin cluster
T/A	<hostname>	<hostname>-server-cert	<hostname>-server-cert-secret	Sertifikat server yang ditandatangani oleh penerbit GDC yang digunakan sebagai sertifikat server ONTAP
T/A	<hostname>	<hostname>-read-only-cert	<hostname>-read-only-cert-secret	Akses pemantauan hanya baca

Sertifikat SVM yang Relevan

Vserver	Nama Sertifikat K8S	Nama Secret Kubernetes	Deskripsi
admin-root	root-admin-server-cert	root-admin-server-cert-secret	Sertifikat server yang ditandatangani oleh penerbit GDC yang digunakan sebagai sertifikat server SVM
admin-root	root-admin-s3-server-cert	root-admin-s3-server-cert-secret	Sertifikat server yang ditandatangani oleh penerbit GDC yang digunakan sebagai sertifikat server S3 ONTAP
admin-root	root-admin-client-cert	root-admin-client-cert-secret	Akses administrator SVM
admin-root	root-admin-s3-identity-client-cert	root-admin-s3-identity-client-cert-secret	Akses identitas S3

Validasi

Sertifikat Vserver

Setelah semua sertifikat dirotasi, pastikan backend Trident masih terhubung dengan berhasil untuk setiap cluster yang terkait dengan sertifikat server yang dirotasi.

1. Jalankan perintah berikut:

   export KUBECONFIG= #path to root-admin kubeconfig
   

   kubectl get tridentbackendconfigs -n netapp-trident
   

   Output akan terlihat seperti:

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

2. Pastikan PHASE adalah Bound dan Status adalah Success.

Sertifikat admin root

Untuk menguji sertifikat admin, kita dapat membuat StorageVirtualMachine pengujian baru dan melihat bahwa GDC dapat merekonsiliasinya dengan tepat. Langkah-langkahnya adalah sebagai berikut:

1. Buat daftar StorageVirtualMachines yang ada dan pilih salah satunya untuk dikloning sebagai pengujian.
2. Ekstrak spesifikasi Kubernetes untuknya.
3. Edit definisi untuk mengubah nama dan menghapus kolom yang tidak diperlukan.
4. Terapkan definisi pengujian.
5. Tunggu hingga status StorageVirtualMachine menjadi Ready.
6. Hapus StorageVirtualMachine pengujian.
7. Hapus SVM sebenarnya dari ONTAP.

Contoh

Contoh ini menggunakan namespace GDC NetApp gpc-system dan meng-clone organization-root-user untuk sementara ke SVM baru bernama test-svm.

1. Mencantumkan SVM:

   kubectl get storagevirtualmachines -n ngpc-system
   

   Output:

   NAME                      AGE
   organization-root-admin   13d
   

2. Ekstrak spesifikasi:

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

3. Edit spesifikasi agar terlihat mirip dengan berikut:

   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. Terapkan ke cluster:

   kubectl create -f svm.yaml
   

5. Tunggu hingga SVM baru siap. Amati output secara berkala:

   kubectl get storagevirtualmachines -n gpc-system test-svm
   

   Keberhasilan ditunjukkan oleh:

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

   atau AnsibleJobSucceed.

6. Hapus resource SVM:

   kubectl delete storagevirtualmachines -n gpc-system test-svm
   

7. Menghapusnya sepenuhnya dari ONTAP. Menghapus resource tidak akan menghapusnya dari ONTAP.

   Login ke konsol NetApp dan hapus SVM:

   alatl12-gpcstge02::> vserver delete test-svm
   

   Output:

   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
   

Gunakan petunjuk berikut untuk memutar sertifikat ONTAP secara manual jika Anda menemukan error selama validasi.

Petunjuk

Jika nama sertifikat ONTAP sebelumnya tidak berlaku, tidak ada yang perlu diubah di ONTAP. Periksa sertifikat dan secret di Kubernetes, lalu hapus secret.

1. Buat sertifikat baru, dengan merujuk pada tabel sebelumnya untuk nama rahasia:

   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. Melihat sertifikat yang diinstal untuk vserver tertentu, untuk sertifikat yang diinstal di ONTAP (tidak ditandai sebagai tidak berlaku):

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

3. Periksa secret yang cocok di Kubernetes (lihat tabel sebelumnya):

   kubectl get certificates -n <namespace>
   

4. Jika sudah puas dengan kecocokan, buat sertifikat baru dengan menghapus secret:

   kubectl delete secret -n <namespace> <secret_name>
   

5. Periksa kembali secret untuk melihat bahwa sertifikat baru telah dibuat ulang. Setelah dikonfirmasi, buat sertifikat server baru di ONTAP. Hanya lakukan langkah-langkah berikut untuk sertifikat sebelumnya dengan sufiks "server-cert".

6. Ekstrak isi sertifikat TLS baru menggunakan kubectl dan alat lainnya secara langsung, lalu instal ke ONTAP:

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

   Perintah pertama adalah:

   Please enter Certificate: Press <Enter> when done

   Di kolom tersebut, Anda harus memasukkan tls.crt. Jika ada beberapa blok sertifikat di tls.crt, masukkan blok pertama, dan simpan blok sertifikat yang tersisa sebagai sertifikat perantara untuk referensi pada langkah berikutnya.

7. Sistem akan meminta: Please enter Private Key: Press <Enter> when done. Tempelkan isi file tls.key Anda, lalu tekan Enter.

   Selanjutnya, akan muncul perintah: Do you want to continue entering root and/or intermediate certificates {y|n}: Jika file tls.crt Anda hanya berisi satu sertifikat, ketik N, lalu tekan Enter. Jika tidak, ketik Y, lalu tekan Enter.

   Jika Anda mengetik Y: Anda akan diminta untuk memasukkan sertifikat perantara. Tempelkan satu per satu dari file tls.crt Anda, tekan Enter setelah setiap kode. Terakhir, tempelkan sertifikat root dari file ca.crt Anda, lalu tekan Enter.

   Jika Anda mengetik N: (Tidak ada tindakan lebih lanjut yang diperlukan terkait sertifikat pada perintah ini)

   Kemudian, ONTAP akan menampilkan nomor seri. Catat nomor ini, karena mewakili nomor seri sertifikat dan CA baru. Nomor seri ini akan disebut sebagai <new\_server\_serial> dan <new\_ca> pada langkah-langkah berikutnya. Jangan ikuti langkah-langkah sertifikat ini jika Anda mengonfigurasi sertifikat server S3.

8. Melihat status konfigurasi SSL saat ini untuk vserver dan cluster. Siapkan CA Penerbit Sertifikat Server, Nama Umum Sertifikat Server, dan Nomor Seri Sertifikat Server, karena ketiganya akan disebut sebagai <old\_server\_common\_name>, <old\_ca>, dan <old\_server\_serial>:

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

   Perintah ini akan menampilkan info SSL, dengan info sertifikat server lama. Anda dapat mereferensikannya nanti untuk memastikan info tersebut telah diperbarui, setelah Anda mengubah konfigurasi SSL.

9. Ubah konfigurasi ssl:

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

10. Lihat status baru konfigurasi SSL untuk vserver dan cluster. Perintah ini akan menampilkan nomor seri yang telah diupdate untuk sertifikat server yang kini diinstal:

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

11. Hapus sertifikat server lama setelah memverifikasi langkah sebelumnya:

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

Sertifikat Client-CA

1. Ambil semua sertifikat CA dari ConfigMap trust-store-internal-only di namespace gpc-system menggunakan perintah berikut:

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

2. Untuk setiap sertifikat CA yang diambil pada langkah sebelumnya, jalankan perintah berikut di cluster ONTAP Anda:

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

   Anda akan diminta: Please enter Certificate: Press <Enter> when done. Tempel setiap blok sertifikat yang diambil pada langkah 1, lalu tekan Enter. Ulangi perintah penginstalan ini untuk setiap sertifikat CA.

Merotasi sertifikat Harvest

Pembuatan sertifikat Harvest bergantung pada <hostname>-read-only-cert-secret. Pastikan <hostname>-read-only-cert-secret diputar sebelum melanjutkan.

1. Lihat sertifikat yang diinstal untuk pod Harvest:

   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. Patch rahasia kredensial Harvest untuk menyediakan sertifikat yang diperbarui:

   $ 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. Mulai ulang layanan Harvest untuk memuat konfigurasi yang diupdate:

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

Merotasi sertifikat sistem file

Jalankan perintah berikut untuk membuat ulang file-storage-webhooks-serving-cert dan sertifikat 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

Mulai ulang pod untuk memuat konfigurasi yang diupdate:

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

Merotasi sertifikat Trident dan ONTAP

Trident harus berkomunikasi dengan ONTAP. Hal ini dikonfigurasi dengan backend Trident yang menggunakan sertifikat klien <svm\_name>-client-cert-secret> yang ditentukan sebelumnya. Rotasi sertifikat klien bukan bagian dari Trident, tetapi Trident mengandalkan bagian dari sertifikat ini, yang perlu diupdate.

Petunjuk

Untuk update sertifikat CA:

1. Ekspor KUBECONFIG untuk mengarah ke kubeconfig untuk cluster tertentu ke komponen Trident yang dimaksud. Setiap cluster akan dikonfigurasi dengan Trident.

2. Ambil sertifikat CA, yang dienkode base64 dari secret client-cert dan simpan sebagai variabel:

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

3. Patch objek tridentBackendConfig:

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

Untuk sertifikat dan kunci klien sebenarnya:

1. Ambil sertifikat TLS, yang dienkode base64 dari secret client-cert, lalu simpan sebagai variabel:

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

2. Ambil kunci TLS, yang dienkode ganda base64 dari secret client-cert dan simpan sebagai variabel:

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

3. Perbarui secret backend dengan kunci pribadi:

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

4. Patch konfigurasi backend dengan sertifikat TLS:

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

Merotasi sertifikat pengontrol Trident

Kontainer Trident harus berkomunikasi dengan Operator Trident. Komunikasi ini dilakukan melalui HTTPs, dan sertifikat server serta klien harus dikelola sebagai bagian dari proses ini.

Validasi

Pastikan daemonset dan deployment (jika berlaku) berada dalam kondisi baik.

Gunakan petunjuk berikut untuk memutar sertifikat server dan klien secara manual jika Anda menemukan error selama validasi.

Petunjuk

Sertifikat server dan klien tidak memiliki sertifikat yang sesuai di sisi ONTAP. Data ini hanya terdapat dalam cluster.

1. Hapus rahasia yang sesuai dengan sertifikat yang akan segera berakhir.

   kubectl delete secret -n netapp-trident <secret_name>
   

2. Mulai ulang daemonset netapp-trident-csi:

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

3. Untuk rotasi sertifikat server, Anda juga perlu memulai ulang deployment netapp-trident-csi:

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

Sertifikat CA Trident

Sertifikat CA digunakan untuk menyediakan certificate authority untuk menandatangani sertifikat server dan klien Trident.

Nama Sertifikat	Namespace	Secret	Deskripsi
netapp-trident-csi-cert	netapp-trident	netapp-trident-csi-cert	Sertifikat CA Trident

Validasi

Anda akan melihat bahwa secret telah dibuat ulang. Agar sertifikat klien dan server diterapkan, Anda juga dapat mengikuti cara merotasi sertifikat pengontrol Trident dalam petunjuk sebelumnya setelah merotasi sertifikat ini.

Gunakan petunjuk berikut untuk memutar sertifikat CA secara manual jika Anda menemukan error selama validasi.

Petunjuk

Untuk merotasi kunci ini, Anda hanya perlu menghapus secret dari Kubernetes:

kubectl delete secret -n netapp-trident <secret_name>

Node CSI Trident dan SVM (data)

Ini adalah kumpulan kredensial CHAP iSCSI di seluruh SVM untuk mengaktifkan akses ke bidang data untuk akses blok. Hal ini tidak berlaku untuk protokol file.

Server Management API

Namespace	Secret	Deskripsi
gpc-system	<organization>-<type>-svm-credential	Konfigurasi SVM yang diperlukan untuk penyiapan Trident

Server Management API dan admin org.

Namespace	Secret	Deskripsi
gpc-system	<organization>-<type>-svm-credential	Konfigurasi SVM yang diperlukan untuk penyiapan Trident
netapp-trident	netapp-trident-backend-tbc-ontap	Secret yang diperlukan untuk mengelola backend Trident

Validasi

1. Verifikasi bahwa backend masih berhasil dikonfigurasi:

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

2. Verifikasi bahwa status backend adalah Success.

Gunakan petunjuk berikut untuk memutar rahasia secara manual jika Anda menemukan error selama validasi.

Petunjuk

Buat string acak baru dengan panjang 16 tanpa karakter khusus untuk secret inisiasi dan secret inisiasi target:

#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\"}}"

Kunci AES Trident

Kunci AES digunakan secara internal oleh Trident untuk mengenkripsi kredensial CHAP iSCSI untuk penggunaan internal Trident. ID ini adalah urutan karakter acak yang harus memiliki panjang 32 byte.

Cluster yang menjalankan Trident (dapat berupa cluster root/org-admin/user/system)

Namespace	Secret	Deskripsi
netapp-trident	netapp-trident-aes-key	Kunci AES yang diperlukan oleh Trident untuk mengenkripsi kredensial CHAP iSCSI

Validasi

1. Verifikasi bahwa backend masih berhasil dikonfigurasi:

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

2. Verifikasi bahwa status backend adalah Success.

3. Mencoba membuat volume pengujian:

   1. Buat file YAML dengan info PVC di dalamnya:

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

   2. Terapkan ke cluster Kubernetes:

      kubectl apply -f pvc.yaml
      

4. Pastikan tidak ada error di log CSI karena enkripsi iSCSI:

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

   Anda tidak akan melihat log yang ditampilkan jika tidak ada error.

5. Bersihkan file dan pvc:

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

Gunakan petunjuk berikut untuk memutar kunci secara manual jika Anda menemukan error selama validasi.

Petunjuk

Sebelum merotasi kunci ini, pastikan tidak ada pod yang tertunda dengan PV di cluster. Jika ada, tunggu hingga penyediaannya selesai sebelum mengganti kunci.

Buat string acak baru sepanjang 32 karakter tanpa karakter khusus untuk 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

Rollback

1. Lakukan rollback ke kredensial yang terakhir digunakan jika terjadi error:

   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. Ulangi langkah-langkah verifikasi.