הקשחת האבטחה של האשכול

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

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

רשימת המשימות

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

רשימת משימות לפריסה תיאור
שליטה בזהויות ובהרשאות הגישה

שימוש בהרשאות של חשבון vSphere:
משתמשים בחשבון אדמין ב-vSphere עם הרשאות מינימליות.

אבטחה Google Cloud של חשבונות שירות:
מצמצמים את Google Cloud ההרשאות של חשבונות השירות.

הגדרת OpenID Connect‏ (OIDC):
הגדרת OpenID Connect לאימות משתמשים.

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

הצפנה של מכונות וירטואליות ב-vSphere:
מגדירים את vSphere להצפנת אמצעי האחסון שמשמשים את Google Distributed Cloud.

ניהול סודות:
הצפנה של סודות במצב מנוחה.
הגנה על הרשת

הגבלת הגישה לרשת לרמת הבקרה ולצמתים:
הגדרת אמצעי בקרה לבידוד ולהגנה על רשתות רמת הבקרה ועל הצמתים.

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

שימוש ב-Policy Controller:
התקנת Policy Controller למדיניות אבטחה הצהרתית באשכולות.
תחזוקה

שדרוגים:
ודאו שאתם משתמשים בגרסה העדכנית ביותר של Google Distributed Cloud.

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

הגדרת אפשרויות לרישום ביומן:
מוודאים שהרישום ביומן מופעל ומשולב בפתרון SIEM.

זהות ובקרת גישה

בקטע הזה מוסבר איך לשלוט בגישה לאשכולות.

שימוש בהרשאות בחשבון vSphere

לחשבון המשתמש ב-vCenter שבו אתם משתמשים כדי להתקין את Google Distributed Cloud צריכות להיות הרשאות מספיקות. לדוגמה, לחשבון משתמש שהוקצה לו תפקיד האדמין של vCenter יש הרשאות לגישה מלאה לכל האובייקטים של vCenter, והוא מספק לאדמין של אשכול Google Distributed Cloud גישה מלאה.

מומלץ להשתמש בהעקרון של הרשאות מינימליות, ולתת רק את ההרשאות שנדרשות להתקנה מוצלחת של {product_name}}. הגדרנו מראש את קבוצת ההרשאות המינימלית שנדרשת כדי לבצע את ההתקנה, וגם את הפקודות שנדרשות כדי להעניק את ההרשאות האלה.

אבטחת Google Cloud חשבונות שירות

‫Google Distributed Cloud דורש כמה Google Cloud חשבונות שירות. במהלך ההתקנה, אתם מקשרים תפקידים בניהול זהויות והרשאות גישה (IAM) לחשבונות השירות האלה. התפקידים האלה מעניקים לחשבונות השירות הרשאות ספציפיות בפרויקט. חלק מחשבונות השירות יכולים להיווצר עבורכם במהלך ההתקנה.

הגדרת אימות למשתמשי אשכול

כדי להגדיר אימות משתמשים באשכול, אפשר להשתמש ב-OpenID Connect‏ (OIDC) או ב-Lightweight Directory Access Protocol‏ (LDAP).

מידע נוסף זמין במאמר GKE Identity Service.

שימוש במרחבי שמות וב-RBAC ב-Kubernetes כדי להגביל את הגישה

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

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

מעבר להרשאות של Google Cloud חשבונות שירות שמשמשים להתקנת Google Distributed Cloud, ‏ IAM לא חל על אשכולות של Google Distributed Cloud.

מידע נוסף זמין במשאבי העזרה הבאים:

הגנה על נתונים

בקטע הזה מוסבר איך להגן על הנתונים.

הצפנה של מכונות וירטואליות ב-vSphere

צמתי אשכולות של Google Distributed Cloud פועלים במכונות וירטואליות (VM) באשכול vSphere. ‫Google ממליצה מאוד להצפין את כל הנתונים שבאחסון. כדי לעשות את זה ב-vSphere, פועלים לפי ההוראות בדף בנושא אבטחה ותאימות של VMware vSphere ולפי השיטות המומלצות להצפנת מכונות וירטואליות.

צריך לבצע את הפעולה הזו לפני ההתקנה של Google Distributed Cloud.

ניהול סודות

כדי לספק שכבת הגנה נוספת למידע אישי רגיש, כמו סודות של Kubernetes שמאוחסנים ב-etcd, צריך להגדיר מנהל סודות שמשולב עם אשכולות של Google Distributed Cloud.

