הצפנת הנתונים במעבר ב-GKE באמצעות מפתחות הצפנה בניהול המשתמש

רגילה

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

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

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

• נתונים במעבר.
• ‫WireGuard, שמשמש את GKE להצפנה ב-GKE Dataplane V2, בנוסף להצפנה שמוגדרת כברירת מחדל על ידי כרטיסי רשת של מכונות וירטואליות.

כברירת מחדל, Google מצפינה את כל הנתונים במעבר בין מכונות וירטואליות ברמת בקר ממשק הרשת (NIC), כדי להבטיח את הסודיות של הנתונים במעבר, ללא קשר לשירות או לאפליקציה שפועלים במכונה הווירטואלית (כולל GKE). שכבת ההצפנה הזו רלוונטית לכל צומתי ה-GKE ולתנועת הנתונים של ה-Pod. מפתחות ההצפנה מסופקים ומנוהלים על ידי Google.

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

מגבלות

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

• הצפנה שקופה בין צמתים ב-GKE נתמכת רק באשכולות GKE Dataplane V2.

• אין תמיכה ב-GKE Autopilot.

• הצפנה שקופה בין צמתים ב-GKE מתבצעת באמצעות WireGuard. ‫WireGuard לא עומד בדרישות של FIPS.

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

• הצפנה שקופה בין צמתים יחד עם Confidential GKE Nodes פועלת רק ב-Container-Optimized OS ‏ (COS) וב-Ubuntu, ולא ב-Windows.

• הצפנה שקופה בין צמתים לא מצפינה תעבורת נתונים ברשת שנוצרת על ידי צומת GKE או Pod באמצעות hostNetwork.

• הצפנה שקופה בין צמתים לא מצפינה תעבורת נתונים ברשת שנשלחת ל-Pod שנחשף ביציאת צומת. גם אם ExternalTrafficPolicy: Cluster מוגדר בשירות, התנועה שמועברת מהצומת הראשון שמקבל תנועה מהלקוח אל ה-Pod של ה-Backend לא מוצפנת.

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

• הצפנה שקופה בין צמתים עלולה לגרום להקצאת יתר של משאבים בצמתים. יכול להיות שתצפו לעלייה של 15% בממוצע ב-CPU בצמתים מסוג n2-standard-8 עם מערכת ההפעלה Ubuntu וקצב העברת נתונים של 2Gbps.

  העלייה בשימוש במעבד לא משויכת לאף Pod כי kube-scheduler לא מודע לה. יכול להיות שה-Pod עם התנועה המוגברת ישתמש בכל משאבי המעבד בצומת. ההגדרה הזו עלולה למנוע מ-Pods אחרים לקבל את משאבי ה-CPU שהם צריכים, גם אם הם מוגדרים בצורה נכונה. זה יכול לגרום לבעיות ב-Pods שמנסים להריץ עומסי עבודה רגישים או שצריכים להגיב במהירות לבקשות. כפתרון עקיף, אפשר להשאיר כמות משמעותית של CPU ללא תזמון בצמתים שבהם מופעלת הצפנה שקופה בין צמתים. אפשר גם לתזמן Pod עם PriorityClass נמוך, עם בקשת CPU גדולה אבל בלי שימוש ב-CPU הזה.

• הצפנה שקופה בין צמתים גורמת לזמן אחזור של 150 מיקרו-שניות בשני צמתים באותו אזור שלא נעשה בהם שימוש ב-Confidential GKE Nodes.

• כשמפעילים הצפנה שקופה בין צמתים, יכול להיות שתכונות של מעקב אחר תנועה שמשמשות למעקב אחר תנועה ב-Pods לא יפעלו כמצופה, כי הנתונים במעבר מוצפנים באמצעות מפתחות שלא נגישים לתשתית הבסיסית של Google.

• כשמפעילים הצפנה שקופה בין צמתים, כתובות ה-IP של ה-Pod לא מוצגות ב-VPC. תכונות שתלויות בבדיקת מנות, כמו Packet Mirroring וכללי חומת אש של VPC שמבוססים על Pod CIDR, לא תואמות להצפנה שקופה בין צמתים.

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

• הצפנה שקופה בין צמתים משביתה חלק מהיכולות של שכבה 7 ב-GKE Dataplane V2. לכן, אי אפשר להפעיל בו-זמנית מדיניות רשת של FQDN והצפנה שקופה בין צמתים.

• אי אפשר להפעיל את התכונה הזו במקביל להרשאות גישה בתוך הצומת.

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

לפני שמתחילים, חשוב לוודא שביצעתם את הפעולות הבאות:

