שיטות מומלצות לשימוש בשערי יציאה (egress) של Cloud Service Mesh באשכולות GKE

במאמר הזה מוסבר איך להשתמש בשערי יציאה (egress) של Cloud Service Mesh ובאמצעי בקרה אחרים של Google Cloud כדי לאבטח תנועה יוצאת (egress) מעומסי עבודה שנפרסו באשכול Google Kubernetes Engine‏ (GKE). אמצעי הבקרה האלה יכולים להגביל את החיבורים לשירותים חיצוניים על סמך הזהות של אפליקציית המקור, מרחב השמות של הצוות, דומיין היעד ומאפיינים אחרים של הבקשות היוצאות.

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

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

מבוא

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

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

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

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

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

‫Cloud Service Mesh הוא הפצה של רשת שירותים בקוד פתוח Istio שנתמכת באופן מלא על ידי Google. ‫Service mesh מספק דרך אחידה להתחבר, לנהל ולאבטח את התקשורת בין האפליקציות. רשתות שירות משתמשות בגישה ממוקדת-אפליקציה ובזהויות אפליקציה מהימנות, במקום בגישה ממוקדת-כתובת IP ברשת.

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

‫Cloud Service Mesh מספק אפשרות לפריסת שרתי proxy עצמאיים להעברת נתונים,שנקראים שערים ליציאת נתונים, בקצה של הרשת. במדריך הזה מוסבר איך אפשר לשלב בין התכונות של שרת ה-proxy של שער היציאה לבין התכונות של Google Cloud כדי לשלוט בתעבורה היוצאת מעומסי עבודה שנפרסו באשכול GKE, לאשר אותה ולעקוב אחריה.

רכיבים מושגיים

ארכיטקטורה של הגנה לעומק

בתרשים הבא מוצגת ארכיטקטורה שמתבססת על גישת הגנה לעומק כדי לשלוט בתעבורת הנתונים היוצאת (egress) של אשכול שמשמש כמה צוותים. הבקרות מבוססות על בקרות רשת של שכבה 4 (תעבורה) ושל שכבה 7 (אפליקציה).

ארכיטקטורה כללית

הארכיטקטורה משתמשת במשאבים ובאמצעי הבקרה הבאים:

  • אשכול GKE פרטי: לצמתים באשכול GKE פרטי יש רק כתובות IP פנימיות, והם לא מחוברים לאינטרנט כברירת מחדל.

  • ‫Cloud NAT: ‏ Cloud NAT מאפשר גישה לאינטרנט מחוץ לאשכול הפרטי.

  • כללי חומת אש של ענן וירטואלי פרטי (VPC): אתם מגדירים כללי חומת אש של VPC כדי להחיל אמצעי בקרה בשכבה 4 (תעבורה) על חיבורים אל הצמתים באשכול GKE וממנו. אפשר להחיל כללי חומת אש של VPC על מכונות וירטואליות על סמך חשבונות שירות או תגי רשת.

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

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

  • ‫Kubernetes network policies: כללי מדיניות של רשת מאפשרים להחיל אמצעי בקרה ברמה 4 על קבוצות Pod. כל מדיניות רשת מוגבלת למרחב שמות, ואפשר להגביל אותה עוד יותר לתרמילים מסוימים במרחב שמות.

  • שער יציאה: תנועת נתונים שיוצאת מ-Pods בתוך הרשת מנותבת דרך שרתי proxy ייעודיים של שער יציאה שפועלים בצמתים ייעודיים. אתם פורסים שערים ליציאת נתונים עם Horizontal Pod Autoscaler כדי שמספר הרפליקות יגדל או יקטן בהתאם לתעבורה.

  • מדיניות הרשאות: משתמשים במדיניות הרשאות של רשת כדי להחיל אמצעי בקרה בשכבה 7 (אפליקציה) על תעבורה בין Pods ברשת ועל תעבורה שיוצאת מהרשת.

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

  • גישה פרטית ל-Google: האפשרות הזו מאפשרת לצמתים ול-Pods באשכול הפרטי לגשת ל-Google APIs ולמשוך קובצי אימג' של Docker מ-Container Registry.

  • ‫GKE Workload Identity: באמצעות Workload Identity, אתם יכולים להשתמש בניהול זהויות והרשאות גישה (IAM) כדי להעניק הרשאות API לעומסי עבודה ספציפיים בהתאם לעיקרון של הרשאות מינימליות, בלי שתצטרכו לטפל בסודות.

