הצפנת סודות בשכבת האפליקציה

במדריך הזה נסביר איך להצפין סודות של Kubernetes בשכבת האפליקציה באמצעות מפתח שמנוהל ב-Cloud Key Management Service ‏(Cloud KMS). תהליך ההצפנה של סודות מספק שכבת אבטחה נוספת לעומסי עבודה רגישים.

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

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

• רוטציית מפתחות
• הצפנת מעטפה

לחצו על תראו לי איך כדי לקרוא הסבר מפורט על המשימה ישירות במסוף Google Cloud :

תראו לי איך

סקירה כללית

כברירת מחדל, ‏ Google Kubernetes Engine ‏ (GKE) מצפין תוכן של לקוחות שמאוחסן במצב מנוחה, כולל סודות. ‫GKE מטפל בהצפנה הזו של ברירת המחדל ומנהל אותה בשבילכם, בלי שתצטרכו לבצע פעולות נוספות. הצפנה של סודות בשכבת האפליקציה מספקת שכבת אבטחה נוספת למידע אישי רגיש שמאוחסן במסד הנתונים של מצב האשכול. כשמפעילים את ההצפנה, משתמשים במפתח שמנוהל באמצעות Cloud KMS כדי להצפין את הנתונים בשכבת האפליקציה.

ב-GKE בגרסה 1.35 ואילך, משאבי Kubernetes הספציפיים שמוצפנים תלויים בחנות המפתחות והערכים שמארחת את מצב האשכול, באופן הבא:

• ‫Spanner: הצפנת סודות בשכבת האפליקציה מצפינה את כל האובייקטים של Kubernetes API.
• ‫etcd: הצפנת סודות בשכבת האפליקציה מצפינה בעיקר סודות.

כדי להשתמש בהצפנת סודות בשכבת האפליקציה, קודם צריך ליצור מפתח Cloud KMS ולהעניק לסוכן השירות של Kubernetes Engine גישה למפתח. אתם יכולים להשתמש במפתח עם כל אחת מרמות ההגנה שנתמכות על ידי Cloud KMS.

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

הצפנת מעטפות

ב-Kubernetes יש הצפנת מעטפת של Secrets באמצעות ספק KMS. כלומר, נעשה שימוש במפתח מקומי, שבדרך כלל נקרא מפתח להצפנת נתונים (DEK), כדי להצפין את ה-Secrets. מפתח ה-DEK עצמו מוצפן באמצעות מפתח אחר שנקרא מפתח להצפנת מפתחות הצפנה (KEK). מפתח ה-KEK לא מאוחסן ב-Kubernetes.

להצפנת מעטפות יש את היתרונות הבאים:

• ביצועים משופרים בהשוואה להצפנה באמצעות מפתח ציבורי:‏ GKE משתמש רק ב-Cloud KMS API כדי להצפין מפתחות DEK חדשים באמצעות KEK או כדי לפענח DEK כשהמטמון המקומי ריק.
• ניהול טוב יותר של מפתחות בהיקף גדול: מפתח KEK יחיד יכול להצפין כמה מפתחות DEK. מספר המפתחות שצריך לאחסן בשירות Cloud KMS קטן בהרבה ממספר המפתחות שמצפינים את הנתונים שלכם.
• אפשרות להשתמש בשורש מרכזי של אמון: סודות שמאוחסנים ב-Kubernetes יכולים להסתמך על שורש חיצוני של אמון. כלומר, אתם יכולים להשתמש ב-Root of Trust מרכזי, למשל מודול אבטחה לחומרה, לכל הסודות שלכם. לגורם עוין שיש לו גישה למאגרי התגים שלכם במצב אופליין אין אפשרות להשיג את הסודות שלכם.

בעזרת הצפנת סודות בשכבת האפליקציה ב-GKE, ‏ GKE מצפין את הסודות באמצעות מפתחות הצפנה מקומיים וספק AES-CBC. ‫GKE מצפין את מפתחות ה-DEK באמצעות מפתח KEK שמנוהל ב-Cloud KMS.

מידע נוסף על הצפנת מעטפות

מה קורה כשהנתונים מוצפנים

כשיוצרים משאב חדש ב-Kubernetes שעומד בדרישות להצפנה, קורה הדבר הבא:

1. ‫GKE יוצר מפתח DEK באמצעות מחולל מספרים אקראי.

2. ‫GKE מצפין את הנתונים באופן מקומי במישור הבקרה באמצעות מפתח ה-DEK הזה.

