Zergatik dabil kubectl VPN bidez baina AKS eskalatzeaz uzten du

Bulegoko VPNaren helbide publikoa AKS API zerbitzariaren baimenduen zerrendan gehitzen duzu, eta kubectl dabil. Astebete geroago node pool baten eskalatzeak huts egiten du, CI lan batek ezin du klusterra heldu, eta atariak IP tarteez ezer esaten ez duen errore bat erakusten du. Inork ez zuen zerrenda aldatu. Gaitu duzun kontrola API zerbitzariaren aurrean dagoen IP iragazki publikoa da, eta ez daki nork deitzen duen, soilik deia zein helbidetatik etorri den. VPN klusterrak behar dituen hainbat helbideren artean bat da, eta gutxitan da lehenengo apurtzen dena.

Baimenduen zerrendak helbide batekin egiten du bat, ez pertsonarekin

--api-server-authorized-ip-ranges CIDR blokeak onartzen ditu, ez erabiltzaileak edo taldeak. Garatzaile baten eskaerak VPN zerbitzaria utzi eta Azure aldera doanean, API zerbitzariko iturburu helbidea VPN zerbitzariaren irteera publikoa da. Beraz, VPN horretako pertsona bakoitzak sarrera bakarra partekatzen du, eta VPNtik kanpo dagoen edonori ukatzen zaio autentifikazioa gertatu aurretik ere.

Horrek esan nahi du sarrerak zuk nahi baino jende gehiago onartzen duela. VPN sarbidea duen kontratista bat, kontzentratzaile berean dagoen ordenagailu eramangarri pertsonal bat eta konprometitutako kontu bat helbide beretik iristen dira. Klusterraren autorizazioa ez da aldatu, beraz roletan oinarritutako sarbide-kontrolak erabakitzen du oraindik deitzaileak zer egin dezakeen, baina baimenduen zerrenda ez da identitate-kontrol bat eta ez litzateke inoiz hala deskribatu behar.

Lehenengo apurtzen dena normalean ez da kubectl

Baimenduen zerrenda API zerbitzariaren amaiera-puntu publikorako da, beraz zerrendatutako helbideetatik kanpo dagoen guztia berehala uzten du funtzionatzen. Biktima nabarmenak VPN ibilbiderik gabeko bigarren bulegoa, ostatutako pipeline bateko CI exekutatzailea eta konektatzeko ahaztu zuen ordenagailu eramangarri bat dira. Hauek erraz ezagutzen dira norbait itxaroten ari delako.

Kasurik nabarmenen ez dena Azurek edo zure tresnek bultzatutako automatizazioa da. Plataformak abiarazitako eragiketa batzuk ez diren zure VPNeko helbideetatik iristen dira API zerbitzarira, eta horietako bat zerrenda estutu eta berehala huts egiten hasten denean, denbora da arrastoa. Ez ezazu pentsatu zerrenda osoa den sarbide interaktiboak funtzionatzen duelako; egiaztatu eginbideak zure eskualde eta harpidetzetarako zer eskatzen duen, klusterra hondatuta dagoela ondorioztatu aurretik.

Hutsaren sinadurak laguntzen du. Eskaerak autentifikaziora inoiz iristen ez bada, iragazkia da. Autentifikatu eta gero baimen-errore bat jasotzen badu, iragazkiak bere lana egin du eta arazoa roletan oinarritutako sarbide-kontrolean dago, eta baimenduen zerrendak ez dio inoiz ukitzen.

Eraiki zerrenda osoa komando bakarrean

Eguneratzeko parametroak zerrenda osoa ordezkatzen du sarrera bat gehitu beharrean, beraz VPN helbidea bakarrik daraman komando batek isil-isilik baztertzen du han zegoen guztia. Irakurri lehenago uneko balioa, gorde ezazu, eta bidali batasuna:

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

Erabili erreserbatutako IP publiko bat VPN zerbitzariarentzat honetan oinarritu aurretik. Helbide dinamikoak berkonektatzean aldatzen dira, eta aldaketa bakoitzak isil-isilik taldea klusterretik kanpo uzten du, norbaitek oraindik baimenduta dagoen sare batetik zerrenda eguneratu arte. Erredundantziarako bi VPN irteera-puntu badituzu, zerrendatu biak, iragazkiak ez baitu bide hobetsiaren kontzepturik.

Ordenatu aldaketa lehen baimendutako saiakera proba ere izan dadin. Iragarri zerrenda berria, aplikatu, eta konektatu VPNtik berehala; alderantziz eginez gero, inork CIDR bloke bateko tipografia-akats bat konpontzeko API zerbitzarira iritsi ezin den leiho bat uzten da.

Baimenduen zerrendak inoiz estali ez zuena

Ez du API zerbitzaria pribatu egiten. Kluster pribatu batek amaiera-puntu pribatua eta DNS pribatua erabiltzen ditu, eta baimendutako tarteen zerrenda ez da hura ordezkatzen duen kontrola. Ez du ere aldatzen onartutako deitzaile batek zer egin dezakeen, beraz filtratutako admin kubeconfig batek oraindik funtzionatzen du baimendutako edozein helbidetatik. Hartu kredentziala segurtasun-muga gisa eta zerrenda sare-erraztasun gisa.

Ez du zerikusirik lan-kargekin. Pods eta Services martxan jarraitzen dute zerrenda gaituta dagoela, eta VPN bidez aplikazio bat heltzea arazo bereizia da: kluster IP bat soilik duen Service batek oraindik barneko karga-balantzatzaile bat, ingress bat edo port-forward bat behar du ordenagailu eramangarri batek ireki ahal izateko. Bi diseinu horiek nahasteak garatzaileak murrizten dituela dioen aldaketa-txartel bat sortzen du, eta egia esan aplikazioei buruz ezer ez du murrizten.

Egiaztatu bi aldeetatik, eta gero exekutatu eragiketa erreal bat

Probatu VPNko bezero berri batekin eta kanpoko bezero batekin. Kanpoko saiakera API zerbitzarian ukatua izan beharko litzateke, ez izen-ebazpenean; izena ebazten ez bada, DNS probatzen ari zara eta ez duzu ezer ikasi iragazkiari buruz. Gero exekutatu kubectl dei interaktiboa ez den eragiketa bat, hala nola node pool baten eskalatzea edo bertsio-berritze egiaztapen bat, eta berretsi osatzen dela pentsatu beharrean.

Gorde aurreko zerrenda-balioa aldaketaren ondoan, eta irakurri berriro balio eraginkorra eguneratu ondoren, idatzitako komandoan fidatu beharrean. AKSren baimendutako IP tarteen dokumentazioak onartutako parametroak eta zerrenda berean dauden plataformaren baldintzak zerrendatzen ditu, eta hori da txartel-deskribapen gehienek uzten duten zatia.