הגדרת אמצעי בקרה לתעבורת נתונים יוצאת (egress)

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

שימוש ב-GKE פרטי עם Cloud NAT

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

יכול להיות שחלק מעומסי העבודה יצטרכו גישה לשירותים מחוץ לרשת ה-VPC ולאינטרנט. כדי לאפשר לעומסי עבודה להתחבר למארחים חיצוניים בלי שיהיו להם כתובות IP ציבוריות, צריך להגדיר Cloud NAT כדי לספק תרגום כתובות רשת (NAT).

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

הגדרת גישה פרטית ל-Google עבור Google APIs ושירותים של Google

סביר להניח שעומסי העבודה שלכם צריכים גישה לשירותים ולממשקי API של Google. להשתמש בגישה פרטית ל-Google עם אזורי DNS בהתאמה אישית כדי לאפשר קישוריות מרשתות משנה פרטיות של VPC לממשקי API של Google באמצעות קבוצה של ארבע כתובות IP. כשמשתמשים בכתובות ה-IP האלה, אין צורך שלפודים יהיו כתובות IP חיצוניות, והתנועה אף פעם לא יוצאת מרשת Google. אפשר להשתמש ב-private.googleapis.com (199.36.153.8/30) או ב-restricted.googleapis.com (199.36.153.4/30), בהתאם לשימוש ב-VPC Service Controls.

שימוש ב-Workload Identity וב-IAM כדי לאבטח עוד יותר את Google APIs והשירותים של Google

הדרך המומלצת לאפשר לעומסי עבודה ב-GKE לעבור אימות ב-Google APIs ולאפשר לאדמינים להחיל אמצעי בקרה של הרשאות מינימליות באמצעות IAM היא באמצעות Workload Identity.

כשמשתמשים בגישה פרטית ל-Google, ב-Workload Identity וב-IAM, אפשר לאפשר לקבוצות Pod של עומסי עבודה לעקוף את שער היציאה ולהתחבר ישירות ל-Google APIs ולשירותים של Google.

שימוש במרחבי שמות של Kubernetes לצורך בקרה אדמיניסטרטיבית

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

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

‫Cloud Service Mesh מבוסס על מרחבי שמות ב-Kubernetes, ומשתמש בהם כיחידת דיירות בתוך Service mesh. אפשר להגביל את הגישה והחשיפה באמצעות כללי מדיניות של הרשאות גישה לרשת ומשאבי sidecar על סמך מרחב שמות, זהות ומאפיינים של שכבה 7 (אפליקציה) בתעבורת הרשת.

באופן דומה, אתם יכולים להשתמש במדיניות רשת של Kubernetes כדי לאשר או לדחות חיבורי רשת בשכבה 4 (שכבת התעבורה).

הפעלת שערים ליציאת תעבורת נתונים בצמתים ייעודיים של שערים

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

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

מוודאים שרק פודים של שערים יכולים לפעול בצמתים של שערים. צריך למנוע מ-Pods אחרים להגיע לצמתי שער, אחרת אפשר לעקוף את אמצעי הבקרה של היציאה. כדי למנוע הפעלה של עומסי עבודה בצמתים מסוימים, אפשר להשתמש בכתמי צבע (taints) ובהיתרים (tolerations). צריך להוסיף כתם לצמתים במאגר הצמתים של שער הכניסה ולהוסיף טולרנטיות תואמת לפריסת שער היציאה.

החלת כללי חומת אש של VPC על צמתים ספציפיים

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

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

