Microsoft הוסיפה בתצוגה מקדימה Private Ingress ל־Azure Application Gateway for Containers. היכולת מאפשרת לפרסם שירותי AKS דרך frontend ללא כתובת IP ציבורית, כך שהגישה אליו מתאפשרת רק באמצעות Azure Private Link ו־private endpoints שאושרו במפורש.
החידוש מיועד לאפליקציות פנימיות, שירותים משותפים ותקשורת בין אשכולות Kubernetes, וכן לארגונים שבהם Firewall, NVA או שירות אחר חייב להיות נקודת הכניסה היחידה. Application Gateway for Containers ממשיך לספק ניתוב Layer 7, TLS, בדיקות בריאות ו־WAF — אך בלי לחשוף נתיב ישיר מהאינטרנט אל ה־frontend הפרטי.
לא עוד כתובת ציבורית שמסתמכים על חסימתה
ב־frontend ציבורי, שם ה־FQDN מפוענח לכתובת שניתנת לניתוב מהאינטרנט. גם אם WAF, NSG ומנגנוני אימות חוסמים גישה לא רצויה, הכתובת עדיין קיימת וניתנת לסריקה. ב־Private Ingress אין כתובת ציבורית. לקוח יכול להגיע לשירות רק דרך private endpoint שחובר ואושר.
- צמצום שטח התקיפה: אין IP ציבורי לסריקה או לפנייה ישירה.
- נתיב כניסה ידוע: כל צרכן חייב private endpoint מאושר.
- חציית גבולות ארגוניים: החיבור יכול לעבור בין VNets, מנויים ו־Microsoft Entra tenants.
- ללא VNet Peering: Private Link תומך גם באזורים שונים ובטווחי CIDR חופפים.
איך זה עובד?
החיבור הפרטי אינו כתובת IP שמוקצית ישירות ב־association subnet של Application Gateway for Containers. Microsoft מדגישה שהגישה מורחבת באמצעות private endpoints. ה־FQDN של ה־frontend הפרטי נפתר לכתובת הפרטית שהוקצתה ל־private endpoint בצד הלקוח, ורק לאחר שהחיבור אושר.
ב־Gateway API משתמשים במחלקה azure-alb-internal כדי ליצור frontend פרטי, לעומת azure-alb-external ל־frontend ציבורי. משאב Application Gateway for Containers יחיד יכול להחזיק frontend ציבורי ופרטי במקביל, עם כללי ניתוב ומדיניות WAF נפרדים לכל אחד.
תרחישי שימוש מרכזיים
יישומים פנימיים בלבד
פורטלים ארגוניים, APIs פנימיים, שירותי פלטפורמה וצינורות נתונים יכולים להישאר ללא חשיפה לאינטרנט. המשתמשים מגיעים דרך VNet פנימי או רשת מקומית שמחוברת ל־private endpoint.
תקשורת בין אשכולות
שירות באשכול A יכול לפנות לשירות באשכול B דרך frontend פרטי, בלי לצאת לכתובת ציבורית ולחזור. המודל מתאים גם לאשכולות באזורים שונים ואינו מחייב peering או תכנון כתובות משותף.
Firewall או NVA לפני היישום
אפשר להציב Azure Firewall או appliance ארגוני לפני Application Gateway for Containers. עם זאת, יש מחיר תפעולי: כאשר ה־Firewall מבצע SNAT, ה־gateway רואה את כתובת ה־Firewall ולא את כתובת הלקוח המקורית. גם כותרת X-Forwarded-For עלולה להכיל את הכתובת הפרטית של ה־Firewall. יישומים שתלויים ב־IP המקורי לצורכי זיהוי, rate limiting או מניעת הונאות חייבים לבדוק את התכנון.
מגבלות ודרישות של התצוגה המקדימה
- היכולת נמצאת ב־Preview ואינה מיועדת אוטומטית לכל עומס ייצור.
- נדרש ALB Controller בגרסה 1.13 ומעלה.
- נדרש REST API בגרסה 2026-03-01 ומעלה.
- frontend פרטי זמין למשאבי association שנוצרו ב־23 באפריל 2026 או לאחר מכן.
- פורטים אחרים מ־80 ו־443 עדיין אינם נתמכים בתרחיש המעבר מ־AGIC.
רשימת בדיקה לפני פיילוט
- הגדירו מי רשאי ליצור ולאשר private endpoint connections.
- תכננו DNS פרטי כך שה־FQDN ייפתר לכתובת הנכונה בכל רשת צרכנית.
- בדקו אם נדרשת שמירת כתובת הלקוח המקורית לפני הצבת Firewall בחזית.
- הפרידו בין frontends ציבוריים ופרטיים ובנו מדיניות WAF מתאימה לכל אחד.
- בצעו בדיקות קצה בין מנויים, tenants ואזורים לפני מעבר שירותים קריטיים.
השורה התחתונה
Private Ingress ל־Application Gateway for Containers מאפשר לארגונים להפעיל ניתוב Kubernetes מנוהל בלי להשאיר frontend ציבורי רק כדי לחסום אותו בשכבות אחרות. השילוב עם Private Link מתאים במיוחד לשירותים פנימיים, סביבות מרובות מנויים ותקשורת בין אשכולות. מנגד, סטטוס ה־Preview, מגבלות הגרסה ואובדן כתובת הלקוח בתצורות מסוימות מחייבים פיילוט ותכנון מדויק לפני שימוש רחב.
מקורות: Microsoft Learn: Private ingress, עודכן 3 בנובמבר 2026; Azure Update הרשמי; תמונת המקור ב־Pexels.
צילום: Douglas Rafael Fonseca, Pexels. התמונה היא מטאפורה חזותית בלבד ואינה מתארת תשתית Azure, בהתאם לרישיון Pexels Free.
