למה kubectl עובד דרך ה-VPN אבל AKS מפסיק להתרחב

אתם מוסיפים את הכתובת הציבורית של ה-VPN במשרד לרשימת ההיתרים של שרת ה-API של AKS, ו-kubectl עובד. כעבור שבוע הרחבת node pool נכשלת, משימת CI לא מגיעה לאשכול, והפורטל מציג שגיאה שלא מזכירה דבר על טווחי IP. איש לא שינה את רשימת ההיתרים. הבקרה שהפעלתם היא מסנן IP ציבורי לפני שרת ה-API, והוא לא יודע מי מתקשר, אלא רק מאיזו כתובת הגיעה הקריאה. ה-VPN הוא כתובת אחת מבין כמה שהאשכול צריך, ולעיתים רחוקות היא זו שנשברת ראשונה.

רשימת ההיתרים מתאימה לכתובת, לא לאדם

--api-server-authorized-ip-ranges מקבל בלוקי CIDR, לא משתמשים או קבוצות. כשבקשה של מפתח יוצאת משרת ה-VPN אל Azure, כתובת המקור בשרת ה-API היא היציאה הציבורית של שרת ה-VPN. לכן כל אדם ב-VPN הזה חולק רשומה אחת, וכל מי שמחוץ ל-VPN נדחה עוד לפני שהאימות מתרחש.

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

מה שנשבר ראשון הוא בדרך כלל לא kubectl

רשימת ההיתרים חלה על נקודת הקצה הציבורית של שרת ה-API, ולכן כל מה שמחוץ לכתובות שרשמתם מפסיק לעבוד מיד. הנפגעים הברורים הם המשרד השני בלי מסלול VPN, מריץ CI בצינור מתארח, ומחשב נייד ששכח להתחבר. קל לזהות אותם כי אדם ממתין.

המקרה הפחות ברור הוא אוטומציה שמונעת על ידי Azure או הכלים שלכם. חלק מהפעולות שמזמינה הפלטפורמה מגיעות לשרת ה-API מכתובות שאינן ה-VPN שלכם, וכשאחת מהן מתחילה להיכשל מיד אחרי ההחמרה ברשימה, התזמון הוא הרמז. אל תניחו שהרשימה מלאה מפני שגישה אינטראקטיבית עובדת; בדקו מה התכונה דורשת עבור האזור והמנויים שלכם לפני שתסיקו שהאשכול שבור.

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

בונים את הרשימה כולה בפקודה אחת

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

az aks show -g rg-app -n aks-prod \
  --query apiServerAccessProfile.authorizedIpRanges -o tsv

az aks update -g rg-app -n aks-prod \
  --api-server-authorized-ip-ranges 203.0.113.10/32,198.51.100.0/24

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

סדרו את השינוי כך שהניסיון המורשה הראשון יהיה גם המבחן. הכריזו על הרשימה החדשה, החילו אותה, והתחברו מה-VPN מיד; עשייה בסדר ההפוך מותירה חלון שבו אף אחד לא יכול להגיע לשרת ה-API כדי לתקן שגיאת הקלדה בבלוק CIDR.

מה רשימת ההיתרים מעולם לא כיסתה

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

אין לה שום קשר לעומסי עבודה. Pods ו-Services ממשיכים לפעול כשהרשימה פעילה, ו-הגעה לאפליקציה דרך ה-VPN היא בעיה נפרדת: Service שיש לו רק IP של אשכול עדיין זקוק למאזן עומסים פנימי, ingress או port-forward לפני שמחשב נייד יכול לפתוח אותו. ערבוב שני התכנונים מייצר כרטיס שינוי שמתיימר להגביל מפתחים ובפועל לא מגביל דבר באפליקציות.

אמתו משני הצדדים, ואז הריצו פעולה אמיתית אחת

בדקו עם לקוח חדש ב-VPN ועם לקוח מחוצה לו. הניסיון מבחוץ אמור להידחות בשרת ה-API, לא בפתרון השמות; אם השם לא נפתר, אתם בודקים DNS ולא למדתם דבר על המסנן. אחר כך הריצו פעולה שאינה קריאת kubectl אינטראקטיבית, כמו הרחבת node pool או בדיקת שדרוג, ואשרו שהיא מסתיימת במקום להניח שכך יהיה.

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