סקירה כללית על אבטחה
בדף הזה מתוארת ארכיטקטורת האבטחה של GKE ב-Azure, כולל הצפנה והגדרת צמתים.
אשכולות GKE מציעים תכונות שיעזרו לכם לאבטח את עומסי העבודה, כולל התוכן של קובץ אימג' של קונטיינר, זמן הריצה של הקונטיינר, רשת האשכולות והגישה לשרת ה-API של האשכול.
כשמשתמשים באשכולות GKE, מסכימים לקחת על עצמכם אחריות מסוימת על האשכולות. מידע נוסף זמין במאמר חלוקת אחריות באשכולות GKE.
הצפנת נתונים במנוחה
הצפנת נתונים במנוחה היא הצפנה של נתונים מאוחסנים, בניגוד לנתונים בזמן ההעברה. כברירת מחדל, נתונים ב-etcd ובנפחי אחסון במצב מנוחה מוצפנים ב-GKE ב-Azure באמצעות מפתחות שמנוהלים על ידי פלטפורמת Azure.
נתונים באשכולות GKE ב-Azure מאוחסנים בנפחי Azure Disk. הנפחים האלה תמיד מוצפנים במצב מנוחה באמצעות מפתחות Azure Key Vault. כשיוצרים אשכולות ומאגרי צמתים, אפשר לספק מפתח של Customer-Managed Keyvault כדי להצפין את נפחי הדיסק הבסיסיים של האשכול. אם לא מציינים מפתח, Azure משתמש במפתח ברירת המחדל שמנוהל על ידי Azure באזור Azure שבו האשכול פועל.
בנוסף, כל אשכולות GKE מאפשרים הצפנה של סודות בשכבת האפליקציה לנתונים רגישים, כמו אובייקטים של סודות ב-Kubernetes, שמאוחסנים ב-etcd. גם אם תוקפים יקבלו גישה לנפח הבסיסי שבו מאוחסנים נתוני etcd, הנתונים האלה מוצפנים.
כשיוצרים אשכול, אפשר לספק מפתח של Azure Key Vault בפרמטר--database-encryption-kms-key-arn. המפתח הזה משמש להצפנה של הנתונים באפליקציה.
אם לא מספקים מפתח במהלך יצירת האשכול, GKE ב-Azure יוצר מפתח לאשכול באופן אוטומטי. אי אפשר לשנות את השדה הזה במשאב אחרי שיוצרים את האשכול.
אפשר גם ליצור מפתח Key Vault באופן ידני או להשתמש במפתח משלכם (BYOK) עם מודול אבטחת חומרה (HSM). מידע נוסף מופיע במאמר בנושא שימוש במפתח הצפנה משלכם.
איך פועלת הצפנה ברמת האפליקציה
Kubernetes מציעה הצפנה ברמת האפליקציה בטכניקה שנקראת הצפנת מעטפה. מפתח מקומי, שנקרא בדרך כלל מפתח להצפנת נתונים (DEK), משמש להצפנה של Secret. לאחר מכן, מפתח ה-DEK עצמו מוצפן באמצעות מפתח שני שנקרא מפתח להצפנת מפתחות הצפנה (KEK). מפתח ה-KEK לא מאוחסן על ידי Kubernetes. כשיוצרים סוד חדש של Kubernetes, האשכול מבצע את הפעולות הבאות:
שרת ה-API של Kubernetes יוצר מפתח DEK ייחודי ל-Secret באמצעות מחולל מספרים אקראיים.
שרת ה-API של Kubernetes מצפין את ה-Secret באופן מקומי באמצעות ה-DEK.
שרת ה-API של Kubernetes שולח את ה-DEK ל-Azure Key Vault להצפנה.
Azure Key Vault משתמש במפתח KEK שנוצר מראש כדי להצפין את ה-DEK ומחזיר את ה-DEK המוצפן לתוסף Azure Key Vault של שרת Kubernetes API.
שרת ה-API של Kubernetes שומר את הסוד המוצפן ואת ה-DEK המוצפן ב-etcd. מפתח ה-DEK בטקסט גלוי לא נשמר בדיסק.
שרת ה-API של Kubernetes יוצר רשומה במטמון בזיכרון כדי למפות את ה-DEK המוצפן ל-DEK בטקסט לא מוצפן. כך שרת ה-API יכול לפענח סודות שהייתה אליהם גישה לאחרונה בלי לשלוח שאילתה ל-Azure Key Vault.
כשלקוח מבקש סוד משרת ה-API של Kubernetes, התהליך הוא כזה:
שרת ה-API של Kubernetes מאחזר את ה-Secret המוצפן ואת ה-DEK המוצפן מ-etcd.
שרת ה-API של Kubernetes בודק אם יש במטמון רשומה קיימת של מיפוי, ואם יש כזו, הוא מפענח את ה-Secret באמצעותה.
אם אין רשומה תואמת במטמון, שרת ה-API שולח את ה-DEK אל Azure Key Vault כדי לפענח אותו באמצעות ה-KEK. לאחר מכן, המערכת משתמשת ב-DEK המפוענח כדי לפענח את הסוד.
לבסוף, שרת ה-API של Kubernetes מחזיר את הסוד המפוענח ללקוח.
הגדרת הצפנה באמצעות חומת האש של Key Vault
אם מעבירים מפתח ציבורי להצפנה, לחשבון המשתמש של השירות לא נדרשת הרשאה להצפנה, אבל כן נדרשת הרשאה לניהול הקצאות של תפקידים. הדרך הכי פשוטה לעשות את זה היא להקצות את התפקיד המובנה User Access Administrator של Azure למנהל השירות.
כדי לאבטח עוד יותר את Azure Key Vault, אפשר להפעיל את חומת האש של Azure Key Vault. לאחר מכן, GKE ב-Azure יכול להשתמש במפתח ציבורי להצפנה ולמנוע גישה לרשת לכספת המפתחות.
כדי להגדיר את חומת האש, צריך להוריד את המפתח של Key Vault באמצעות Azure CLI.
מעבירים את המפתח אל --config-encryption-public-key כשיוצרים אשכול באמצעות Google Cloud CLI.
עדיין צריך להפעיל נקודות קצה של שירותים עבור Key Vault בכל רשתות המשנה שמשמשות את האשכול. מידע נוסף זמין במאמר בנושא נקודות קצה של שירות רשת וירטואלית עבור Azure Key Vault.
רוטציית מפתחות
בניגוד לרוטציה של אישורים, רוטציית מפתחות היא פעולה של שינוי החומר הקריפטוגרפי הבסיסי שכלול במפתח להצפנת מפתחות הצפנה (KEK). היא יכולה להיות מופעלת אוטומטית כחלק מרוטציה מתוזמנת, או באופן ידני, בדרך כלל אחרי אירוע אבטחה שבו המפתחות עלולים להיפרץ. רוטציה של מפתחות מחליפה רק את השדה היחיד במפתח שמכיל את נתוני המפתח הגולמיים להצפנה/לפענוח.
מידע נוסף זמין במאמר בנושא רוטציית מפתחות.
אמון באשכול
כל התקשורת בין הצמתים באשכול מוצפנת באמצעות פרוטוקול ההצפנה Transport Layer Security (TLS). לכל אשכול מוקצים רשויות אישורים (CA) בסיסיות בחתימה עצמית:
- ה-CA הבסיסי של האשכול משמש לאימות בקשות שנשלחות לשרת ה-API.
- אישור ה-CA הבסיסי של etcd משמש לאימות בקשות שנשלחות לשכפולים של etcd.
לכל אשכול יש רשות אישורים (CA) בסיסית ייחודית. אם רשות אישורים של אשכול אחד נפגעת, היא לא משפיעה על רשות אישורים של אשכול אחר. לכל רשויות האישורים הבסיסיות יש תקופת תוקף של 30 שנה.
אבטחת הצומת
GKE ב-Azure פורס את עומסי העבודה (workloads) שלכם במאגרי צמתים של מכונות וירטואליות ב-Azure. בקטע הבא מוסבר על תכונות האבטחה של הצמתים.
Ubuntu
הצמתים מריצים גרסה אופטימלית של מערכת ההפעלה Ubuntu כדי להריץ את מישור הבקרה והצמתים של Kubernetes. מידע נוסף זמין במאמר תכונות אבטחה במסמכי העזרה של Ubuntu.
באשכולות GKE מיושמות כמה תכונות אבטחה, כולל התכונות הבאות:
חבילת ערוצים שעברה אופטימיזציה
Google Cloud- Linux kernel מותאם
חשבונות משתמשים מוגבלים והשבתה של התחברות כמשתמש על
יש מדריכי אבטחה נוספים ל-Ubuntu, כמו המדריכים הבאים:
אבטחת עומסי העבודה
Kubernetes מאפשר למשתמשים להקצות, לשנות את גודלן ולעדכן במהירות עומסי עבודה מבוססי-קונטיינרים. בקטע הזה מתוארות טקטיקות שבהן אפשר להשתמש כדי להגביל את תופעות הלוואי של הפעלת קונטיינרים באשכולות וב Google Cloud שירותים.
הגבלת הרשאות של תהליכים במאגר Pod
הגבלת ההרשאות של תהליכים מבוססי-קונטיינר חשובה לאבטחת האשכול. אפשר להגדיר אפשרויות שקשורות לאבטחה באמצעות הקשר אבטחה. ההגדרות האלה מאפשרות לכם לשנות את הגדרות האבטחה של התהליכים שלכם, למשל:
- המשתמש או הקבוצה שמריצים את התהליך
- יכולות Linux זמינות
- הסלמת הרשאות (privilege escalation)
מערכת ההפעלה של הצומת ב-GKE on Azure, Ubuntu, משתמשת במדיניות אבטחה של Docker AppArmor כברירת מחדל לכל הקונטיינרים. אפשר לראות את תבנית הפרופיל ב-GitHub. בין היתר, הפרופיל הזה מונע מהקונטיינרים את היכולות הבאות:
- כתיבה לקבצים ישירות בספרייה עם מזהה תהליך (
/proc/) - כתיבה לקבצים שלא נמצאים ב-
/proc/ - כתיבה לקבצים ב-
/proc/sysשאינם/proc/sys/kernel/shm* - הרכבת מערכות קבצים
הגבלת היכולת של עומסי עבודה לשנות את עצמם
לעומסי עבודה מסוימים של Kubernetes, במיוחד לעומסי עבודה של המערכת, יש הרשאה לבצע שינויים בעצמם. לדוגמה, חלק מעומסי העבודה מבצעים שינוי גודל אוטומטי אנכי בעצמם. הגישה הזו נוחה, אבל היא מאפשרת לתוקף שכבר פרץ לצומת להשיג הרשאות גבוהות יותר באשכול. לדוגמה, יכול להיות שלתוקף יש עומס עבודה בצומת, והוא יכול לשנות אותו כך שיפעל כחשבון שירות עם יותר הרשאות שקיים באותו מרחב שמות.
הכי טוב לא לתת לעומסי עבודה הרשאה לשנות את עצמם מלכתחילה. אם יש צורך בשינוי עצמי, אפשר להגביל את ההרשאות באמצעות התקנה של Policy Controller או של Gatekeeper באשכול והחלת אילוצים, כמו NoUpdateServiceAccount מספריית Gatekeeper של קוד פתוח, שמספקת כמה כללי מדיניות שימושיים בנושא אבטחה.
כשפורסים מדיניות, בדרך כלל צריך לאפשר לבקרים שמנהלים את מחזור החיים של האשכול לעקוף את המדיניות. הפעולה הזו נדרשת כדי שהבקרה תוכל לבצע שינויים באשכול, כמו שדרוג האשכול. לדוגמה, אם פורסים את מדיניות NoUpdateServiceAccount ב-GKE ב-Azure, צריך להגדיר את הפרמטרים הבאים ב-Constraint:
parameters:
allowedGroups: []
allowedUsers:
- service-PROJECT_NUMBER@gcp-sa-gkemulticloud.iam.gserviceaccount.com
מחליפים את הערך PROJECT_NUMBER במספר (ולא במזהה) של הפרויקט שמארח את האשכול.
בידוד עומסי עבודה במאגרי צמתים ייעודיים
אפשר להשתמש ב-taints וב-tolerations של Kubernetes כדי להגדיר מאגרי צמתים ספציפיים להרצת סוגים ספציפיים של עומסי עבודה. לדוגמה, אתם יכולים להנחות את GKE on Azure לתזמן עומסי עבודה של משתמשים הרחק מרוב עומסי העבודה שמנוהלים על ידי המערכת, או למקם עומסי עבודה עם רמות אמון שונות במאגרי צמתים שונים.
בידוד עומסי עבודה באמצעות taints ו-tolerations לא מבטיח אבטחה. חשוב להשתמש בפתרון הזה רק לצד אמצעי האבטחה האחרים ש-GKE ב-Azure מציע.
מידע נוסף זמין במאמר בידוד עומסי עבודה במאגרי צמתים ייעודיים.