סקירה כללית על אבטחה

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

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

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

הצפנה ב-AWS KMS

‫GKE ב-AWS משתמש במפתחות סימטריים של AWS Key Management Service (KMS) בניהול הלקוח כדי להצפין:

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

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

הצפנת נתונים במנוחה

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

באשכולות GKE ב-AWS, הנתונים מאוחסנים בנפחי AWS Elastic Block Storage ‏ (EBS). הנפחים האלה של EBS תמיד מוצפנים במנוחה באמצעות מפתחות של AWS Key Management System ‏ (AWS KMS). כשיוצרים אשכולות ומאגרי צמתים, אפשר לספק מפתח KMS בניהול הלקוח (CMK) כדי להצפין את נפחי ה-EBS הבסיסיים. אם לא מציינים מפתח, AWS משתמשת במפתח ברירת המחדל שמנוהל על ידי AWS באזור AWS שבו האשכול פועל.

בנוסף, כל אשכולות GKE מאפשרים הצפנה של סודות בשכבת האפליקציה לנתונים רגישים, כמו אובייקטים של סודות ב-Kubernetes, שמאוחסנים ב-etcd. גם אם תוקפים יקבלו גישה לנפח הבסיסי שבו מאוחסנים נתוני etcd, הנתונים האלה מוצפנים.

כשיוצרים אשכול, צריך להעביר מפתח AWS KMS לשדה --database-encryption-kms-key-arn. המפתח הזה משמש להצפנת מעטפת של נתוני האפליקציה. בגלל שאי אפשר לשנות את השדה הזה במשאב אחרי שיוצרים את האשכול, מומלץ להשתמש בכינוי למפתח KMS. אתם יכולים להשתמש בכינויי מפתחות כדי לבצע רוטציה של המפתחות שמשמשים להצפנה במנוחה לאורך מחזור החיים של האשכול.

איך פועלת הצפנה ברמת האפליקציה

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

  1. שרת ה-API של Kubernetes יוצר מפתח DEK ייחודי ל-Secret באמצעות מחולל מספרים אקראיים.

  2. שרת ה-API של Kubernetes מצפין את ה-Secret באופן מקומי באמצעות ה-DEK.

  3. שרת ה-API של Kubernetes שולח את ה-DEK ל-AWS KMS להצפנה.

  4. ‫AWS KMS משתמש במפתח KEK שנוצר מראש כדי להצפין את מפתח ה-DEK ומחזיר את מפתח ה-DEK המוצפן לפלאגין AWS KMS של שרת Kubernetes API.

  5. שרת ה-API של Kubernetes שומר את הסוד המוצפן ואת ה-DEK המוצפן ב-etcd. מפתח ה-DEK בטקסט גלוי לא נשמר בדיסק.

  6. שרת ה-API של Kubernetes יוצר רשומה במטמון בזיכרון כדי למפות את ה-DEK המוצפן ל-DEK בטקסט לא מוצפן. כך שרת ה-API יכול לפענח סודות שנכנסו אליהם לאחרונה בלי לשלוח שאילתה ל-AWS KMS.

כשלקוח מבקש סוד משרת ה-API של Kubernetes, התהליך הוא כזה:

  1. שרת ה-API של Kubernetes מאחזר את ה-Secret המוצפן ואת ה-DEK המוצפן מ-etcd.

  2. שרת ה-API של Kubernetes בודק אם יש במטמון רשומה קיימת של מיפוי, ואם יש כזו, הוא מפענח את ה-Secret באמצעותה.

  3. אם אין רשומה תואמת במטמון, שרת ה-API שולח את מפתח ה-DEK ל-AWS KMS כדי לפענח אותו באמצעות מפתח ה-KEK. לאחר מכן, המערכת משתמשת ב-DEK המפוענח כדי לפענח את הסוד.

  4. לבסוף, שרת ה-API של Kubernetes מחזיר את הסוד המפוענח ללקוח.

רוטציית מפתחות

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

רוטציית מפתחות KMS

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

מידע נוסף זמין במאמר בנושא רוטציית מפתחות.

אמון באשכול

