הסבר על אבטחת רשת ב-GKE

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

ב-Google Kubernetes Engine‏ (GKE), החלת העיקרון של הרשאות מינימליות על תעבורת הרשת פירושה הגבלת התקשורת רק למה שנדרש כדי שהאפליקציות יפעלו. כברירת מחדל, הרשת בתוך אשכול GKE פתוחה, כלומר כל Pod יכול לתקשר עם כל Pod אחר.

‫GKE תומך עכשיו בגישה היררכית לאבטחת רשת באמצעות ClusterNetworkPolicy לאכיפה ברמת האדמין בכל מרחבי השמות.

במסמך הזה מוסבר מה מפעילים, מומחי רשת ומומחי אבטחה צריכים להבין וליישם כדי לאבטח את הרשת באשכולות GKE. מידע נוסף על תפקידים נפוצים ומשימות לדוגמה ב- Cloud de Confiance by S3NSזמין במאמר תפקידים נפוצים של משתמשי GKE ומשימות.

לפני שקוראים את המסמך הזה, חשוב לוודא שאתם מכירים את הנושאים הבאים:

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

המטרות של אבטחת הרשת ב-GKE

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

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

בחירת מדיניות אבטחת רשת

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

סוגי תנועה

כדי לבחור את המדיניות הנכונה, צריך להביא בחשבון את המקור והיעד של התנועה שרוצים לנהל:

  • תקשורת בין Pods בתוך האשכול: כדי לשלוט באופן שבו מיקרו-שירותים מתקשרים זה עם זה, משתמשים במדיניות שפועלת על תוויות ומרחבי שמות של Pods.

    • מפתחי אפליקציות יכולים להשתמש ב-NetworkPolicy הרגיל של Kubernetes כדי להגדיר כללי כניסה ויציאה לאפליקציה במרחב השמות שלה.
    • כאדמינים של אשכולות, אתם יכולים להשתמש ב-ClusterNetworkPolicy הרגיל של Kubernetes כדי לאכוף אמצעי הגנה מחייבים (רמה Admin) או להגדיר ברירות מחדל של אפס אמון (רמה Baseline) בכל מרחבי השמות. המשאב הזה נתמך באשכולות שפועלת בהם גרסה 1.36.1-gke.1067000 של GKE ואילך.
    • אדמינים של אשכולות יכולים להשתמש ב-CiliumClusterwideNetworkPolicy הקנייני כדי לשלוט בתעבורת נתונים באשכול באופן מיוחד. בהטמעות חדשות, צריך להשתמש ב-ClusterNetworkPolicy שמותאם ל-Kubernetes במקום במדיניות הקניינית הזו.

  • תעבורת נתונים יוצאת מ-Pods לשירותים חיצוניים: כדי לשלוט בתעבורת נתונים יוצאת מ-Pods לשירותים חיצוניים על סמך שמות דומיין, משתמשים ב-FQDNNetworkPolicy. המדיניות הזו שימושית כשכתובות ה-IP של שירותים חיצוניים הן לא סטטיות, כי היא פותרת ומתעדכנת אוטומטית את כתובות ה-IP המותרות על סמך DNS.

  • הצפנה של כל התעבורה בין שירותים: כדי לוודא שכל התקשורת בין השירותים מוצפנת ומאומתת, צריך להשתמש ברשת שירותים. שימוש ב-Istio או ב-Anthos Cloud Service Mesh להטמעה של TLS הדדי (mTLS), שמטפל בהצפנה באופן אוטומטי.

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

מערכת GKE מעריכה את כללי מדיניות אבטחת הרשת בשלוש רמות היררכיות.

  1. רמת האדמין (ClusterNetworkPolicy): רמת העדיפות הגבוהה ביותר. אפשר להשתמש ברמה הזו כדי לאכוף חובות אבטחה. כללי דחייה ברמה הזו מבטלים את כל שאר כללי המדיניות. כללי Accept מאפשרים תנועה ומפסיקים את ההערכה של המנה הזו.
  2. רמת NetworkPolicy: הרמה שבה מפתחים מגדירים אבטחה ספציפית לאפליקציה. המדיניות כוללת את המשאבים הרגילים NetworkPolicy, FQDNNetworkPolicy ו-CiliumClusterwideNetworkPolicy.
  3. רמת הבסיס (ClusterNetworkPolicy): רמת העדיפות הנמוכה ביותר. משתמשים במסלול הזה כדי להגדיר אמצעי הגנה שמוגדרים כברירת מחדל כ'דחייה כברירת מחדל', ומפתחים יכולים לבטל אותם באופן סלקטיבי במסלול NetworkPolicy.

אם אין התאמה למדיניות באף רמה, ברירת המחדל של GKE היא התנהגות משתמעת של 'התרת הכול'.

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

בטבלה הבאה מפורטות המדיניות שבהן כדאי להשתמש בהתאם ליעד האבטחה.

יעד מדיניות מומלצת
שליטה בתנועה בין Pods באמצעות תוויות ומרחבי שמות. ‫Kubernetes NetworkPolicy
שליטה בתעבורת נתונים יוצאת לשירותים חיצוניים לפי שם הדומיין. FQDNNetworkPolicy
הצפנה ואימות של כל התנועה בין שירותים. ‫Istio או Anthos Cloud Service Mesh (ל-mTLS)
אכיפה של אמצעי בקרה מחייבים בנושא אבטחה שלא ניתן לעקוף. ‫ClusterNetworkPolicy (רמת אדמין)
הגדרת אמצעי הגנה שמוגדרים כברירת מחדל כ'אפס אמון' ומפתחים יכולים לבטל אותם. ‫ClusterNetworkPolicy (רמת הבסיס)
הגדרת כללי מדיניות קנייניים ברמת האשכול (לא מומלץ לפריסות חדשות). CiliumClusterwideNetworkPolicy
ביצוע ביקורת על חיבורים שהמדיניות מאפשרת או דוחה, ותיעוד שלהם ביומן. רישום ביומן של מדיניות הרשת (מופעל לכל מדיניות)

ביקורת של מדיניות הרשת ופתרון בעיות

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

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

בניגוד למדיניות רגילה שהיא "הרשאה בלבד", משאבי ClusterNetworkPolicy תומכים בפעולות דחייה מפורשות. אם מדיניות ניהולית מפילה תנועה, רשומת היומן משייכת את הדחייה למדיניות הספציפית שאחראית לחסימה.

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