3. ‫GKE שולח את ה-DEK ל-Cloud KMS להצפנה. בפעולה הזו נעשה שימוש ב-Kubernetes Engine Service Agent של הפרויקט כדי לבצע אימות ל-Cloud KMS.

4. ‫Cloud KMS מצפין את ה-DEK באמצעות ה-KEK ושולח אותו בחזרה למישור הבקרה של GKE.

5. מישור הבקרה של GKE מאחסן את הנתונים המוצפנים לצד ה-DEK המוצפן במסד הנתונים של האשכול. מפתח ה-DEK בטקסט לא מוצפן לא נכתב לדיסק, אבל הוא נשמר במטמון בזיכרון כדי לשפר את הביצועים.

כשלקוח מבקש נתונים משרת ה-API של Kubernetes, התהליך הבא מתרחש:

1. מישור הבקרה של GKE מאחזר את הנתונים המוצפנים ממסד הנתונים של מצב האשכול.

2. מישור הבקרה של GKE בודק את מטמון הזיכרון כדי למצוא את מפתח ה-DEK בטקסט גלוי. אם ה-DEK בטקסט ללא הצפנה נמצא במטמון, GKE משתמש בו כדי לפענח את הנתונים.

3. אם מפתח ה-DEK לא נמצא במטמון, ‏ GKE שולח את מפתח ה-DEK המוצפן אל Cloud KMS כדי לפענח אותו באמצעות מפתח ה-KEK.

4. ‫GKE מקבל את ה-DEK המפוענח מ-Cloud KMS ומשתמש ב-DEK כדי לפענח את הנתונים.

5. שרת ה-API של Kubernetes מחזיר את הנתונים המפוענחים ללקוח.

מה קורה כשמשמידים מפתח

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

אפשר לשמור את הגרסה הקודמת של ה-KEK כדי להימנע מהצפנה מחדש של סודות, אבל תמשיכו לשלם על כל ה-KEK הפעילים ב-Cloud KMS. פרטים על התמחור מופיעים במאמר תמחור של Cloud KMS.

אלא אם אתם משתמשים בהקרנת נפח של אסימונים של חשבון שירות, חשבונות שירות שמשמשים את עומסי העבודה שלכם ב-GKE משתמשים גם ב-Secrets, ואם מפתח מושמד, הם לא זמינים יותר. אם לא תהיה גישה למשאבים האלה, עומסי העבודה ייכשלו.

יש יוצאים מן הכלל:

• ל-Pods עם גישה קיימת ל-Secrets כנפחים מוצמדים או כמשתני סביבה תהיה גישה.

• אחרי שמשמידים את ה-KEK, מישור הבקרה של GKE עדיין יכול להשתמש בערכי מיפוי של DEK שנשמרו במטמון כדי לפענח נתונים. כך פודים שהופעלו מחדש או שנקבע להם מועד חדש יוכלו לגשת לנתונים, אלא אם יקרה אחד מהמקרים הבאים:

  • מישור הבקרה של האשכול מופעל מחדש.
  • ה-Pod של מישור הבקרה של GKE מופעל מחדש.
  • מפתח ה-DEK לא נמצא במטמון של מישור הבקרה של GKE.

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

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

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

• כדי לבצע את התרגילים בנושא הזה, אתם צריכים שני Google Cloud פרויקטים:

  • פרויקט המפתח: כאן יוצרים מפתח להצפנת מפתחות הצפנה (KEK).

  • פרויקט אשכול: כאן יוצרים אשכול שמאפשר הצפנה של סודות בשכבת האפליקציה.

  אתם יכולים להשתמש באותו פרויקט גם לפרויקט המרכזי וגם לפרויקט האשכול. אבל השיטה המומלצת היא להשתמש בפרויקטים נפרדים.

• בפרויקט המפתח, מוודאים שהפעלתם את Cloud KMS API.

  הפעלת Cloud KMS API

• בפרויקט המפתח, המשתמש שיוצר את אוסף המפתחות והמפתח צריך את ההרשאות הבאות ב-IAM:

  • cloudkms.keyRings.getIamPolicy
  • cloudkms.keyRings.setIamPolicy

  ההרשאות האלה (ועוד רבות אחרות) מוענקות לroles/cloudkms.admin תפקיד המוגדר מראש בניהול זהויות והרשאות גישה. מידע נוסף על הענקת הרשאות לניהול מפתחות זמין במסמכי התיעוד של Cloud KMS.

• בפרויקט של האשכול, מוודאים שהפעלתם את Google Kubernetes Engine API.

  הפעלת Google Kubernetes Engine API

• מוודאים שהתקנתם את Google Cloud CLI.