כשיוצרים כלל של חומת אש ב-VPC, מציינים את היציאות והפרוטוקולים שהכלל מאפשר או חוסם, ואת כיוון תעבורת הנתונים שהוא חל עליה. כללי תעבורת נתונים יוצאת (egress) חלים על תעבורה יוצאת, וכללי תעבורת נתונים נכנסת (ingress) חלים על תעבורה נכנסת. ברירת המחדל לתעבורת נתונים יוצאת (egress) היא allow וברירת המחדל לתעבורת נתונים נכנסת (ingress) היא deny.

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

בתרשים הבא מוצג איך אפשר להחיל כללי חומת אש נפרדים על צמתים בשני מאגרי צמתים שונים, על סמך חשבון השירות שמוקצה לצומת. במקרה הזה, כלל חומת אש deny all ברירת מחדל דוחה את הגישה ליציאה לכל ה-VPC. כדי למנוע דריסה של כללי ברירת מחדל של חומת האש שחיוניים להפעלת האשכול, הכלל deny all צריך להשתמש בעדיפות נמוכה, כמו 65535. כלל חומת אש יוצאת עם עדיפות גבוהה יותר מוחל על צמתי השער כדי לאפשר להם להתחבר ישירות למארחים חיצוניים ביציאות 80 ו-443. למאגר הצמתים שמוגדר כברירת מחדל אין גישה למארחים חיצוניים.

מאגר צמתים של חומת אש

שימוש בכללי מדיניות של רשת Kubernetes כחומת אש לקבוצות Pod ולמרחבי שמות

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

  • בין מרחבי שמות
  • ל-Pods בתוך מרחב שמות
  • לפורטים ספציפיים ולבלוקים של כתובות IP.

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

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

  • צריך לאפשר חיבורים יוצאים ממרחבי השמות של עומס העבודה למרחבי השמות של istio-system ושל istio-egress. ל-Pods צריכה להיות אפשרות להתחבר אל istiod ואל שער היציאה.
  • מתן הרשאה לעומסי עבודה לשלוח שאילתות DNS ממרחבי השמות של עומסי העבודה ליציאה 53 במרחב השמות kube-system.
  • אפשר גם לאפשר לעומסי עבודה באותו מרחב שמות להתחבר אחד לשני.
  • אפשר גם לאפשר חיבורים יוצאים בין מרחבי השמות שבהם משתמשים צוותים שונים של אפליקציות.
  • לאפשר חיבורים יוצאים ממרחבי שמות של עומסי עבודה לכתובות ה-VIP של Google APIs (שנחשפים באמצעות גישה פרטית ל-Google). ‫Cloud Service Mesh מספק רשות אישורים מנוהלת וחושף אותה כ-API, כך ששרתי ה-proxy מסוג sidecar צריכים להיות מסוגלים להתחבר אליה. סביר להניח שחלק מעומסי העבודה יזדקקו לגישה ל-Google APIs.
  • לאפשר חיבורים יוצאים ממרחבי שמות של עומסי עבודה לשרת המטא-נתונים של GKE, כדי שממשקי ה-proxy של sidecar ועומסי העבודה יוכלו לבצע שאילתות מטא-נתונים ולאמת את עצמם ב-Google APIs.

כברירת מחדל, כשמזריקים קובץ עזר חיצוני ל-Pod של עומס עבודה, iptablesמוגדרים כללים כך שהפרוקסי יתעד את כל תעבורת ה-TCP הנכנסת והיוצאת. עם זאת, כמו שציינתי קודם, יש דרכים לעומסי עבודה לעקוף את השרת הפרוקסי. כללי חומת האש ב-VPC מונעים גישה ישירה לתעבורת נתונים יוצאת (egress) מהצמתים שמוגדרים כברירת מחדל שמריצים את עומסי העבודה. אתם יכולים להשתמש במדיניות רשת של Kubernetes כדי לוודא שלא ניתן לבצע יציאה חיצונית ישירה ממרחבי שמות של עומסי עבודה, ושהיציאה אפשרית למרחב השמות istio-egress.

