בדף הזה מוסבר איך להצפין נתונים במעבר לתקשורת בין רכיבי 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 פועלת רק ב-מערכת הפעלה שמותאמת לקונטיינרים (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. תכונות שתלויות בבדיקת חבילות נתונים, כמו רפליקציה של חבילות נתונים וכללי חומת אש של VPC שמבוססים על Pod CIDR, לא תואמות להצפנה שקופה בין צמתים.
כשמפעילים הצפנה שקופה בין צמתים באשכולות שמצורפים לתת-רשתות שונות של VPC, צריך ליצור כללים של חומת אש באופן ידני כדי לאפשר תקשורת בין הצמתים באשכול.
ההצפנה השקופה בין הצמתים משביתה חלק מהיכולות של שכבה 7 ב-GKE Dataplane V2. לכן, אי אפשר להפעיל בו-זמנית את מדיניות הרשת FQDN ואת ההצפנה השקופה בין הצמתים.
אי אפשר להפעיל את התכונה הזו במקביל להרשאות גישה בתוך הצומת.
לפני שמתחילים
לפני שמתחילים, חשוב לוודא שביצעתם את הפעולות הבאות:
- מפעילים את ממשק Google Kubernetes Engine API. הפעלת Google Kubernetes Engine API
- אם רוצים להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז להפעיל את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה
gcloud components updateכדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.
הצפנה שקופה בין צמתים ב-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 באשכול יחיד או בסביבה מרובת אשכולות.
הפעלה באשכול חדש
כדי להפעיל הצפנה שקופה בין צמתים באשכול חדש:
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. מציינים אזור לאשכולות אזוריים או אזור זמין לאשכולות אזוריים.
כדי לוודא שההגדרה תקינה, משתמשים בפקודה הבאה כדי לבדוק את סטטוס ההצפנה:
kubectl -n kube-system exec -ti anetd-XXXX -- cilium status | grep Encryptionהפלט אמור להיראות כך:
Encryption: Wireguard [cilium_wg0 (Pubkey: <key>, Port: 51871, Peers: 2)]
הפעלה באשכול קיים
כדי להפעיל הצפנה שקופה בין צמתים באשכול קיים:
gcloud container clusters update CLUSTER_NAME \ --in-transit-encryption inter-node-transparent \ --location=CONTROL_PLANE_LOCATIONמחליפים את מה שכתוב בשדות הבאים:
CLUSTER_NAMEבשם של האשכול.-
CONTROL_PLANE_LOCATION: המיקום של מישור הבקרה של האשכול ב-Compute Engine. מציינים אזור לאשכולות אזוריים או אזור זמין לאשכולות אזוריים.
כדי לבדוק שהפקודה של 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 תגרום להפעלה מחדש אוטומטית של הצמתים. יכול להיות שיחלפו כמה שעות עד שהצומת יופעל מחדש והצמתים החדשים יאכפו את המדיניות.
כדי לוודא שהצמתים הופעלו מחדש:
kubectl get nodesבודקים את השדה
AGEשל כל צומת וממשיכים אם השדהAGEמשקף צמתים חדשים.כדי לוודא שההגדרה תקינה, אפשר להשתמש בפקודה הבאה כדי לבדוק את סטטוס ההצפנה:
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, הם לא יוכלו לתקשר עם אשכולות רגילים שההצפנה מופעלת בהם.
כדי להפעיל הצפנה שקופה בין צמתים בסביבה מרובת אשכולות:
מפעילים הצפנה שקופה בין צמתים באשכול חדש או באשכול קיים.
רושמים את האשכול ב-Fleet.
מפעילים הצפנה שקופה בין הצמתים עבור הצי:
gcloud container fleet dataplane-v2-encryption enable --project PROJECT_IDמחליפים את
PROJECT_IDבמזהה הפרויקט.אימות הסטטוס בכל הצמתים:
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)] ...
השבתת הצפנה שקופה בין צמתים
במקרים מסוימים, יכול להיות שתרצו להשבית את ההצפנה השקופה בין הצמתים באשכול 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. מציינים אזור לאשכולות אזוריים או אזור זמין לאשכולות אזוריים.
השבתה באשכול ששייך לצי
אפשר להשבית את ההצפנה של אשכול בצי באמצעות אחת משתי האפשרויות הבאות:
כדי להסיר לגמרי את האשכול מהצי, מבטלים את הרישום של האשכול.
אפשר גם להשאיר את האשכול בצי אבל להשבית את ההצפנה:
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במזהה הפרויקט.כדי לנהל ביעילות אשכולות עם אותו שם ולהבטיח הפעלה של הצפנה מרובת אשכולות, פועלים לפי השלבים הבאים:
מבטלים את הרישום של האשכול הישן מהצי לפני שיוצרים אשכול חדש עם אותו שם.
לרשום מחדש את האשכול החדש אחרי היצירה מחדש.
אם שכחתם לבטל את הרישום של אשכול, תצטרכו למחוק את החברות הישנה וליצור מחדש את האשכול החדש עם חברות חדשה.
אם לא תבצעו את השלבים האלה, יכול להיות שההצפנה של כמה אשכולות לא תופעל באשכול החדש עד ליצירה מחדש של החברות בצי.
איך הצפנה שקופה בין צמתים פועלת ב-GKE
בקטעים הבאים מוסבר איך הצפנה שקופה בין צמתים פועלת כשמפעילים אותה באשכול:
הצפנה של תעבורת נתונים ברשת בין שני פודים בצמתים שונים
כשההצפנה השקופה בין הצמתים מופעלת, GKE Dataplane V2 מצפין תעבורת נתונים מ-Pod ל-Pod אם ה-Pods נמצאים בצמתים שונים, ללא קשר לאשכול שאליו הצמתים האלה שייכים. אם האשכולות הם חלק מאותו צי, הם שייכים לאותו דומיין הצפנה.
אפשר להשתמש באותו צי מכשירים באשכולות עם הגדרות שונות של הצפנה שקופה בין צמתים. אם יש לכם סביבה מרובת אשכולות שבה רק חלק מהאשכולות משתמשים בהצפנה שקופה בין צמתים, כדאי לשים לב לנקודות הבאות:
התקשורת בין פודים בצמתים באותו אשכול מוצפנת באמצעות זוג מפתחות ציבורי/פרטי.
התקשורת בין Pod ל-Pod בין צומת באשכול שבו מופעלת הצפנה שקופה בין צמתים לבין צומת באשכול שבו לא מופעלת הצפנה שקופה בין צמתים נכשלת.
יצירה ושימוש במפתחות הצפנה
כשהתכונה מופעלת, כל צומת GKE באשכול יוצר באופן אוטומטי זוג מפתחות ציבורי/פרטי שנקרא מפתחות הצפנה.
המפתח הפרטי מאוחסן בזיכרון (לא בדיסק) ולעולם לא יוצא מהצומת. שימוש ב-GKE Confidential Nodes מצמצם עוד יותר את הסיכון לפריצה למפתחות, כי גם הזיכרון של הצומת מוצפן (עם מפתחות שונים).
המפתח הציבורי משותף עם צמתים אחרים באמצעות מישור הבקרה GKE Dataplane V2, וכל הצמתים באותו תחום הצפנה יכולים לגשת אליו.
אחרי החלפת המפתחות, כל צומת יכול ליצור מנהרת WireGuard עם צמתים אחרים באותו דומיין הצפנה. כל מנהרה ייחודית לזוג נתון של צמתים.
כשעובדים עם זוגות של מפתחות פרטיים או ציבוריים ומפתח סשן, כדאי לשקול את הנקודות הבאות:
זוג מפתחות פרטיים/ציבוריים:
המפתח הציבורי מופץ באשכול, וכל הצמתים באשכול יכולים לגשת אליו.
זוג המפתחות עובר רוטציה כשמפעילים מחדש את הצומת. ב-GKE, לא מתבצעת רוטציה של מפתחות במרווחי זמן קבועים. כדי להפעיל רוטציית מפתחות באופן ידני, צריך לרוקן את הצומת ולהפעיל אותו מחדש. הפעולה הזו מבטלת את התוקף של זוג המפתחות המקורי ויוצרת זוג מפתחות חדש.
מפתח סשן:
אי אפשר להגדיר את המקש הזה.
המפתח הזה מתחלף באופן מחזורי כל שתי דקות.
מפתח הסשן הוא בלעדי לצמתים שמעורבים במנהרה.
המאמרים הבאים
- מידע נוסף על Google Cloud הצפנה במצב מנוחה
- מידע נוסף על Google Cloud הצפנה של נתונים במעבר
- מידע נוסף על הצפנת סודות בשכבת האפליקציה