• עדכון gcloud לגרסה האחרונה:

  gcloud components update

יצירת מפתח Cloud KMS

כדי ליצור מפתח Cloud KMS, קודם צריך ליצור אוסף מפתחות. מפתחות ואוספי מפתחות הם משאבים אזוריים. כשיוצרים אוסף מפתחות, מציינים מיקום שתואם למיקום של אשכול GKE:

• אשכול אזורי צריך להשתמש במחזיק מפתחות מאזור על. לדוגמה, קלאסטר באזור us-central1-a יכול להשתמש רק במפתח באזור us-central1.

• אשכול אזורי צריך להשתמש באוסף מפתחות מאותו מיקום. לדוגמה, אשכול באזור asia-northeast1 צריך להיות מוגן באמצעות מחזיק מפתחות מהאזור asia-northeast1.

אי אפשר להשתמש באזור global של Cloud KMS עם GKE.

אפשר להשתמש ב-CLI של gcloud או במסוף Google Cloud .

gcloud kms keyrings create RING_NAME \
    --location=LOCATION \
    --project=KEY_PROJECT_ID

gcloud kms keys create KEY_NAME \
    --location=LOCATION \
    --keyring=RING_NAME \
    --purpose=encryption \
    --project=KEY_PROJECT_ID

מתן הרשאה לשימוש במפתח

לסוכן השירות של Kubernetes Engine בפרויקט האשכול יש את השם הבא:

service-CLUSTER_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com

מחליפים את CLUSTER_PROJECT_NUMBER במספר הפרויקט של האשכול. כדי למצוא את מספר הפרויקט באמצעות ה-CLI של gcloud, מריצים את הפקודה הבאה:

gcloud projects describe CLUSTER_PROJECT_ID \
    --format="value(projectNumber)"

כדי להעניק גישה לסוכן השירות של Kubernetes Engine, אפשר להשתמש במסוף Google Cloud או ב-CLI של gcloud.

gcloud kms keys add-iam-policy-binding KEY_NAME \
    --location=LOCATION \
    --keyring=RING_NAME \
    --member=serviceAccount:SERVICE_ACCOUNT_NAME \
    --role=roles/cloudkms.cryptoKeyEncrypterDecrypter \
    --project=KEY_PROJECT_ID

אם המפתח הוא מפתח Cloud HSM, מוודאים שיש לו מספיק מכסה.

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

הפעלת הצפנה של סודות בשכבת האפליקציה

אתם יכולים להפעיל הצפנה של סודות בשכבת האפליקציה באשכולות חדשים או קיימים של GKE Standard ו-GKE Autopilot באמצעות ה-CLI של gcloud או מסוף Google Cloud .

הפעלה באשכול חדש

אפשר ליצור אשכול חדש עם הצפנה של סודות בשכבת האפליקציה באמצעותGoogle Cloud המסוף או ה-CLI של gcloud.

gcloud container clusters create-auto CLUSTER_NAME \
    --cluster-version=latest \
    --location=CONTROL_PLANE_LOCATION \
    --database-encryption-key=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/RING_NAME/cryptoKeys/KEY_NAME \
    --project=CLUSTER_PROJECT_ID

הפעלה באשכול קיים

אפשר להשתמש ב-CLI של gcloud או במסוף Google Cloud כדי לעדכן אשכול קיים כך שישתמש בהצפנת סודות בשכבת האפליקציה. ‫GKE מצפין את כל הסודות הקיימים והחדשים באמצעות מפתח ההצפנה שציינתם.

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

gcloud container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --database-encryption-key=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/RING_NAME/cryptoKeys/KEY_NAME \
    --project=CLUSTER_PROJECT_ID

עדכון מפתח Cloud KMS

אפשר להשתמש ב-CLI של gcloud או במסוף Google Cloud כדי לעדכן אשכול קיים כך שישתמש במפתח חדש של Cloud KMS.

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

gcloud container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --database-encryption-key=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/RING_NAME/cryptoKeys/KEY_NAME \
    --project=CLUSTER_PROJECT_ID

השבתת הצפנת סודות בשכבת האפליקציה

כדי להשבית את ההצפנה של סודות בשכבת האפליקציה, אפשר להשתמש ב-CLI של gcloud או במסוףGoogle Cloud .

gcloud container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --disable-database-encryption \
    --project=CLUSTER_PROJECT_ID

אימות שההצפנה של סודות בשכבת האפליקציה מופעלת

אפשר לבדוק אם נעשה שימוש בהצפנת סודות בשכבת האפליקציה באשכול באמצעות מסוףGoogle Cloud או ה-CLI של gcloud.