אם אתם שולטים גם בתעבורת נתונים נכנסת (ingress) באמצעות מדיניות רשת, אתם צריכים ליצור מדיניות כניסה שתתאים למדיניות היציאה שלכם.

הגדרות ואבטחה של Anthos Service Mesh

עומסי עבודה שפועלים ב-Service mesh לא מזוהים על סמך כתובות ה-IP שלהם. ‫Cloud Service Mesh מקצה לכל עומס עבודה זהות חזקה שניתנת לאימות בצורה של אישור ומפתח X.509. תקשורת מהימנה בין עומסי עבודה נוצרת באמצעות חיבורים מוצפנים ומאומתים של TLS דו-צדדי (mTLS).

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

למרות שהתנועה יכולה לצאת מהרשת ישירות משרתי ה-proxy של ה-sidecar, אם אתם צריכים שליטה נוספת, מומלץ לנתב את התנועה דרך שערים ליציאה, כפי שמתואר במדריך הזה.

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

אדמינים של רשתות יכולים לנהל את אמצעי הבקרה באופן מרכזי באמצעות מרחב שמות (namespace) ייעודי istio-egress להגדרת רשתות mesh שקשורות ליציאה. כפי שהמלצנו קודם, כדאי לפרוס את שער היציאה במרחב השמות istio-egress. אפשר ליצור ולנהל רשומות שירות, שערים ומדיניות הרשאות במרחב השמות הזה.

נדרשת הגדרה מפורשת של יעדים חיצוניים

מוודאים שפרוקסי של Service mesh מתוכנתים רק עם נתיבים למארחים חיצוניים שהוגדרו במפורש במרשם של Service mesh. מגדירים את מצב מדיניות התעבורה היוצאת לערך REGISTRY_ONLY במשאב sidecar שמוגדר כברירת מחדל לכל מרחב שמות. הגדרת מדיניות לתעבורת נתונים יוצאת ב-mesh לא צריכה להיחשב כשלעצמה כאמצעי בקרה מאובטח של היקף.

הגדרת יעדים חיצוניים באמצעות רשומות שירות

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

הגדרת אופן הפעולה של שער יציאה באמצעות משאב השער

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

ב-Cloud Service Mesh מגרסה 1.6 ואילך, פרוטוקול mTLS מופעל אוטומטית כברירת מחדל. עם mTLS אוטומטי, קובץ עזר חיצוני בצד הלקוח מזהה באופן אוטומטי אם לשרת יש קובץ עזר חיצוני. ה-sidecar בצד הלקוח שולח mTLS לעומסי עבודה עם sidecars ושולח תנועה של טקסט רגיל לעומסי עבודה ללא sidecars. גם עם mTLS אוטומטי, תעבורת נתונים שנשלחת לשער היציאה מפרוקסי מסוג sidecar לא משתמשת ב-mTLS באופן אוטומטי. כדי לציין איך החיבורים לשער היציאה צריכים להיות מאובטחים, צריך להגדיר את מצב ה-TLS במשאב השער. בכל מקרה שאפשר, צריך להשתמש ב-mTLS לחיבורים משרתי proxy מסוג sidecar לשער היציאה.

אפשר לאפשר לעומסי עבודה ליזום חיבורי TLS ‏ (HTTPS) בעצמם. אם עומסי העבודה יוצרים חיבורי TLS, בדרך כלל ביציאה 443, צריך להגדיר את השער לשימוש במצב passthrough לחיבורים ביציאה הזו. עם זאת, שימוש במצב passthrough אומר שהשער לא יכול להחיל מדיניות הרשאות על סמך הזהות של עומס העבודה או המאפיינים של הבקשה המוצפנת. בנוסף, אי אפשר להשתמש כרגע ב-mTLS וב-passthrough ביחד.

tls pass through

הגדרת שירותים וירטואליים וכללי יעד לניתוב תעבורה דרך שער

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

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