• מפעילים את ממשק Google Kubernetes Engine API.
הפעלת Google Kubernetes Engine API
• כדי להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז להפעיל את gcloud CLI. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.
  הערה: אם כבר התקנתם את ה-CLI של gcloud, הקפידו להגדיר את compute/region המאפיין. אם אתם משתמשים בעיקר באשכולות אזוריים, עליכם להגדיר את compute/zone במקום זאת. אם מגדירים מיקום ברירת מחדל, אפשר להימנע משגיאות ב-CLI של gcloud כמו השגיאה הבאה: One of [--zone, --region] must be supplied: Please specify location. יכול להיות שתצטרכו לציין את המיקום בפקודות מסוימות אם המיקום של האשכול שונה מברירת המחדל שהגדרתם.

• הצפנה שקופה בין צמתים ב-GKE נתמכת רק ב-Google Cloud CLI בגרסה 458.0.0 ואילך, ובגרסאות הבאות של GKE:

  • ‫1.26.10-gke.1024000 ואילך
  • ‫1.27.7-gke.1506000 ואילך
  • ‫1.28.2-gke.1098000 ואילך

הפעלה של הצפנה שקופה בין צמתים באמצעות GKE

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

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

1. כדי להפעיל הצפנה שקופה בין צמתים באשכול חדש:

   gcloud container clusters create CLUSTER_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --enable-datapane-v2 \
       --in-transit-encryption inter-node-transparent
   

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

   • CLUSTER_NAME בשם של האשכול.
   • ‫CONTROL_PLANE_LOCATION: המיקום של מישור הבקרה של האשכול ב-Compute Engine. מציינים אזור לאשכולות אזוריים או אזור זמין לאשכולות אזוריים.
   הערה: מומלץ ליצור אשכולות חדשים עם הצפנה בין צמתים מופעלת, במקום ליצור אותם עם הצפנה בין צמתים מושבתת ואז להפעיל אותה. הפעלה של הצפנה בין צמתים בשלב מאוחר יותר עלולה לגרום להפעלה מחדש של מאגר הצמתים.

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

   kubectl -n kube-system exec -ti anetd-XXXX -- cilium status | grep Encryption
   

   הפלט אמור להיראות כך:

   Encryption: Wireguard [cilium_wg0 (Pubkey: <key>, Port: 51871, Peers: 2)]
   

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

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

1. כדי להפעיל הצפנה שקופה בין צמתים באשכול קיים:

   gcloud container clusters update CLUSTER_NAME \
     --in-transit-encryption inter-node-transparent \
     --location=CONTROL_PLANE_LOCATION
   

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

   • CLUSTER_NAME בשם של האשכול.
   • ‫CONTROL_PLANE_LOCATION: המיקום של מישור הבקרה של האשכול ב-Compute Engine. מציינים אזור לאשכולות אזוריים או אזור זמין לאשכולות אזוריים.
   הערה: מומלץ לבצע את הפעולה הזו במהלך חלון תחזוקה, כי היא עלולה לשבש את התנועה אל ה-Pod. יכול להיות שיחלפו כמה שעות עד שהעדכון של האשכול וההתקנה של רשת ההצפנה בין הצמתים יסתיימו.

2. כדי לבדוק שהפקודה של Google Cloud CLI הושלמה בהצלחה :

   gcloud container clusters describe CLUSTER_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --format json | jq .status
   

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

   • CLUSTER_NAME בשם של האשכול.
   • ‫CONTROL_PLANE_LOCATION: המיקום של מישור הבקרה של האשכול ב-Compute Engine. מציינים אזור לאשכולות אזוריים או אזור זמין לאשכולות אזוריים.

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

3. כדי לוודא שהצמתים הופעלו מחדש:

   kubectl get nodes
   

   בודקים את השדה AGE של כל צומת וממשיכים אם השדה AGE משקף צמתים חדשים.

4. כדי לוודא שההגדרה תקינה, אפשר להשתמש בפקודה הבאה כדי לבדוק את סטטוס ההצפנה:

   kubectl -n kube-system exec -ti anetd-XXXX -- cilium status | grep Encryption
   

   הפלט אמור להיראות כך:

   Encryption: Wireguard [cilium_wg0 (Pubkey: <key>, Port: 51871, Peers: 2)]
   

   מוודאים שמספר העמיתים קטן ב-1 ממספר הצמתים באשכול. לדוגמה, באשכול עם 24 צמתים, מספר העמיתים צריך להיות 23. אם מספר העמיתים לא קטן ב-1 ממספר הצמתים באשכול, מפעילים מחדש את סוכן anetd בצמתים.

הפעלה בכמה אשכולות

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

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

1. מפעילים הצפנה שקופה בין צמתים באשכול חדש או באשכול קיים.

2. רושמים את האשכול ב-Fleet.

3. מפעילים הצפנה שקופה בין הצמתים עבור הצי:

   gcloud container fleet dataplane-v2-encryption enable --project PROJECT_ID
   

   מחליפים את PROJECT_ID במזהה הפרויקט.