gcloud container clusters describe CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --format='value(databaseEncryption.state)' \
    --project=CLUSTER_PROJECT_ID

רוטציה של המפתחות

כשמבצעים רוטציה למפתח, הסודות הקיימים נשארים מוצפנים באמצעות הגרסה הקודמת של המפתח להצפנת מפתחות הצפנה (KEK). כדי לוודא שגרסה חדשה יותר של KEK עוטפת סוד, צריך להצפין מחדש את הסוד אחרי רוטציית מפתחות.

לדוגמה, יוצרים Secret ומאחסנים אותו, Secret1. הוא מוצפן באמצעות DEK1, שמוצפן בעצמו באמצעות KEKv1.

אחרי שמבצעים רוטציה למפתח ה-KEK, מצפינים מחדש את Secret1 כך שהוא יהיה ארוז על ידי DEK2, שבתורו ארוז על ידי KEKv2, מפתח ה-KEK שעבר רוטציה.

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

הצפנה מחדש של הסודות

אחרי שמבצעים רוטציה למפתח, צריך להצפין מחדש את הסודות כדי לעטוף אותם בגרסה החדשה של מפתח הצפנת המפתח (KEK). אפשר להצפין מחדש את הסודות באחת מהדרכים הבאות:

• באופן ידני, על ידי הרצת הפקודה kubectl בטרמינל.
• באופן אוטומטי, באמצעות עומס עבודה חוזר, כמו CronJob, כדי להריץ פקודה kubectl במרווחי זמן קבועים.

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

kubectl get secrets --namespace=NAMESPACE -o json \
    | kubectl annotate --overwrite -f - encryption-key-rotation-time="TIME"

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

• ‫NAMESPACE: מרחב השמות שבו רוצים לעדכן את הסודות. באשכולות רגילים, אפשר להשתמש בדגל --all-namespaces במקום זאת כדי לעדכן כל סוד באשכול באמצעות אותה פקודה. ב-Autopilot clusters, אפשר לעדכן רק את מרחבי השמות שבבעלותכם.
• ‫TIME: מחרוזת שמציינת מתי מתבצעת הרוטציה (לדוגמה, 20200909-090909).

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

מגבלות

• ‫GKE תומך בהצפנה של סודות בשכבת האפליקציה, עם עד 30,000 סודות לכל אשכול. אם מאחסנים יותר מ-30,000 סודות, יכול להיות שהאשכול יהפוך ללא יציב בזמן השדרוג, ועלול לגרום להפסקת פעולה של עומסי העבודה.
• מוודאים שהגודל הממוצע של המטא-נתונים של סוד בכל מרחב שמות קטן מ-5KiB. אם הגודל הממוצע של המטא-נתונים גדול מ-5KiB, יכול להיות שהאשכול ייכנס למצב לא תקין שבו חלק מהסודות מוצפנים וחלקם מפוענחים אחרי הפעלת התכונה או השבתת התכונה.

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

  המפתח לא צריך להיות באותו פרויקט כמו האשכול. מידע נוסף על המיקומים הנתמכים ב-Cloud KMS זמין במאמר בנושא Google Cloud מיקומים.

• ‫GKE תומך רק במפתחות מ-Cloud KMS. אי אפשר להשתמש בספק KMS אחר של Kubernetes או בספק הצפנה אחר.

פתרון בעיות

במאמר פתרון בעיות בהצפנת סודות בשכבת האפליקציה מוסבר איך לפתור בעיות בהצפנת סודות בשכבת האפליקציה, כולל בעיות בעדכונים של הצפנת סודות שנכשלו.

מפתח Cloud KMS מושבת

סוכן השירות של Kubernetes Engine לא יכול להשתמש במפתח Cloud KMS מושבת להצפנת סודות בשכבת האפליקציה.

כדי להפעיל מחדש מפתח מושבת, אפשר לעיין במאמר בנושא הפעלה של גרסת מפתח מושבתת.

גרסת מפתח של Cloud KMS נמחקת

אם סטטוס האשכול מכיל את ההודעה: KEY_VERSION_URI is not enabled, current state is: DESTROYED, המשמעות היא שגרסת המפתח ששימשה להצפנת סודות בשכבת האפליקציה הושמדה.

מחליפים את KEY_VERSION_URI במזהה המשאבים האחיד (URI) של גרסת המפתח.

המאמרים הבאים

• מידע נוסף על Secrets ב-Kubernetes
• מידע נוסף על ניהול סודות באמצעות Cloud KMS
• איך מאבטחים את האשכול