אתם יכולים להתאים אישית את הגישה לרשת עבור רמת הבקרה והצמתים של אשכול Google Kubernetes Engine (GKE) כדי לשפר את אבטחת הרשת של האשכול ועומסי העבודה שלו. במסמך הזה מוסבר על סוגי הבידוד השונים שאפשר להגדיר עבור האשכול, על היתרונות של בידוד הרשת ועל המגבלות שצריך לקחת בחשבון לפני שמבודדים את האשכול.
כדי להגדיר רמות בידוד ספציפיות לאשכול, אפשר לעיין במסמכים הבאים:
כדאי לתכנן ולעצב את ההגדרה של בידוד הרשת עם הארכיטקטים של הרשת, מהנדסי הרשת, האדמינים של הרשת או צוות אחר בארגון שאחראי על ההגדרה, ההטמעה והתחזוקה של ארכיטקטורת הרשת.
סוגי גישה לרשת
רכיבים באשכול – כמו מישור הבקרה, שרת ה-API והצמתים – שולחים ומקבלים תנועה ברשת למטרות שונות. אתם יכולים להתאים אישית את הבידוד של האשכול על ידי שליטה בסוג אחד או יותר של גישה לרשת:
- גישה למישור הבקרה ממקורות חיצוניים: אפשר להתאים אישית את האנשים שיכולים לגשת למישור הבקרה כדי לבצע משימות כמו הפעלת פקודות
kubectlבאשכול. - גישה לתגובות לפעולה מאתרים אחרים (webhook) חיצוניים משרת ה-API: אפשר להתאים אישית את האפשרות ששרת ה-API של Kubernetes ישלח תנועה ישירות לשרתי webhook חיצוניים דרך מישור הבקרה.
- גישה לצמתים ממקורות חיצוניים: אפשר להתאים אישית את הגישה לצמתים שלכם ללקוחות חיצוניים באינטרנט הציבורי.
גישה למישור הבקרה ממקורות חיצוניים
בקטע הזה, נסביר לכם איך לקבוע למי תהיה גישה למישור הבקרה.
לכל אשכול GKE יש מישור בקרה שמטפל בבקשות של Kubernetes API. מישור הבקרה פועל במכונה וירטואלית (VM) שנמצאת ברשת VPC בפרויקט שמנוהל על ידי Google. באשכול אזורי יש כמה רפליקות של מישור הבקרה, וכל אחד מהם פועל במכונה וירטואלית משלו.
גורמים ראשיים כמו אדמינים של אשכולות משתמשים בנקודת קצה של מישור הבקרה כדי לגשת לאשכול למשימות כמו הפעלת פקודות kubectl או פריסת עומסי עבודה. לקוחות חיצוניים משתמשים בנקודת הקצה של רמת הבקרה כדי לגשת לאשכול, והיא לא משמשת לתקשורת ישירה עם המכונות הווירטואליות ב-Compute Engine שמארחות את העותקים המשוכפלים של רמת הבקרה. למישור הבקרה יש את סוגי נקודות הקצה הבאים לגישה לאשכול:
למישור הבקרה יש שני סוגים של נקודות קצה לגישה לאשכול:
- נקודת קצה מבוססת DNS
- נקודות קצה מבוססות-IP
כדי לפשט את ההגדרה ולקבל שכבת אבטחה גמישה שמבוססת על מדיניות, מומלץ להשתמש רק בנקודת הקצה שמבוססת על DNS כדי לגשת למישור הבקרה.
נקודת קצה מבוססת DNS
נקודת הקצה מבוססת ה-DNS מספקת DNS ייחודי וקבוע או שם דומיין מלא (FQDN) לכל מישור בקרה של אשכול. אפשר להשתמש בשם ה-DNS הזה כדי לגשת למישור הבקרה לאורך כל מחזור החיים שלו. שם ה-DNS מומר לנקודת קצה שאפשר לגשת אליה מכל רשת שאפשר להגיע אליה באמצעות ממשקי API של Cloud de Confiance by S3NS , כולל רשתות מקומיות או רשתות ענן אחרות. הפעלת נקודת הקצה מבוססת ה-DNS מבטלת את הצורך ביעד מבוצר (bastion host) או בצמתי שרת proxy כדי לגשת למישור הבקרה מרשתות VPC אחרות או ממיקומים חיצוניים.
כדי לגשת לנקודת הקצה של מישור הבקרה, צריך להגדיר תפקידים ומדיניות של IAM וטוקנים לאימות. לפרטים נוספים על ההרשאות הנדרשות, אפשר לעיין במאמר התאמה אישית של בידוד הרשת.
בנוסף למדיניות ולטוקנים של IAM, אפשר גם להגדיר את מאפייני הגישה הבאים:
אמצעי בקרה מבוססי כתובת IP או רשת באמצעות VPC Service Controls: כדי לשפר את האבטחה של מישור הבקרה של אשכול GKE, VPC Service Controls מוסיף עוד שכבת אבטחה לגישה. היא משתמשת בבקרת גישה מבוססת-הקשר שמבוססת על מאפיינים כמו מקור הרשת.
שירות VPC Service Controls לא תומך ישירות באשכולות עם כתובות IP ציבוריות למישור הבקרה שלהם. עם זאת, אשכולות GKE, כולל אשכולות פרטיים וציבוריים, מקבלים הגנה מ-VPC Service Controls כשניגשים אליהם באמצעות נקודת הקצה (endpoint) שמבוססת על DNS.
כדי להגדיר את VPC Service Controls להגנה על נקודת הקצה מבוססת ה-DNS של אשכול GKE, צריך לכלול את
container.googleapis.comואתkubernetesmetadata.googleapis.comברשימת השירותים המוגבלים של service perimeter. הוספת ממשקי ה-API האלה לגבולות גזרה לשירות תאפשר שימוש ב-VPC-SC עבור כל הפעולות של GKE API. ההגדרה הזו עוזרת להבטיח שהגישה למישור הבקרה תהיה בהתאם למתחמי האבטחה שהגדרתם.שימוש במדיניות IAM וב-VPC Service Controls כדי לאבטח את הגישה לנקודת הקצה שמבוססת על DNS יוצר מודל אבטחה רב-שכבתי למישור הבקרה של האשכול. VPC Service Controls משתלב עם שירותים נתמכים Cloud de Confiance . הוא מתאים את הגדרות האבטחה של האשכול לנתונים שאתם מארחים בשירותים אחרים של Cloud de Confiance .
Private Service Connect או Cloud NAT: כדי לגשת לנקודת הקצה (endpoint) שמבוססת על DNS מלקוחות שאין להם גישה לאינטרנט הציבורי. כברירת מחדל, אפשר לגשת לנקודת הקצה (endpoint) שמבוססת על DNS דרך Cloud de Confiance ממשקי API שזמינים באינטרנט הציבורי. מידע נוסף זמין במאמר התאמה אישית של בידוד הרשת בקטע נקודת קצה מבוססת DNS.
אמצעי אימות של Kubernetes: כדי לבצע אימות לנקודת הקצה מבוססת ה-DNS באמצעות אסימוני Bearer של Kubernetes ServiceAccount או אישורי לקוח X.509. שיטות האימות האלה מושבתות כברירת מחדל באשכולות GKE. אפשר להפעיל את ה-methods האלה כשמגדירים את נקודת הקצה (endpoint) מבוססת ה-DNS של אשכול.
נקודות קצה מבוססות-IP
אופציונלית, אפשר גם להגדיר גישה למישור הבקרה באמצעות נקודות קצה מבוססות-IP.
טרמינולוגיה שקשורה לאשכולות ולכתובות IP
Cloud de Confiance by S3NS כתובות IP חיצוניות:
כתובות IP חיצוניות שמוקצות לכל מכונה וירטואלית שמשמשת לקוחות שמתארחים ב-Cloud de Confiance. Cloud de Confiance הן בבעלות שלCloud de Confiance. Cloud de Confiance מידע נוסף זמין במאמר איפה אפשר למצוא את טווחי כתובות ה-IP של Compute Engine?
כתובות IP חיצוניות שמשמשות מוצרים כמו Cloud Run או פונקציות של Cloud Run. Cloud de Confiance כל לקוח שמתארח ב- Cloud de Confiance יכול ליצור מופעים של כתובות ה-IP האלה. Cloud de Confiance הוא הבעלים של כתובות ה-IP האלה.
כתובות IP שמורות של Google: כתובות IP חיצוניות למטרות ניהול של אשכולות GKE. כתובות ה-IP האלה כוללות תהליכים מנוהלים של GKE ושירותי Google אחרים בייצור. כתובות ה-IP האלה הן בבעלות Google.
טווחים של כתובות IP של אשכול GKE: כתובות IP פנימיות שמוקצות לאשכול ש-GKE משתמש בו עבור הצמתים, ה-Pods והשירותים של האשכול.
כתובות IP פנימיות: כתובות IP מרשת ה-VPC של האשכול. כתובות ה-IP האלה יכולות לכלול את כתובת ה-IP של האשכול, רשתות מקומיות, טווחים של RFC 1918 או כתובות IP ציבוריות בשימוש פרטי (PUPI) שכוללות טווחים שאינם RFC 1918.
נקודת קצה של אשכול שמבוססת על כתובת IP חיצונית: כתובת ה-IP של נקודת הקצה החיצונית, שמוקצית למישור הבקרה על ידי GKE.
IP חיצוני של מכונה וירטואלית במישור הבקרה: כתובת ה-IP החיצונית שמוקצית לכל מופע של מכונה וירטואלית שמריצה את מישור הבקרה, ומשמשת רק לתעבורת נתונים יוצאת משרת ה-API.
נקודת קצה פנימית: כתובת ה-IP הפנימית ש-GKE מקצה למישור הבקרה.
רשת VPC: רשת וירטואלית שבה יוצרים תת-רשתות עם טווחי כתובות IP במיוחד לצמתים ול-Pods של האשכול.
כשמשתמשים בנקודות קצה מבוססות-IP, יש שתי אפשרויות:
חשיפת מישור הבקרה בנקודות הקצה החיצוניות והפנימיות. המשמעות היא שאפשר לגשת לנקודת הקצה החיצונית של מישור הבקרה מכתובת IP חיצונית, ואפשר לגשת לנקודת הקצה הפנימית מרשת ה-VPC של האשכול. הצמתים יתקשרו עם מישור הבקרה רק בנקודת הקצה הפנימית.
חשיפת מישור הבקרה בנקודת הקצה הפנימית בלבד. המשמעות היא שלקוחות באינטרנט לא יכולים להתחבר לאשכול, ומישור הבקרה נגיש מכל כתובת IP מרשת ה-VPC של האשכול. הצמתים יתקשרו עם מישור הבקרה רק בנקודת הקצה הפנימית.
זו האפשרות המאובטחת ביותר כשמשתמשים בנקודות קצה מבוססות IP, כי היא מונעת גישה למישור הבקרה מכל מקום באינטרנט. זו בחירה טובה אם יש לכם עומסי עבודה שדורשים – לדוגמה – גישה מבוקרת בגלל תקנות בנושא פרטיות נתונים ואבטחה.
בשתי האפשרויות הקודמות, אפשר להגביל את כתובות ה-IP שיכולות להגיע לנקודות הקצה על ידי הגדרת רשתות מורשות. אם אתם משתמשים בנקודות קצה מבוססות-IP, מומלץ מאוד להוסיף לפחות רשת מורשית אחת. רשתות מורשות מעניקות גישה למישור הבקרה לקבוצה ספציפית של כתובות IPv4 מהימנות, ומספקות הגנה והטבות אבטחה נוספות לאשכול GKE.
כדי לאבטח את אשכול GKE, מומלץ להפעיל רשתות מורשות כשמשתמשים בנקודות קצה (endpoint) מבוססות-IP.
איך רשתות מורשות פועלות
רשתות מורשות מספקות חומת אש שמבוססת על כתובות IP ושולטת בגישה למישור הבקרה של GKE. הגישה למישור הבקרה תלויה בכתובות ה-IP של המקור. כשמפעילים רשתות מורשות, מגדירים את כתובות ה-IP שרוצים לאפשר להן גישה לנקודת הקצה של מישור הבקרה של אשכול GKE כרשימה של בלוקים בפורמט CIDR.
בטבלה הבאה מוצגים:
- כתובות ה-IP המוגדרות מראש שתמיד יכולות לגשת למישור הבקרה של GKE, גם אם מפעילים רשתות מורשות.
- כתובות ה-IP שניתנות להגדרה שיכולות לגשת למישור הבקרה כשמוסיפים אותן לרשימת ההיתרים על ידי הפעלת רשתות מורשות.
| נקודות קצה של מישור הבקרה | כתובות IP מוגדרות מראש שיכולות תמיד לגשת לנקודות הקצה | כתובת IP שאפשר להגדיר לה גישה לנקודות הקצה אחרי הפעלת רשתות מורשות |
|---|---|---|
| נקודות קצה חיצוניות ופנימיות מופעלות |
|
|
| הפעלת נקודת קצה פנימית בלבד |
|
|
ברשת מורשית, אפשר גם להגדיר את האזור שממנו כתובת IP פנימית יכולה להגיע לנקודת הקצה הפנימית של מישור הבקרה. אתם יכולים לבחור לאפשר גישה רק מרשת ה-VPC של האשכול, או מכל אזור ב-VPC או בסביבה מקומית. Cloud de Confiance
מגבלות על שימוש בנקודות קצה (endpoints) שמבוססות על כתובות IP
- אם מרחיבים רשת משנה שמשמשת אשכול עם רשתות מורשות, צריך לעדכן את הגדרת הרשתות המורשות כך שתכלול את טווח כתובות ה-IP המורחב.
- אם יש לכם לקוחות שמתחברים מרשתות עם כתובות IP דינמיות, כמו עובדים ברשתות ביתיות, אתם צריכים לעדכן את רשימת הרשתות המורשות לעיתים קרובות כדי לשמור על הגישה לאשכול.
- השבתת הגישה לנקודת הקצה החיצונית של מישור הבקרה מונעת אינטראקציה מרחוק עם האשכול. אם אתם צריכים לגשת מרחוק לאשכול, אתם צריכים להשתמש ביעד מבוצר (bastion host) שמעביר את תעבורת הנתונים של הלקוחות לאשכול. לעומת זאת, אם משתמשים בנקודת קצה מבוססת DNS, צריך רק להגדיר הרשאות IAM.
- נקודות קצה מבוססות-IP לא משתלבות ישירות עם VPC Service Controls. VPC Service Controls פועל ברמת גבולות גזרה לשירות כדי לשלוט בגישה לנתונים ובתנועת הנתונים בתוך Cloud de Confiance. מומלץ להשתמש גם בנקודת קצה מבוססת DNS וגם ב-VPC Service Controls כדי להשיג הגנה חזקה מפני איומי אבטחה.
- אפשר לציין עד 100 טווחי כתובות IP מורשים (כולל כתובות IP חיצוניות ופנימיות).
אבטחת תעבורה לחיבורים של מישור הבקרה
כששולחים בקשות לשרת Kubernetes API באשכול באמצעות שיטות כמו ספריות לקוח או kubectl CLI, החיבור בין הלקוח לשרת מוגן באמצעות TLS.
כדי ליצור חיבור TLS, השרת מציג אישור ללקוח. השרת הספציפי שמציג את האישור ורשות האישורים (CA) שחותמת על האישור תלויים בנקודת הקצה שבה אתם משתמשים כדי לגשת למישור הבקרה, באופן הבא:
- נקודת קצה מבוססת DNS: האישור מוצג על ידי שירות ממשק הקצה של Google (GFE) שמארח את נקודת הקצה מבוססת ה-DNS. האישור חתום על ידי רשות אישורים (CA) ציבורית של Google, שמוכרת בדרך כלל. הלקוח יכול להשתמש במידע הציבורי של רשות האישורים כדי לאמת את האישור.
- נקודות קצה מבוססות-IP: שרת ה-API של Kubernetes מציג את האישור.
האישור חתום על ידי רשות האישורים הבסיסית של האשכול. כדי לאמת את אישור שרת ה-API, הלקוח צריך להשתמש באישור הציבורי של CA הבסיסי של האשכול. כשמגדירים לקוח בסביבה שאין לה גישה ל-CLI של gcloud, צריך להוסיף את אישור ה-CA הבסיסי של האשכול לקובץ
~/.kube/config. מידע נוסף זמין במאמר בנושא אימות לשרת Kubernetes API.
גישה למקורות חיצוניים משרת ה-API
מישור הבקרה של אשכול GKE מריץ רכיבים של מישור הבקרה של Kubernetes, כמו שרת ה-API, המתזמן והבקרים. מישור הבקרה פועל במכונה וירטואלית של Compute Engine שנמצאת בבעלות GKE בפרויקט מנוהל. למערכות Autopilot ולמערכות אזוריות יש כמה עותקים של מישור הבקרה, וכל אחד מהם פועל במכונת VM משלו.
כברירת מחדל, לכל אחת מהמכונות הווירטואליות האלה ב-Compute Engine מוקצית כתובת IP חיצונית ישירות למכונה הווירטואלית. כתובת ה-IP הזו משמשת רק לשליחת בקשות הרשאה משרת ה-API של Kubernetes במופע אל שרתי webhook של הרשאה שפועלים מחוץ לאשכול, למשל בשירות ענן אחר או בפריסה מקומית. כתובת ה-IP הזו משמשת רק אם ה-webhooks של הגישה יוצרים קשר ישירות עם שרת ה-webhook באמצעות כתובת ה-URL של השרת או כתובת ה-IP של השרת.
כדי לשפר את רמת האבטחה של מישור הבקרה, אפשר להשבית את כתובת ה-IP החיצונית במכונות וירטואליות של מישור הבקרה. במקרה של פריצה, תוקפים פוטנציאליים לא יכולים להשתמש בכתובות ה-IP החיצוניות האלה כדי לתקשר. אפשר להתאים אישית את תנועת היציאה משרת ה-API בדרכים הבאות:
- אין תעבורת נתונים יוצאת (
NONE): משביתים את כתובת ה-IP החיצונית של כל מופע של מישור הבקרה ומנתבים את תעבורת הנתונים היוצאת של שרת API לחור שחור. כל תעבורת הנתונים היוצאת (egress) הלא קריטית משרת ה-API ליעדים חיצוניים נחסמת, כולל תעבורת נתונים לשירותים מחוץ לאשכול. Cloud de Confiance האפשרות הזו לא משפיעה על תנועה קריטית של המערכת או על תנועה מהצמתים שלכם. - כל התנועה היוצאת (
VIA_CONTROL_PLANE): שומרים את כתובת ה-IP החיצונית של כל מופע של מישור הבקרה ומאפשרים לשרת ה-API להשתמש בכתובת ה-IP לתעבורת נתונים יוצאת. האפשרות הזו מוגדרת כברירת מחדל ב-GKE.
כדי ללמוד איך להתאים אישית את האשכול לאחת מהאפשרויות האלה, אפשר לעיין במאמר בנושא הגבלת תנועת היציאה משרת ה-API.
הגדרה של webhook חיצוני
כשמגדירים את הגבלות היציאה של מישור הבקרה ל-NONE, שרת ה-API לא יכול לבצע קריאות ישירות לכתובות IP חיצוניות או לשמות דומיין מלאים (FQDN). להגדרה NONE יש את ההשפעות הבאות על ווּבּהוּקים חיצוניים:
- בגרסה 1.35.1-gke.1396000 ואילך, GKE מונע יצירה או עדכון של ValidatingWebhookConfigurations או MutatingWebhookConfigurations שמשתמשים בשדה
clientConfig.url. - הגדרות קיימות של webhook שמשתמשות בשדה
clientConfig.urlכדי ליצור קשר עם שרת חיצוני מפסיקות לפעול.
כדי ליצור שרתי webhook חיצוניים ולהשתמש בהם, צריך לבצע את הפעולות הבאות:
- מעדכנים את ValidatingWebhookConfigurations או את MutatingWebhookConfigurations כדי להשתמש בשדה
clientConfig.service. השדה הזה מאפשר לשרת ה-API לשלוח בקשות לנקודת קצה של שירות, כמוmy-webhook.default.svc, באשכול שלכם. הבקשות האלה לא נחסמות כי התנועה נמצאת בתוך האשכול. מידע נוסף זמין במאמר בנושא הפניה לשירות. מגדירים את השירות להעברת תעבורה לשרת ה-webhook החיצוני. אתם יכולים להשתמש באחד מהעיצובים הבאים לניתוב תעבורה, בהתאם לדרישות האבטחה והתפעול שלכם:
- Proxy Pods: שימוש ב-Deployment או ב-StatefulSet כקצה העורפי של ה-Service. מגדירים את ה-Pods כך שיפעלו כשרתי proxy שמפנים בקשות קבלה נכנסות לשרת ה-Webhook החיצוני. העיצוב הזה מאפשר לבצע משימות נוספות, כמו בדיקה ושינוי של בקשות הגישה.
- EndpointSlices: יוצרים את השירות בלי סלקטור, ואז מוסיפים ידנית EndpointSlice שממפה את השירות לכתובת ה-IP של שרת ה-webhook החיצוני. העיצוב הזה מעביר את התנועה בלי לשנות את הבקשות.
כשמעצבים את הגדרת ה-webhook, כדאי להתחשב בגורמים הבאים:
- אימות ופרטי כניסה: כדאי לחשוב איך לבצע אימות באמצעות שרת ה-webhook החיצוני. בנוסף, תהליך העבודה של ניתוב התנועה צריך לנהל את אופן ההחלה של פרטי הכניסה (כמו מפתחות API, אישורי mTLS וטוקנים של OAuth) על החיבורים.
- אבטחה ובקרה על הרשת: כדאי לשקול את שטח ההתקפה של תכנון הניתוב ואת האפשרויות לאבטחה ולביקורת. העיצוב שאתם מטמיעים משפיע על ההגבלות שאתם יכולים להחיל על התנועה. לדוגמה, אפשר להשתמש ב-NetworkPolicies עם תרמילי proxy.
- ניראות ומהימנות: כדאי לחשוב איך לעקוב אחרי החיבורים. לדוגמה, אפשר להגדיר תרמילי proxy כדי שיפלטו מדדים, או להטמיע יכולת ניטור של רשתות עבור EndpointSlices.
גישה לצמתים ממקורות חיצוניים
בקטע הזה נסביר איך לבודד צמתים בתוך אשכול Kubernetes.
הפעלת צמתים פרטיים
כדי למנוע מלקוחות חיצוניים לגשת לצמתים, צריך להקצות לצמתים האלה רק כתובות IP פנימיות, וכך להפוך את הצמתים לפרטיים. עומסי עבודה שפועלים בצמתים ללא כתובת IP חיצונית לא יכולים לגשת לאינטרנט, אלא אם מופעל NAT ברשת של האשכול. תמיד תוכלו לשנות את ההגדרות האלה.
אפשר להפעיל צמתים פרטיים ברמת האשכול הבודד או ברמת מאגר הצמתים (במצב Standard) או ברמת עומס העבודה (במצב Autopilot). הפעלת צמתים פרטיים ברמת מאגר הצמתים או ברמת עומס העבודה מבטלת כל הגדרת צמתים ברמת האשכול.
אם מעדכנים מאגר צמתים ציבורי למצב פרטי, יכול להיות שעומסי עבודה שנדרשת להם גישה מחוץ לרשת האשכול ייכשלו בתרחישים הבאים:
אשכולות ברשת VPC משותפת שבה לא מופעלת גישה פרטית ל-Google. צריך להפעיל באופן ידני גישה פרטית ל-Google כדי לוודא ש-GKE יוריד את תמונת הצומת שהוקצתה. במקרה של אשכולות שלא נמצאים ברשת VPC משותפת, GKE מפעיל באופן אוטומטי גישה פרטית ל-Google.
עומסי עבודה שנדרשת להם גישה לאינטרנט, אבל Cloud NAT לא מופעל או שלא מוגדר פתרון NAT בהתאמה אישית. כדי לאפשר תעבורת נתונים יוצאת לאינטרנט, מפעילים Cloud NAT או פתרון NAT מותאם אישית.
גם אם מפעילים צמתים פרטיים וגם אם לא, מישור הבקרה עדיין מתקשר עם כל הצמתים רק באמצעות כתובות IP פנימיות.
היתרונות של בידוד הרשת
אלה היתרונות של בידוד הרשת:
גמישות:
- לצבירים יש הגדרה מאוחדת וגמישה. לכל האשכולות, עם או בלי נקודות קצה חיצוניות, יש אותה ארכיטקטורה והם תומכים באותה פונקציונליות. אתם יכולים לאבטח את הגישה באמצעות אמצעי בקרה ושיטות מומלצות שמתאימים לצרכים שלכם. כל התקשורת בין הצמתים באשכול לבין מישור הבקרה מתבצעת באמצעות כתובת IP פנימית.
- אפשר לשנות את הגדרות הגישה למישור הבקרה ואת ההגדרות של צומתי האשכול בכל שלב, בלי ליצור מחדש את האשכול.
- אתם יכולים להפעיל את נקודת הקצה החיצונית של מישור הבקרה אם אתם צריכים לנהל את האשכול מכל מיקום עם גישה לאינטרנט, או מרשתות או ממכשירים שלא מחוברים ישירות ל-VPC. אפשר גם להשבית את נקודת הקצה החיצונית כדי לשפר את האבטחה אם צריך לשמור על בידוד הרשת עבור עומסי עבודה רגישים. בכל מקרה, אפשר להשתמש ברשתות מורשות כדי להגביל את הגישה לטווחי כתובות IP מהימנים.
אבטחה:
- נקודות קצה מבוססות DNS עם VPC Service Controls מספקות מודל אבטחה רב-שכבתי שמגן על האשכול מפני רשתות לא מורשות וגם מפני זהויות לא מורשות שמקבלות גישה למישור הבקרה. VPC Service Controls משתלב עם יומני הביקורת של Cloud כדי לעקוב אחרי הגישה למישור הבקרה.
- לא ניתן לגשת ישירות לצמתים פרטיים ולעומסי העבודה שפועלים בצמתים האלה מהאינטרנט הציבורי, ולכן הסיכון להתקפות חיצוניות על האשכול שלכם קטן משמעותית.
- אתם יכולים לחסום גישה למישור הבקרה מCloud de Confiance כתובות IP חיצוניות או מכתובות IP חיצוניות כדי לבודד לחלוטין את מישור הבקרה של האשכול ולהפחית את החשיפה לאיומי אבטחה פוטנציאליים.
- אתם יכולים להשבית את כתובות ה-IP החיצוניות של מכונות וירטואליות במישור הבקרה כדי למנוע מהאקרים להשתמש בכתובות ה-IP.
עמידה בדרישות: אם אתם עובדים בתעשייה עם תקנות מחמירות לגבי גישה לנתונים ואחסון שלהם, צמתים פרטיים עוזרים לעמוד בדרישות האלה כי הם מבטיחים שמידע רגיש יישאר בתוך הרשת הפרטית שלכם.
שליטה: צמתים פרטיים מאפשרים לכם שליטה מדויקת על התנועה שנכנסת לאשכול ויוצאת ממנו. אתם יכולים להגדיר כללים של חומת אש ומדיניות רשת כדי לאפשר רק תקשורת מורשית. אם אתם פועלים בסביבות מרובות עננים, צמתים פרטיים יכולים לעזור לכם ליצור תקשורת מאובטחת ומבוקרת בין סביבות שונות.
עלות: הפעלת צמתים פרטיים יכולה להוזיל את העלויות של צמתים שלא נדרשת להם כתובת IP חיצונית כדי לגשת לשירותים ציבוריים באינטרנט.
המאמרים הבאים
- כדי להתנסות בבידוד רשת, פועלים לפי ההוראות שבמאמר הגדרת בידוד רשת.
- איך מגבילים את תעבורת הנתונים היוצאת משרת ה-API
- מידע נוסף על Private Service Connect
- כדאי לקרוא סקירה כללית על ארכיטקטורת אשכולים.
- מידע נוסף על שיטות מומלצות בנוגע לרשתות