4. מאמתים את הסטטוס בכל הצמתים:

   kubectl -n kube-system get pods -l k8s-app=cilium -o name | xargs -I {} kubectl -n kube-system exec -ti {} -- cilium status
   

   הפלט אמור להיראות כך:

   ...
   Encryption: Wireguard [cilium_wg0 (Pubkey: <key>, Port: 51871, Peers: 5)]
   ...
   

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

השבתת הצפנה שקופה בין צמתים

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

• ההצפנה השקופה בין הצמתים מופעלת לכל האשכול, ואי אפשר להשבית אותה באופן חלקי במשאבי Kubernetes ספציפיים, כמו מרחבי שמות או Pods.

• מומלץ לבצע את הפעולה הזו במהלך חלון זמן לתחזוקה, כי היא תשבש את התנועה של ה-Pod.

השבתה באשכול יחיד

כדי להשבית הצפנה שקופה בין צמתים באשכול יחיד:

gcloud container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --in-transit-encryption none

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

• ‫CLUSTER_NAME: עם שם האשכול.
• ‫CONTROL_PLANE_LOCATION: המיקום של מישור הבקרה של האשכול ב-Compute Engine. מציינים אזור לאשכולות אזוריים או אזור זמין לאשכולות אזוריים.

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

השבתה באשכול שמשתייך לצי

אפשר להשבית את ההצפנה של אשכול בצי באמצעות אחת משתי האפשרויות הבאות:

• כדי להסיר לגמרי את האשכול מהצי, מבטלים את הרישום של האשכול.

• אפשרות אחרת היא להשאיר את האשכול בצי אבל להשבית את ההצפנה:

  gcloud container fleet dataplane-v2-encryption disable --project PROJECT_ID
  

  מחליפים את PROJECT_ID במזהה הפרויקט.

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

  kubectl -n kube-system exec -ti anetd-XXXX -- cilium status | grep Encryption
  

השבתה של כל ציידי האשכולות

• כדי להשבית הצפנה שקופה בין צמתים בצי:

  gcloud container fleet dataplane-v2-encryption disable --project PROJECT_ID
  

  מחליפים את PROJECT_ID במזהה הפרויקט.

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

  gcloud services disable gkedataplanev2.googleapis.com \
      --project=PROJECT_ID
  

  מחליפים את PROJECT_ID במזהה הפרויקט.

  הערה: ה-API הזה אחראי לתכונת ההצפנה השקופה בין הצמתים (inter-node) בצי שלכם. כדי למנוע התנהגות לא צפויה, חשוב לוודא שממשק ה-API הזה לא נמצא בשימוש בשום מקום אחר בצי המכשירים לפני שמשביתים אותו.

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

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

  2. לרשום מחדש את האשכול החדש אחרי היצירה מחדש.

  3. אם שכחתם לבטל את הרישום של אשכול, תצטרכו למחוק את החברות הישנה וליצור מחדש את האשכול החדש עם חברות חדשה.

  אם לא תבצעו את השלבים האלה, יכול להיות שההצפנה של כמה אשכולות לא תופעל באשכול החדש עד ליצירה מחדש של החברות בצי.

איך פועלת הצפנה שקופה בין צמתים ב-GKE

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

הצפנה של תנועת נתונים ברשת בין שני פודים בצמתים שונים

כשההצפנה השקופה בין הצמתים מופעלת, GKE Dataplane V2 מצפין תעבורת נתונים מ-Pod ל-Pod אם ה-Pods נמצאים בצמתים שונים, ללא קשר לאשכול שאליו הצמתים האלה שייכים. אם האשכולות הם חלק מאותו צי, הם שייכים לאותו תחום הצפנה.

הערה: הצפנה שקופה בין צמתים מצפינה חבילות כשהן יוצאות מהצומת המקורי. הצפנה שקופה בין צמתים לא מצפינה חבילות בין Pods באותו צומת.

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

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

• התקשורת בין Pod ל-Pod בין צומת באשכול שבו מופעלת הצפנה שקופה בין צמתים לבין צומת באשכול שבו לא מופעלת הצפנה שקופה בין צמתים נכשלת.

יצירה ושימוש במפתח הצפנה

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

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

• המפתח הציבורי משותף עם צמתים אחרים באמצעות מישור הבקרה של GKE Dataplane V2, וכל הצמתים באותו תחום הצפנה יכולים לגשת אליו.

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

הערה: ‏ WireGuard לא עומד בדרישות של FIPS.

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

• צמד מפתחות פרטי/ציבורי:

  • המפתח הציבורי מופץ באשכול, וכל הצמתים באשכול יכולים לגשת אליו.

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

• מפתח סשן:

  • אי אפשר להגדיר את המקש הזה.

  • המפתח הזה מתחלף באופן מחזורי כל שתי דקות.

  • מפתח הסשן הוא בלעדי לצמתים שמעורבים במנהרה.

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

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