אם אתם מריצים עומסי עבודה בכמה סביבות, יכול להיות שתעדיפו פתרון שמתאים גם ל-Google Kubernetes Engine וגם ל-Google Distributed Cloud. אם אתם בוחרים להשתמש במנהל סודות חיצוני, כמו HashiCorp Vault, אתם צריכים להגדיר אותו לפני שאתם משלבים את האשכולות של Google Distributed Cloud.

יש כמה אפשרויות לניהול סודות:

  • אפשר להשתמש ב-Kubernetes Secrets באופן מקורי ב-Google Distributed Cloud. אנחנו מצפים שהאשכולות ישתמשו בהצפנה של vSphere למכונות וירטואליות, כפי שמתואר קודם, שמספקת הגנה בסיסית על סודות בהצפנה במנוחה. כברירת מחדל, הסודות לא מוצפנים יותר.
  • אפשר להשתמש במנהל סודות חיצוני, כמו HashiCorp Vault. אפשר לבצע אימות ב-HashiCorp באמצעות חשבון שירות ב-Kubernetes או באמצעות Google Cloud חשבון שירות.

הגנה על הרשת

בקטע הזה מופיע מידע על הגנה על הרשת.

הגבלת הגישה לרשת למישור הבקרה ולצמתים

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

שימוש במדיניות רשת כדי להגביל את התנועה

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

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

  • כדי לשלוט בתנועה בשכבה 7 לנקודות הקצה של האפליקציות, משתמשים ב-Istio. אפשרות זו מתאימה אם אתם מעוניינים באיזון עומסים, בהרשאת שירות, בהגבלת קצב, במכסה ובמדדים.
  • כדי לשלוט בתעבורת נתונים ברמה 4 בין קבוצות Pod, משתמשים בכללי מדיניות של רשת ב-Kubernetes. האפשרות הזו מתאימה אם אתם מחפשים את היכולות הבסיסיות של בקרת הגישה שמנוהלות על ידי Kubernetes.

אחרי שיוצרים את האשכולות של Google Distributed Cloud, אפשר להפעיל גם את Istio וגם את מדיניות הרשת של Kubernetes. אפשר להשתמש בהם ביחד אם צריך.

מידע נוסף זמין במשאבי העזרה הבאים:

אבטחה הצהרתית

בקטע הזה מפורטות המלצות לאבטחת האשכולות.

שימוש ב-Policy Controller

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

השיטה המומלצת היא להשתמש ב-Policy Controller. Policy Controller משתמש ב-OPA Constraint Framework כדי לתאר ולאכוף מדיניות בתור CRD. האילוצים שאתם מחילים על האשכול מוגדרים בתבניות אילוצים, שנפרסות באשכולות שלכם.

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

מידע נוסף זמין במשאבי העזרה הבאים:

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

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

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

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

parameters:
  allowedGroups:
  - system:masters
  allowedUsers:
  - system:serviceaccount:kube-system:monitoring-operator
  - system:serviceaccount:kube-system:stackdriver-operator
  - system:serviceaccount:kube-system:metrics-server-operator
  - system:serviceaccount:kube-system:logmon-operator

תחזוקה

בקטע הזה מוסבר איך לתחזק את האשכולות.

שדרוג של Google Distributed Cloud

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

אתם אחראים לעדכן את האשכולות של Google Distributed Cloud. בכל גרסה, כדאי לעיין בנתוני הגרסה. בנוסף, מומלץ להתעדכן בתיקוני אבטחה חדשים מדי חודש ובגרסאות משניות מדי שלושה חודשים. איך משדרגים את האשכולות

אתם גם אחראים לשדרוג ולאבטחה של תשתית vSphere:

מעקב אחרי עדכוני אבטחה דחופים

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

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

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

מידע נוסף זמין במשאבי העזרה הבאים:

מעקב ורישום ביומן

‫Google Distributed Cloud כולל כמה אפשרויות לרישום ביומן ולמעקב אחר אשכולות, כולל שירותים מנוהלים מבוססי-ענן, כלים בקוד פתוח ותאימות מאומתת לפתרונות מסחריים של צד שלישי:

  • ‫Cloud Logging ו-Cloud Monitoring, שמופעלים על ידי סוכנים בתוך האשכול שפריסתם באמצעות Google Distributed Cloud
  • הגדרות שאומתו באמצעות פתרונות של צד שלישי

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

מידע נוסף זמין במשאבי העזרה הבאים: