במאמר הזה מוסברים מושגי ליבה בנושא אבטחת רשת ב-GKE, כמו העיקרון של הרשאות מינימליות, והוא עוזר לכם לבחור את הכלים הנכונים לאבטחת האשכול. המטרות העיקריות של הטמעת אבטחת רשת ב-GKE הן בידוד עומסי עבודה וריבוי דיירים מאובטח. כדי להשיג את המטרות האלה, כדאי להחיל את העקרונות של הרשאות מינימליות והגנה מעמיקה, ולהשתמש בנתונים מעשיים כדי לקבל החלטות מושכלות בנושאי אבטחה.
ב-Google Kubernetes Engine (GKE), יישום העיקרון של הרשאות מינימליות על תעבורת הרשת פירושו הגבלת התקשורת רק למה שנדרש כדי שהאפליקציות יפעלו. כברירת מחדל, הרשת בתוך אשכול GKE פתוחה, כלומר כל Pod יכול לתקשר עם כל Pod אחר.
המסמך הזה עוזר למפעילים, למומחי רשת ולמומחי אבטחה להבין וליישם אבטחת רשת באשכולות GKE. מידע נוסף על תפקידים נפוצים ודוגמאות למשימות ב- Google Cloudזמין במאמר תפקידים נפוצים של משתמשים ב-GKE ומשימות.
לפני שקוראים את המסמך הזה, חשוב לוודא שאתם מכירים את הנושאים הבאים:
- מושגים של רשתות GKE: סקירה כללית זמינה במאמר מידע על רשתות GKE.
- קבוצות Pod, שירותים ומרחבי שמות ב-Kubernetes: משאבי Kubernetes הבסיסיים האלה הם מרכזיים להגדרת כללי מדיניות של אבטחת רשת. לעיון במסמכי התיעוד של Kubernetes
- העיקרון של הרשאות מינימליות: עיקרון האבטחה הזה הוא מושג מרכזי שמופיע לאורך המסמך.
המטרות של אבטחת הרשת ב-GKE
כללי מדיניות של אבטחת רשת ב-GKE מספקים בקרת תעבורה פרטנית שמודעת ל-Kubernetes בתוך האשכול. כללי המדיניות האלה הם מרכיב חשוב באסטרטגיית האבטחה הכוללת שלכם. כדי להטמיע אבטחת רשת חזקה, כדאי להביא בחשבון את העקרונות הבסיסיים הבאים:
- הרשאות מינימליות: צריך להעניק למערכות ולשירותים רק את ההרשאות המינימליות שנדרשות לביצוע הפונקציות שלהם. העיקרון הזה מצמצם את ההשפעה הפוטנציאלית של פגיעה באבטחה. כללי מדיניות של רשת Kubernetes עוזרים לכם לעבור מרשת פתוחה כברירת מחדל לרשת שבה מותרים רק חיבורים נדרשים.
- הגנה לעומק: שימוש בכמה אמצעי בקרה עצמאיים לאבטחה. כשל באמצעי בקרה אחד לא מוביל לפגיעה כוללת במערכת. לדוגמה, אתם משתמשים במדיניות רשת כדי לבודד מסד נתונים, גם אם מסד הנתונים עצמו דורש אימות.
- נתונים שאפשר לפעול לפיהם: קבלת החלטות בנושא אבטחה על סמך נתונים. מודלים של איומים והערכת סיכונים עוזרים לכם להבין את מצב האבטחה שלכם. תכונות כמו רישום ביומן של מדיניות הרשת מספקות את הנתונים לאימות המדיניות ולאיתור פרצות פוטנציאליות.
בחירת מדיניות אבטחת רשת
כדי לבחור את המדיניות הנכונה, צריך לזהות את הסוג וההיקף של התנועה שרוצים לשלוט בה.
סוגי תנועה
כדי לבחור את המדיניות הנכונה, צריך לקחת בחשבון את המקור והיעד של התנועה שרוצים לנהל:
תקשורת בין Pods בתוך האשכול: כדי לשלוט באופן שבו מיקרו-שירותים מתקשרים זה עם זה, משתמשים במדיניות שפועלת על תוויות ומרחבי שמות של Pods.
- מפתחי אפליקציות יכולים להשתמש ב-Kubernetes
NetworkPolicyכדי להגדיר כללי תעבורת נתונים נכנסת (ingress) ותעבורת נתונים יוצאת (egress) לאפליקציה במרחב השמות שלה. - כאדמינים של אשכולות, אתם יכולים להשתמש ב-
CiliumClusterwideNetworkPolicyכדי לאכוף אמצעי הגנה שחלים על כל האשכול. לכללי הדחייה ב-NetworkPolicyיש עדיפות על פני כללי ההרשאה ב-CiliumClusterwideNetworkPolicy.
- מפתחי אפליקציות יכולים להשתמש ב-Kubernetes
תנועת יציאה מ-Pods לשירותים חיצוניים: כדי לשלוט בתנועת היציאה מ-Pods לשירותים חיצוניים על סמך שמות דומיין, משתמשים ב-
FQDNNetworkPolicy. המדיניות הזו שימושית כשכתובות ה-IP של שירותים חיצוניים הן לא סטטיות, כי היא פותרת ומתעדכנת אוטומטית לגבי כתובות ה-IP המותרות על סמך DNS.הצפנה של כל התעבורה בין שירותים: כדי לוודא שכל התקשורת בין השירותים מוצפנת ומאומתת, כדאי להשתמש ברשת שירותים. שימוש ב-Istio או ב-Anthos Cloud Service Mesh להטמעה של TLS דו-צדדי (mTLS), שמטפל בהצפנה באופן אוטומטי.
סיכום של אפשרויות המדיניות
בטבלה הבאה מפורטות המדיניות שבהן כדאי להשתמש בהתאם ליעד האבטחה.
| מטרה | מדיניות מומלצת |
|---|---|
| שליטה בתנועה בין Pods באמצעות תוויות ומרחבי שמות. | Kubernetes NetworkPolicy |
| שליטה בתעבורת נתונים יוצאת לשירותים חיצוניים לפי שם הדומיין. | FQDNNetworkPolicy |
| הצפנה ואימות של כל התנועה בין שירותים. | Istio או Anthos Cloud Service Mesh (ל-mTLS) |
| אדמינים יכולים לאכוף כללים מחייבים ברמת האשכול. | CiliumClusterwideNetworkPolicy |
| ביצוע ביקורת על חיבורים שהמדיניות מאפשרת או אוסרת, ותיעוד שלהם ביומן. | רישום ביומן של מדיניות הרשת (מופעל לכל מדיניות) |
ביקורת ומציאת פתרונות לבעיות במדיניות הרשת
אחרי שמטמיעים מדיניות רשת, חשוב לוודא שהיא פועלת כמצופה ולאבחן בעיות בקישוריות. אפשר להשתמש ברישום ביומן של מדיניות הרשת ככלי העיקרי לכך.
כשמפעילים את רישום היומנים של מדיניות הרשת, GKE יוצר רשומה ביומן ב-Cloud Logging לכל חיבור שמדיניות הרשת מאשרת או דוחה. היומנים האלה חיוניים לביצוע ביקורת אבטחה ולפתרון בעיות בהתנהגות לא צפויה. בדיקת היומנים האלה מאפשרת לראות את ההשפעות הקונקרטיות של הכללים, ולוודא שהתנועה הלגיטימית זורמת כמצופה ושהתנועה הלא מורשית נחסמת.
המאמרים הבאים
- איך מגדירים Kubernetes
NetworkPolicy - איך שולטים בתנועת היציאה באמצעות
FQDNNetworkPolicy - איך מגדירים את
CiliumClusterwideNetworkPolicyלכללים ברמת האשכול - איך מפעילים רישום ביומן של מדיניות הרשת כדי לבדוק את הכללים.