כל התקשורת בין הצמתים באשכול מוצפנת באמצעות פרוטוקול ההצפנה Transport Layer Security ‏ (TLS). לכל אשכול מוקצים רשויות אישורים (CA) בסיסיות בחתימה עצמית:

  • ה-CA הבסיסי של האשכול משמש לאימות בקשות שנשלחות לשרת ה-API.
  • אישור ה-CA הבסיסי של etcd משמש לאימות בקשות שנשלחות לשכפולים של etcd.

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

אבטחת הצומת

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

Ubuntu

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

באשכולות GKE מיושמות כמה תכונות אבטחה, כולל התכונות הבאות:

  • חבילת ערוצים שעברה אופטימיזציה

  • ‫Google Cloud- Linux kernel מותאם

  • חשבונות משתמשים מוגבלים והשבתה של התחברות כמשתמש על

יש מדריכי אבטחה נוספים ל-Ubuntu, כמו המדריכים הבאים:

אבטחת עומסי העבודה

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

הגבלת הרשאות של תהליכים במאגר Pod

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

  • המשתמש או הקבוצה שמריצים את התהליך
  • יכולות Linux זמינות
  • הסלמת הרשאות (privilege escalation)

מערכת ההפעלה של צומתי GKE ב-AWS, ‏ Ubuntu, משתמשת במדיניות אבטחה של Docker AppArmor כברירת מחדל לכל הקונטיינרים. אפשר לראות את תבנית הפרופיל ב-GitHub. בין היתר, הפרופיל הזה מונע מהקונטיינרים את היכולות הבאות:

  • כתיבה לקבצים ישירות בספרייה עם מזהה תהליך (/proc/)
  • כתיבה לקבצים שלא נמצאים ב-/proc/
  • כתיבה לקבצים ב-/proc/sys שאינם /proc/sys/kernel/shm*
  • הרכבת מערכות קבצים

הגבלת היכולת של עומסי עבודה לשנות את עצמם

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

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

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

parameters:
  allowedGroups: []
  allowedUsers:
  - service-PROJECT_NUMBER@gcp-sa-gkemulticloud.iam.gserviceaccount.com

מחליפים את הערך PROJECT_NUMBER במספר (ולא במזהה) של הפרויקט שמארח את האשכול.

שימוש ב-Binary Authorization

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

כך מתבצע התהליך:

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

  2. גורם מאשר (לדוגמה, מפתח או מערכת אוטומטית) משתמש באלגוריתם קריפטוגרפי כדי ליצור זוג מפתחות (מפתחות פרטיים וציבוריים).

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

  4. החתימה הדיגיטלית 'מצורפת' לתמונה. במילים אחרות, החתימה מאוחסנת במטא-נתונים של התמונה, בדרך כלל במאגר התמונות.

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

  6. כשמתקבלת בקשה לפריסת קונטיינר, מערכת Binary Authorization מאחזרת את החתימה הדיגיטלית שמצורפת לקובץ האימג' במאגר.

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

למידע נוסף על אופן הפעולה של Binary Authorization, ראו סקירה כללית על Binary Authorization.

במאמר איך מפעילים Binary Authorization מוסבר איך להפעיל את התכונה הזו באשכול קיים או כשיוצרים אשכול.

בידוד עומסי עבודה במאגרי צמתים ייעודיים

אפשר להשתמש ב-taints וב-tolerations של Kubernetes כדי להגדיר מאגרי צמתים ספציפיים להרצת סוגים ספציפיים של עומסי עבודה. לדוגמה, אתם יכולים להנחות את GKE on AWS לתזמן עומסי עבודה של משתמשים הרחק מרוב עומסי העבודה שמנוהלים על ידי המערכת, או למקם עומסי עבודה עם רמות אמון שונות במאגרי צמתים שונים.

בידוד עומסי עבודה באמצעות taints ו-tolerations לא מבטיח אבטחה. חשוב להשתמש באפשרות הזו רק לצד אמצעי האבטחה האחרים ש-GKE on AWS מציע.

מידע נוסף זמין במאמר בידוד עומסי עבודה במאגרי צמתים ייעודיים.

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