משתמשים בכלל יעד לכל מארח חיצוני כדי להגדיר את שער היציאה כך שיבצע 'שדרוג' של בקשות HTTP רגילות לשימוש בחיבור TLS ‏ (HTTPS) כשמעבירים אותן ליעד. שדרוג חיבור של טקסט רגיל ל-TLS נקרא לעיתים קרובות התחלת TLS.

שליטה בהיקף של הגדרת ה-proxy באמצעות משאב ה-Sidecar

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

  • ‫Pods באותו מרחב שמות
  • ממשקי API ושירותים של Google
  • שרת המטא-נתונים של GKE
  • מארחים חיצוניים ספציפיים שהוגדרו באמצעות רשומות שירות

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

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

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

‫AuthorizationPolicy הוא משאב שמאפשר להגדיר מדיניות פרטנית של בקרת גישה לתעבורה ב-mesh. אתם יכולים ליצור כללי מדיניות כדי לאפשר או לדחות תנועה על סמך מאפיינים של המקור, היעד או התנועה עצמה (לדוגמה, המארח או הכותרות של בקשת HTTP).

כדי לאפשר או לדחות חיבורים על סמך הזהות או מרחב השמות של עומס העבודה של המקור, צריך לאמת את החיבור לשער היציאה באמצעות mTLS. החיבורים מ-sidecar לשער היציאה לא משתמשים אוטומטית ב-mTLS, ולכן בכלל היעד של החיבורים לשער צריך לציין במפורש את מצב ה-TLS‏ ISTIO_MUTUAL.

כדי לאשר או לדחות בקשות בשער באמצעות מדיניות הרשאות, עומסי העבודה צריכים לשלוח בקשות HTTP רגילות ליעדים מחוץ לרשת. לאחר מכן, שרתי ה-proxy מסוג sidecar יכולים להעביר את הבקשה לשער באמצעות mTLS, והשער יכול ליצור חיבור TLS מאובטח למארח החיצוני.

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

  • אם מרחב השמות של המקור הוא team-x והמארח של היעד הוא example.com, התנועה מותרת.

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

  • אם מרחב השמות של המקור הוא team-y וגם המארח של היעד הוא httpbin.org וגם הנתיב הוא ‎/status/418, אז מאשרים את התנועה.

    מדיניות הרשאות באמצעות httpbin

כל הבקשות האחרות נדחות.

הגדרת שער היציאה כך שיצור חיבורי TLS ‏ (HTTPS) ליעד

הגדרת כללי יעד כך ששער היציאה יתחיל חיבורי TLS ‏ (HTTPS) ליעדים חיצוניים.

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

מכיוון שעומסי העבודה שולחים בקשות HTTP רגילות, צריך להגדיר את שרת ה-proxy של קובץ העזר החיצוני של עומס העבודה כדי ליצור חיבור mTLS כששולחים אותן לשער. שער תעבורת הנתונים היוצאת מבטל את חיבור ה-mTLS ויוצר חיבור TLS (HTTPS) רגיל למארח היעד.

התחלת TLS בשער יציאה

לגישה הזו יש כמה יתרונות:

  • אפשר להשתמש במדיניות הרשאות כדי לאשר או לדחות תנועה על סמך מאפיינים של עומס העבודה של המקור והבקשות.

  • תעבורת הנתונים בין עומסי העבודה של ה-Pods לבין שער היציאה מוצפנת ומאומתת (mTLS), ותעבורת הנתונים בין שער היציאה לבין היעד מוצפנת (TLS/HTTPS).

  • בתוך הרשת, שרתי proxy מסוג sidecar יכולים לצפות במאפיינים של בקשות HTTP (לדוגמה, כותרות) ולפעול בהתאם להם, וכך לספק אפשרויות נוספות לניטור ולשליטה.

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

  • אפשר להשתמש מחדש בחיבורי TLS ששער היציאה יוצר לשירותים חיצוניים כדי להעביר תעבורה ממספר רב של Pods. שימוש חוזר בחיבורים יעיל יותר ומפחית את הסיכון להגעה למגבלות החיבור.

