kubectl veikia per VPN, bet AKS nustoja skalėtis: kodėl

Pridedate biuro VPN viešąjį adresą prie AKS API serverio leidžiamų sąrašo, ir kubectl veikia. Po savaitės nepavyksta išplėsti mazgų telkinio, CI užduotis negali pasiekti klasterio, o portale rodoma klaida, kurioje nieko nekalbama apie IP diapazonus. Niekas nepakeitė leidžiamų sąrašo. Įjungta kontrolė yra viešas IP filtras prieš API serverį, ir jis nežino, kas skambina, tik iš kokio adreso ateina iškvietimas. VPN yra vienas iš kelių adresų, kurių klasteriui reikia, ir retai tas, kuris sugenda pirmas.

Leidžiamų sąrašas atitinka adresą, o ne asmenį

--api-server-authorized-ip-ranges priima CIDR blokus, o ne vartotojus ar grupes. Kai kūrėjo užklausa palieka VPN serverį ir keliauja į Azure, šaltinio adresas API serveryje yra VPN serverio viešoji išeiga. Todėl kiekvienas žmogus tame VPN dalijasi vienu įrašu, o bet kas už VPN ribų atmetamas dar prieš prasidedant autentifikacijai.

Tai taip pat reiškia, kad įrašas įleidžia daugiau žmonių, nei galbūt ketinate. Rangovas su VPN prieiga, asmeninis nešiojamasis kompiuteris tame pačiame koncentratoriuje ir pažeista paskyra ateina iš to paties adreso. Klasterio autorizacija nesikeičia, todėl vaidmenimis pagrįsta prieigos kontrolė vis dar sprendžia, ką gali daryti skambinantysis, bet leidžiamų sąrašas nėra tapatybės kontrolė ir niekada neturėtų būti taip apibūdinamas.

Tai, kas sugenda pirmas, paprastai nėra kubectl

Leidžiamų sąrašas taikomas viešajam API serverio galiniam taškui, todėl viskas už išvardytų adresų iškart nustoja veikti. Akivaizdžios aukos yra antrasis biuras be VPN maršruto, CI vykdytojas prieglobos konvejeryje ir nešiojamasis kompiuteris, kuris pamiršo prisijungti. Juos lengva atpažinti, nes laukia žmogus.

Mažiau akivaizdus atvejis yra automatizavimas, kurį valdo Azure arba jūsų pačių įrankiai. Kai kurios platformos inicijuotos operacijos pasiekia API serverį iš adresų, kurie nėra jūsų VPN, ir kai viena iš jų pradeda nepavykti iškart po sąrašo sugriežtinimo, laikas yra užuomina. Nemanome, kad sąrašas pilnas vien todėl, kad interaktyvi prieiga veikia; patikrinkite, ko funkcija reikalauja jūsų regionui ir prenumeratoms, prieš darydami išvadą, kad klasteris sugedęs.

Gedimo parašas padeda. Jei užklausa niekada nepasiekia autentifikacijos, tai filtras. Jei ji autentifikuojama ir tada gauna leidimo klaidą, filtras atliko savo darbą, o problema yra vaidmenimis pagrįsta prieigos kontrolė, kurios leidžiamų sąrašas niekada neliečia.

Sukurkite visą sąrašą viena komanda

Atnaujinimo parametras pakeičia visą sąrašą, o ne prideda įrašą, todėl komanda, kurioje yra tik VPN adresas, tyliai išmeta visa kita. Pirmiausia perskaitykite dabartinę reikšmę, išsaugokite ją ir siųskite sąjungą:

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

Naudokite rezervuotą viešąjį IP VPN serveriui, prieš juo pasikliaudami. Dinaminis adresas pasikeičia prisijungus iš naujo, ir kiekvienas pakeitimas tyliai užrakina komandą už klasterio ribų, kol kas nors atnaujina sąrašą iš dar leidžiamo tinklo. Jei turite du VPN išėjimo taškus dubliavimui, nurodykite abu, nes filtras neturi pageidaujamo kelio sąvokos.

Sudėliokite pakeitimą taip, kad pirmasis leidžiamas bandymas būtų ir testas. Paskelbkite naują sąrašą, pritaikykite jį ir iškart prisijunkite per VPN; atvirkštine tvarka lieka langas, kuriame niekas negali pasiekti API serverio, kad ištaisytų rašybos klaidą CIDR bloke.

Ko leidžiamų sąrašas niekada neapėmė

Jis nepadaro API serverio privataus. Privatus klasteris naudoja privatų galinį tašką ir privatų DNS, o autorizuotų diapazonų sąrašas nėra ta kontrolė, kuri tai pakeičia. Jis taip pat nekeičia to, ką gali daryti įleistas skambinantysis, todėl nutekėjęs administratoriaus kubeconfig vis dar veikia iš bet kurio leidžiamo adreso. Traktuokite prisijungimo duomenis kaip saugumo ribą, o sąrašą kaip tinklo patogumą.

Jis neturi nieko bendra su darbo krūviais. Podai ir paslaugos toliau veikia su įjungtu sąrašu, ir pasiekti programą per VPN yra atskira problema: paslaugai, kuri turi tik klasterio IP, vis tiek reikia vidinio apkrovos balansuotojo, ingress arba port-forward, kol nešiojamasis kompiuteris galės ją atidaryti. Sumaišius šiuos du projektus gaunamas pakeitimo bilietas, kuris teigia ribojantis kūrėjus ir iš tikrųjų nieko programose neriboja.

Patikrinkite iš abiejų pusių, tada atlikite vieną realią operaciją

Išbandykite su nauju klientu VPN ir su klientu už jo ribų. Bandymas iš išorės turėtų būti atmestas API serveryje, o ne vardų sprendime; jei vardas neišsprendžiamas, jūs tikrinate DNS ir nieko nesužinojote apie filtrą. Tada atlikite operaciją, kuri nėra interaktyvus kubectl iškvietimas, pavyzdžiui, mazgų telkinio skalėjimą arba atnaujinimo patikrą, ir patvirtinkite, kad ji baigiama, o ne manykite, kad taip bus.

Užsirašykite ankstesnę sąrašo reikšmę šalia pakeitimo ir po atnaujinimo dar kartą perskaitykite galiojančią reikšmę, o ne pasitikėkite įvesta komanda. AKS autorizuotų IP diapazonų dokumentacija išvardija palaikomus parametrus ir platformos reikalavimus, kurie priklauso tam pačiam sąrašui, o tai dalis, kurią dauguma bilietų aprašymų praleidžia.