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

בגלל קצב הפיתוח המהיר ב-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 7 וההנחיות לשיטות מומלצות בנושא הצפנת מכונות וירטואליות.

צריך לבצע את הפעולה הזו לפני ההתקנה של 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 יכולים לתקשר ביניהם. בקטעים הבאים מוסבר איך לשלוט בתקשורת בין שירותים לפי הצורך בעומסי העבודה שלכם.

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

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

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

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

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

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

שימוש ב-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), כדי לנהל אירועי אבטחה.

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