DNS, שמות מארחים ותווים כלליים

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

‫Cloud Service Mesh יכול לנתב תעבורה על סמך מארחים עם תווים כלליים. המקרה הפשוט ביותר הוא שימוש בתו כללי למארחים שחולקים שם משותף ומאוחסנים בקבוצה משותפת של שרתים. לדוגמה, אם קבוצה אחת של שרתים יכולה לספק שירות לדומיינים שתואמים ל-*.example.com, אפשר להשתמש במארח עם תו כללי.

שער יציאה רגיל לא יכול להעביר נתונים על סמך מארחים כלליים ושרירותיים יותר עם תווים כלליים לחיפוש (לדוגמה, *.com) בגלל מגבלות מסוימות של פרוקסי Envoy שמשמש את Istio. ‫Envoy יכול לנתב תנועה רק למארחים מוגדרים מראש, לכתובות IP מוגדרות מראש או לכתובת ה-IP המקורית של היעד של בקשה. כשמשתמשים בשער יציאה, כתובת ה-IP המקורית של היעד של הבקשה אובדת כי היא מוחלפת בכתובת ה-IP של השער, ואי אפשר להגדיר מראש את מארחי היעד השרירותיים.

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

שימוש בבקרת גישה מבוססת-תפקידים (RBAC) ב-Kubernetes

רק אדמינים מורשים צריכים להיות מסוגלים להגדיר אמצעי בקרה ליציאה. הגדרת בקרת גישה מבוססת-תפקידים (RBAC) ב-Kubernetes כדי למנוע עקיפה לא מורשית של אמצעי הבקרה ליציאת נתונים. הקצאת תפקידים ב-RBAC כדי שרק אדמינים של רשתות יוכלו לנהל את מרחבי השמות istio-egress,istio-system, ו-kube-system ואת המשאבים הבאים:

  • Sidecar
  • ServiceEntry
  • שער
  • AuthorizationPolicy
  • NetworkPolicy

הגבלת השימוש ב-tolerations

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

גישה נוספת היא שימוש בבקרת כניסה של Kubernetes. ‫Anthos כולל רכיב שנקרא Policy Controller, שפועל כ-Kubernetes admission controller ומאמת שהפריסות עומדות במגבלות המדיניות שאתם מציינים.

מוודאים שהתנועה מתועדת

לעתים קרובות יש צורך לרשום ביומן את כל התנועה שחוצה את גבולות הרשת. תיעוד התנועה חיוני אם אתם צריכים להוכיח עמידה בתקנות נפוצות להגנה על נתונים. יומני תעבורה נשלחים ישירות אל Cloud Logging ואפשר לגשת אליהם מלוחות הבקרה של Cloud Service Mesh במסוף Google Cloud . אפשר לסנן את היומנים לפי מאפיינים שונים, כולל מקור/יעד, זהות, מרחב שמות, מאפייני התנועה והחביון.

כדי לאפשר ניפוי באגים בקלות באמצעות kubectl, מפעילים את רישום התנועה ב-stdout כשמתקינים את Cloud Service Mesh באמצעות ההגדרה accessLogFile.

יומני ביקורת נשלחים אל Cloud Logging בכל פעם ש-Mesh CA יוצר אישור לעומס עבודה.

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

אפשר לפרוס את Cloud Service Mesh בכמה אשכולות GKE. רשתות מרובות אשכולות מציעות אפשרויות חדשות לשליטה בתעבורת נתונים יוצאת (egress), אבל יש גם כמה מגבלות.

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

אפשר להשתמש במדיניות רשת של Kubernetes בפריסות מרובות אשכולות, אבל מכיוון שהיא פועלת בשכבה 4 (תעבורה), היא לא יכולה להגביל חיבורים בין אשכולות על סמך מרחב השמות או ה-Pod של היעד.

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