רוטציה של מפתחות אימות ואישורים של אחסון

מכשיר Google Distributed Cloud ‏ (GDC) עם בידוד פיזי מאמץ את ONTAP Select ‏ (OTS) כספק אחסון מוגדר בתוכנה. ל-OTS יש מערכת אימות משלה, שבה לכל זהות (שירות ליבה או לקוח) יש שם ומפתח משויכים.

במסמך הזה מתוארים השלבים לביצוע רוטציה של מפתחות ואישורים לאימות, שצריך לבצע עבור:

• רוטציה מתוזמנת של מפתחות כדי לוודא שהמכשיר תואם ומאובטח.
• חשיפה למפתח. מומלץ לבצע רוטציה של המפתח שנחשף בהקדם האפשרי.

לפני שמתחילים

חשוב לוודא שיש לכם את הגישה הבאה:

• גישה למסוף Admin של אשכול ONTAP
• קובץ Kubeconfig לשרת Management API

עדכון של פרטי הכניסה ל-IPsec ‏ (PSK)

מגרסה 9.10.1 ואילך, מערכת ONTAP תומכת באימות מבוסס-אישור עבור IPsec. הגרסה הזו של GDC היא 9.14.1 והיא משתמשת במפתחות משותפים מראש.

ב-Appliance, פרוטוקול IPsec מיושם עבור שני סוגים של תנועת OTS:

• תנועה חיצונית בין מארחי Bare Metal לבין מכונות וירטואליות של SVM.
• תנועה פנימית בין צמתי עובדים.

נעבור עליהם בנפרד.

דרישות מוקדמות

• גישה למסוף Admin של אשכול ONTAP
• מפתח חדש ששותף מראש
• קובץ Kubeconfig לשרת Management API
• גישה למארחים כדי לעדכן את ההגדרה של 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.

   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 לפי הסדר שמופיע ברשימה

   • מחיקת הסוד של התנועה הפנימית sh kubectl delete secret ots-internal-pre-shared-key -n gpc-system

   • מחיקת כל שלושת משימות המדיניות של מערכת ההפעלה 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

   • מחיקת כל שלושת הקבצים 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 דקות). חוזרים על שלב 2 עד שכל ה-CR נמצאים בסטטוס READY או Complete.

סיבוב של כפתורי עוצמת הקול

בקטע הזה מוסבר איך מבצעים רוטציה של פרטי הכניסה של נפח OTS באופן ידני.

לפני שמתחילים

כך עושים את זה:

1. מוודאים שאתם עומדים בדרישות המוקדמות לשימוש במחשב נייד.
2. מוודאים שאפשר להתחבר למסוף של אשכול OTS דרך BM01 או BM02.

התחלת רוטציית מפתחות עוצמת הקול

במסוף OTS, מפעילים את הרוטציה החד-פעמית של המפתחות:

volume encryption rekey start -vserver SVM_name -volume volume_name

הפקודה הבאה משנה את מפתח ההצפנה של vol1 ב-SVMvs1:

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 חיצוניים

בקטע הזה מוסבר איך לבצע רוטציה של האישורים של ה-HSM החיצוני ב-ONTAP ואיך לעדכן אותם.

דרישות מוקדמות

• הרשאת אדמין לאשכול ONTAP או למכונות ה-SVM הרלוונטיות
• הסיסמה הנוכחית
• גישה של kubectl לאשכולות המתאימים

הוראות

1. מגבים את האישורים הישנים של ה-HSM:

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

2. מעדכנים את הסוד של אישורי ה-HSM ב-Kubernetes:

   1. מעתיקים את קובץ ה-YAML הישן של הסוד: sh cp external-hsm-creds-old.yaml external-hsm-creds-new.yaml

   2. מעדכנים את הקובץ החדש external-hsm-creds-new.yaml עם פרטי הכניסה החדשים של ה-HSM, כולל אישור ה-CA של השרת, אישור הלקוח הציבורי והמפתח הפרטי של הלקוח.

   3. מחילים את השינוי ומעדכנים את אובייקט הסוד של HSM.

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

3. מעדכנים את האישורים של HSM ב-ONTAP:

   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. אפשר לוודא שהחלפת הסודות בוצעה על ידי בדיקה אם הסוד עדיין מסומן למחיקה. אם לא, הסוד עבר רוטציה. כדי לבדוק את זה, פועלים לפי שלב 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. בשלב הזה, תהליך המחיקה יתחיל (ואפשר לאשר אותו על ידי בדיקה אם הסוד מסומן למחיקה). יכול להיות שיעבור כמעט שעה עד שהסוד יימחק וייווצר מחדש.

החלפת אישורים של מנהל האחסון ושל SVM

האישורים האלה הם אישורי השרת שהותקנו במערכת ONTAP על ידי GDC.

יש אישור אחד לאדמין האחסון, שנקרא גם חשבון האדמין של האשכול. השם שלו מתחיל בשם המארח של מערכת ONTAP ומסתיים בגיבוב ייחודי. היא מותקנת ב-vserver של מנהל האשכול. ‫GDC משתמשת באישור הזה באופן פנימי למשימות אדמיניסטרטיביות.

יש גם כמה אישורים בצד השרת שמוגדרים ל-SVM של ONTAP. הם מאפשרים ללקוחות שמתקשרים עם מודלי ה-SVM לוודא שהתשובות אותנטיות.

אפשר להחליף את כל האישורים באותו תהליך. בגלל חוסר התאמה של אישור CA בסיסי באשכול של אדמין הבסיס, כדי לבצע רוטציה של אישורים של אשכולות ו-SVM, שמפורטים בטבלאות הבאות, צריך לבצע רוטציה של כל האישורים ברשימה המתאימה. כלומר, אם צריך להחליף אישור של אשכול, צריך להחליף גם את כל שאר האישורים של האשכול. אותו עיקרון חל על אישורי SVM. המגבלה הזו תיפתר אחרי שנחיל ניהול אוטומטי של אישורים.

דרישות מוקדמות

• הרשאת אדמין לאשכול ONTAP או למכונות ה-SVM הרלוונטיות
• גישת kubectl לאשכולות Kubernetes המתאימים
• להתקין מחדש את אישורי ה-CA של הלקוח לפי השלבים שמפורטים במאמר בנושא התקנת אישורי CA של הלקוח.

מיפוי בין אישורים לבין סודות ב-Kubernetes

לכל אישור שמותקן ב-ONTAP, יש סוד תואם של Kubernetes בשרת Management API שמכיל את פרטי האישור. ‫GDC יוצר את האישורים, ותהליך ההחלפה של אישור הוא פשוט: מוחקים את הסוד שמתאים לאישור מסוים, והאישור ייווצר מחדש באופן מיידי. אחר כך אפשר להתקין את האישור החדש ב-ONTAP באופן ידני, במקום האישור הישן.

משתמשים ב-kubectl get secrets -n <namespace> -s <secret> -o yaml כדי לבדוק את האישור ב-Kubernetes ולוודא שהוא תואם לפרטים ב-ONTAP כפי שמוצג ב-security certificate show -vserver <svm_name>. מרחב השמות תמיד יהיה gpc-system, ואפשר לעיין בטבלה הבאה כדי לראות את שם הסוד.

אפשר גם לראות את המיפוי של האישור לסוד על ידי בדיקה של:

kubectl get certificates -n <namespace>

אישורים רלוונטיים של אשכול

ONTAP Common Name	Vserver	שם האישור של K8S	שם הסוד ב-Kubernetes	תיאור
לא רלוונטי	<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	תיאור
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 הוא Bound והערך של Status הוא Success.

אישור אדמין ראשי

כדי לבדוק את אישור האדמין, אפשר ליצור StorageVirtualMachine חדש לבדיקה ולראות ש-GDC מצליח להתאים אותו בצורה נכונה. כדי לעשות את זה, צריך לבצע את השלבים הבאים:

1. מציגים את רשימת ה-StorageVirtualMachines הקיימים ובוחרים אחד לשכפול כבדיקה.
2. מחולצים את מפרט Kubernetes שלו.
3. עורכים את ההגדרה כדי לשנות את השם ולמחוק שדות מיותרים.
4. מחילים את הגדרת הבדיקה.
5. מחכים שהסטטוס של StorageVirtualMachine יהפוך ל-Ready.
6. מוחקים את מכונת ה-StorageVirtualMachine של הבדיקה.
7. מוחקים את ה-SVM בפועל מ-ONTAP.

דוגמה

בדוגמה הזו נעשה שימוש במרחב שמות של GDC NetApp‏ 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. עורכים את המפרט כך שייראה כמו הדוגמה הבאה:

   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 (כפי שמופיע בטבלה הקודמת):

   kubectl get certificates -n <namespace>
   

4. אם התוצאה תואמת, צריך למחוק את הסוד כדי ליצור אישור חדש:

   kubectl delete secret -n <namespace> <secret_name>
   

5. בודקים מחדש את הסוד כדי לראות שנוצר מחדש אישור חדש. אחרי האישור, יוצרים אישור שרת חדש ב-ONTAP. רק מבצעים את השלבים הבאים עבור האישורים הקודמים עם הסיומת server-cert.

6. מחלקים את גוף אישור ה-TLS החדש באמצעות kubectl וכלים אחרים ישירות, ומתקינים אותו ב-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 תחזיר מספר סידורי. חשוב לרשום את המספר הזה, כי הוא מייצג את המספר הסידורי של האישור החדש ושל רשות האישורים. מספר סידורי זה יכונה <new\_server\_serial> ו-<new\_ca> בשלבים הבאים. אל תפעלו לפי השלבים האלה בנוגע לאישור אם אתם מגדירים אישור שרת S3.

8. אפשר לראות את המצב הנוכחי של הגדרות ה-SSL עבור השרת הווירטואלי והאשכול. כדאי לשמור בהישג יד את רשות האישורים שהנפיקה את אישור השרת, את השם הנפוץ של אישור השרת ואת המספר הסידורי של אישור השרת, כי הם יופיעו בהמשך בתור <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. כדי לאחזר את כל האישורים של רשות האישורים מ-trust-store-internal-only ConfigMap במרחב השמות gpc-system, מריצים את הפקודה הבאה:

   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

הפקת אישור 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. מבצעים תיקון (patch) של הסוד של פרטי הכניסה של 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-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

מפעילים מחדש את ה-pods כדי לטעון את ההגדרה המעודכנת:

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 כדי להפנות אל קובץ ה-kubeconfig של האשכול שספציפי לרכיבי Trident הרלוונטיים. בכל אשכול תהיה הגדרה של Trident.

2. מעתיקים את אישור ה-CA בקידוד base64 מהסוד של אישור הלקוח ושומרים אותו כמשתנה:

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

3. מבצעים תיקון (patch) באובייקט tridentBackendConfig:

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

לגבי אישור הלקוח והמפתח בפועל:

1. שולפים את אישור ה-TLS בקידוד Base64 מהסוד של אישור הלקוח ומאחסנים אותו כמשתנה:

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

2. לוקחים את מפתח ה-TLS, מקודדים אותו פעמיים ב-Base64 מהסוד של אישור הלקוח ומאחסנים אותו כמשתנה:

   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 וגם הפריסה (במקרים הרלוונטיים) מופיעים במצב תקין.

אם נתקלתם בשגיאה במהלך האימות, תוכלו לפעול לפי ההוראות הבאות כדי להחליף ידנית את האישורים של השרת והלקוח.

הוראות

גם לשרת וגם לאישורי הלקוח אין אישור תואם בצד 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
   

אישור CA של Trident

אישור ה-CA משמש לספק את רשות האישורים לחתימה על אישורי השרת והלקוח של Trident.

שם האישור	מרחב שמות	Secret	תיאור
netapp-trident-csi-cert	netapp-trident	netapp-trident-csi-cert	אישור CA של Trident

אימות

אפשר לראות שהסוד נוצר מחדש. כדי שהאישורים של הלקוח והשרת ייכנסו לתוקף, אפשר גם לפעול לפי ההוראות הקודמות לרוטציה של האישורים של בקר Trident אחרי שמבצעים רוטציה של האישור הזה.

אם נתקלתם בשגיאה במהלך האימות, תוכלו לפעול לפי ההוראות הבאות כדי לבצע רוטציה ידנית של אישור ה-CA.

הוראות

כדי להחליף את המפתח הזה, צריך רק למחוק את ה-Secret מ-Kubernetes:

kubectl delete secret -n netapp-trident <secret_name>

צמתי Trident CSI ו-SVM (נתונים)

זוהי קבוצה של פרטי כניסה של iSCSI CHAP ברמת ה-SVM, שמאפשרת גישה למישור הנתונים לגישה לחסימה. ההגבלה הזו לא חלה על פרוטוקולים של קבצים.

שרת Management API

מרחב שמות	Secret	תיאור
gpc-system	<organization>-<type>-svm-credential	נדרשת הגדרת SVM להגדרת Trident

מנהל חשבון ארגוני ושרת Management API

מרחב שמות	Secret	תיאור
gpc-system	<organization>-<type>-svm-credential	נדרשת הגדרת SVM להגדרת Trident
netapp-trident	netapp-trident-backend-tbc-ontap	נדרש סוד כדי לנהל את ה-backend של 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\"}}"

מפתח AES של Trident

מפתח ה-AES משמש באופן פנימי את Trident להצפנת פרטי הכניסה של iSCSI CHAP לשימוש פנימי של Trident. זוהי רצף אקראי של תווים באורך של 32 בייט.

אשכול שמופעל בו Trident (יכול להיות אשכול root, אדמין ארגוני, משתמש או מערכת)

מרחב שמות	Secret	תיאור
netapp-trident	netapp-trident-aes-key	מפתח AES שנדרש ל-Trident כדי להצפין את פרטי הכניסה של iSCSI CHAP

אימות

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
   

אם אתם מוצאים שגיאה במהלך האימות, אתם יכולים להשתמש בהוראות הבאות כדי להחליף את המפתח באופן ידני.

הוראות

לפני שמבצעים רוטציה של המפתח הזה, צריך לוודא שאין פודים בהמתנה עם 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. מבצעים שוב את שלבי האימות.