EKS API’ni VPN orqasiga qo‘yish: operatsiyalar tartibi

Xususiy endpoint’ni yoqing, kubectl unga yetib kelganini isbotlang, so‘ngra ommaviy endpoint’ni yoping. Har bir qadam orasidagi buyruqlar va tekshiruvlar bilan bosqichma-bosqich runbook.

Bu o‘zgarishning xavfli varianti — endpoint’ni aylantirib, barcha administratorlarni bir vaqtda bloklaydigan bitta buyruq. Xavfsiz variant ikkala yo‘lni ham ochiq saqlaydi, xususiy yo‘l VPN’dan ishlashini isbotlaydi va shundan keyingina ommaviy endpoint’ni foydalanishdan chiqaradi. Mavjud klaster, uning VPC’siga tasdiqlangan tunnel va allaqachon ishlayotgan kubeconfig bor deb hisoblang; vazifa Kubernetes API’ga xususiy kirish, xususiy nodelar ham, yangi ruxsat modeli ham emas. Quyidagi har bir qadamda xavfsiz muvaffaqiyatsiz bo‘lish mumkin bo‘lgan tekshiruv bor.

1. Endpoint’ni inventarizatsiya qiling va qaytish yo‘lini saqlang

O‘zgartirishdan oldin joriy holatni yozib oling, jumladan ommaviy CIDR ruxsat ro‘yxati va klaster xavfsizlik guruhi. Biror narsa ishlamay qolganda aynan shu ikkitasini solishtirasiz, xususiy marshrut noto‘g‘ri bo‘lib chiqsa, ruxsat ro‘yxati ham orqaga qaytish yo‘lingizdir.

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

Bu yerda REGION va CLUSTER o‘rin egallovchilardir. Xususiy bayroq hozir nima ko‘rsatayotganiga e’tibor bering, chunki xususiy kirish allaqachon yoqilgan holda yaratilgan klaster hech qachon bo‘lmagan klasternikidan boshqacha birinchi qadam talab qiladi. O‘tish davrida kamida bitta tasdiqlangan ma’muriy yo‘lni ochiq saqlang; ayni klaster yetib borishiga bog‘liq VPN tiklash yo‘li emas.

2. Tarmoq yo‘li tayyor bo‘lganda xususiy kirishni yoqing

Bayroqni yoqish — oson yarmi. Tunnel endpoint’ning xususiy manzillariga marshrut talab qiladi, klaster xavfsizlik guruhi esa VPN haqiqatda taqdim etadigan manbadan TCP 443 talab qiladi. Client VPN birlashmasi, sayt-sayt shlyuzi va peer qilingan VPC har xil manba manzillarini taqdim etishi mumkin, shuning uchun umumiy xususiy diapazon o‘rniga o‘zingiz joylashtirgan modeldan foydalaning.

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

Yangilanish asinxrondir. Belgilangan soniya kutib taxmin qilish o‘rniga yangilanish id’si muvaffaqiyat haqida xabar berguncha so‘rang. Buni qilayotganda node va boshqaruv tekisligi trafigini yolg‘iz qoldiring: klasterning butun xavfsizlik guruhini noutbukungiz uchun qoida bilan almashtirish ishlayotgan ma’lumot tekisligini ikkinchi hodisaga aylantirish yo‘lidir.

EKS endpoint’lari hujjatlari bir marta to‘liq o‘qishga arziydi, chunki ularda faqat xususiy kirish VPC yoki ulangan tarmoqdan kelishi mumkinligi aytilgan. Aynan o‘sha gap bu migratsiyaning mumkin bo‘lishining butun sababi va keyingi qadam borligining sababi ham.

3. Ish stansiyasi xususiy yo‘ldan foydalanganini isbotlang

Ikkala endpoint yoqilganda muvaffaqiyatli kubectl get ns qaysi biri javob bergani haqida hech narsani isbotlamaydi. Endpoint’ning host nomini hal qiling va olingan manzil xususiy yoki ommaviy diapazonga tegishli ekanini tekshiring. Agar ulangan tarmog‘ingiz DNS orqali xususiy ko‘rinishni olmasa, buyruq ommaviy endpoint orqali muvaffaqiyatli bo‘ladi va siz yolg‘on dalillarga asoslanib ommaviy yo‘lni foydalanishdan chiqarasiz. Bu migratsiyaning noto‘g‘ri ketishining eng keng tarqalgan yo‘li bo‘lib, u muvaffaqiyatga aynan o‘xshaydi.

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

Host nomi va sertifikat tekshiruvini bor holida qoldiring. kubeconfig’da xususiy IP qo‘yish va TLS tekshiruvini o‘tkazib yuborish siz o‘zgarish yozuvida tasvirlagan migratsiya emas va endpoint aylangan paytda u yana muvaffaqiyatsiz bo‘ladi.

4. Ommaviy kirishni ataylab foydalanishdan chiqaring

Xususiy yo‘l isbotlanib, tiklash jarayoni tasdiqlangach, ommaviy endpoint’ni yoping. Bu ko‘rish emas, haqiqiy o‘zgarish, shuning uchun uni haqiqatan nazarda tutgan hisob va sozlamalarda bajaring.

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

Faqat xususiy rejimda ommaviy DNS nomi VPC ichidan endpoint’ning xususiy manzillariga hal qilinadi, shuning uchun hal qilish va yetib borish endi bir narsa emas. Ommaviy manzilga tayangan hamma narsa, jumladan CI ishga tushirgichlari yoki boshqa tarmoqdagi noutbuk, endi o‘zining kirish yo‘lini talab qiladi.

5. Tarmoq siyosati va identifikatsiya siyosatini alohida saqlang

Ommaviy kirish CIDR ro‘yxati faqat ommaviy endpoint’ni boshqaradi. U xususiy endpoint’ni cheklamaydi, uni buning o‘rniga klaster xavfsizlik guruhi va ulangan tarmoq siyosati cheklaydi. Agar ommaviy endpoint’ni saqlasangiz, uning ruxsat ro‘yxati API mijozlaringiz va nodelaringiz haqiqatda ishlatadigan ommaviy chiqishga mos kelishi kerak; VPN puli manzili bu manba bo‘lishi kamdan-kam.

Bularning hech biri IAM yoki Kubernetes RBAC’ni o‘zgartirmaydi. Endpoint sozlamalari ma’muriy harakat, oddiy foydalanuvchilar esa faqat API’ga yetish uchun chegarani yumshatish ruxsatini olmasligi kerak. Yakuniy holat, sana va tiklash yo‘lini runbook’ka yozing, so‘ngra hali oson bo‘lganda tiklash yo‘lini bir marta sinab ko‘ring.

O'xshash maqolalar