לשים את ה-API של EKS מאחורי VPN: סדר הפעולות

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

1. למפות את נקודת הקצה ולהשאיר דרך חזרה

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

aws eks describe-cluster --region REGION --name CLUSTER \
  --query 'cluster.{endpoint:endpoint,public:resourcesVpcConfig.endpointPublicAccess,private:resourcesVpcConfig.endpointPrivateAccess,cidrs:resourcesVpcConfig.publicAccessCidrs}'

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

2. להפעיל גישה פרטית כשנתיב הרשת כבר קיים

הדלקת הדגל היא החצי הקל. המנהרה זקוקה לנתיב לכתובות הפרטיות של נקודת הקצה, וקבוצת האבטחה של הקלאסטר זקוקה ל-TCP 443 מהמקור שה-VPN מציג בפועל. שיוך Client VPN, שער site-to-site ו-VPC מקושר יכולים כולם להציג כתובות מקור שונות, לכן השתמשו במודל שפרסתם ולא בטווח פרטי גנרי.

aws eks update-cluster-config --region REGION --name CLUSTER \
  --resources-vpc-config endpointPublicAccess=true,endpointPrivateAccess=true

aws eks describe-update --region REGION --name CLUSTER --update-id UPDATE_ID

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

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

3. להוכיח שתחנת העבודה השתמשה בנתיב הפרטי

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

nslookup HASH.gr7.REGION.eks.amazonaws.com
kubectl cluster-info
kubectl get ns --request-timeout=10s

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

4. להפסיק את הגישה הציבורית במכוון

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

aws eks update-cluster-config --region REGION --name CLUSTER \
  --resources-vpc-config endpointPublicAccess=false,endpointPrivateAccess=true

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

5. להפריד בין מדיניות הרשת למדיניות הזהות

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

שום דבר מזה לא משנה IAM או Kubernetes RBAC. הגדרות נקודת הקצה הן פעולה מנהלית, ומשתמשים רגילים לא צריכים לקבל הרשאה להקל על הגבול רק כדי להגיע ל-API. כתבו את המצב הסופי, התאריך ונתיב השחזור בספר הריצה, ואז בדקו את נתיב השחזור פעם אחת כשעוד קל.