Zakaj kubectl deluje prek VPN, a AKS preneha skalirati

Javni naslov pisarniškega VPN dodate na seznam dovoljenih strežnika AKS API in kubectl deluje. Teden pozneje skaliranje node pool-a ne uspe, opravilo CI ne doseže gruče, portal pa prikaže napako, ki ne omenja ničesar o razponih IP. Nihče ni spremenil seznama dovoljenih. Nadzor, ki ste ga omogočili, je javni filter IP pred strežnikom API in ne ve, kdo kliče, le s katerega naslova prihaja klic. VPN je en naslov med več, ki jih gruča potrebuje, in le redko je tisti, ki se zlomi prvi.

Seznam dovoljenih se ujema z naslovom, ne z osebo

--api-server-authorized-ip-ranges sprejema bloke CIDR, ne uporabnikov ali skupin. Ko zahteva razvijalca zapusti strežnik VPN proti Azure, je izvorni naslov na strežniku API javni izhod strežnika VPN. Zato si vsaka oseba na tem VPN deli en vnos, vsakomur zunaj VPN pa je zavrnjen še preden se avtentikacija sploh zgodi.

To pomeni tudi, da vnos spusti več ljudi, kot nameravate. Izvajalec z dostopom VPN, osebni prenosnik na istem koncentratorju in kompromitiran račun vsi prihajajo z istega naslova. Avtorizacija gruče se ne spremeni, zato nadzor dostopa na podlagi vlog še vedno odloča, kaj sme klicatelj storiti, vendar seznam dovoljenih ni nadzor identitete in ga nikoli ne smete opisovati kot takega.

Kar se zlomi prvo, običajno ni kubectl

Seznam dovoljenih velja za javno končno točko strežnika API, zato vse zunaj vaših naštetih naslovov takoj preneha delovati. Očitne žrtve so druga pisarna brez poti VPN, izvajalec CI v gostovani cevovod in prenosnik, ki se je pozabil povezati. Te je zlahka prepoznati, ker človek čaka.

Manj očiten primer je avtomatizacija, ki jo poganjata Azure ali vaša lastna orodja. Nekatere operacije, ki jih sproži platforma, dosežejo strežnik API z naslovov, ki niso vaš VPN, in ko ena od njih začne propadati takoj po zaostritvi seznama, je čas namig. Ne predpostavljajte, da je seznam popoln, ker interaktivni dostop deluje; preverite, kaj funkcija zahteva za vašo regijo in naročnine, preden sklenete, da je gruča pokvarjena.

Podpis okvare pomaga. Če zahteva nikoli ne doseže avtentikacije, je to filter. Če se avtentificira in nato dobi napako dovoljenja, je filter opravil svoje delo in težava je v nadzoru dostopa na podlagi vlog, ki se ga seznam dovoljenih nikoli ne dotakne.

Zgradite celoten seznam z enim ukazom

Parameter za posodobitev zamenja celoten seznam, namesto da bi dodal vnos, zato ukaz, ki nosi le naslov VPN, tiho zavrže vse ostalo, kar je bilo tam. Najprej preberite trenutno vrednost, obdržite jo in pošljite unijo:

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

Za strežnik VPN uporabite rezervirani javni IP, preden se zanesete na to. Dinamični naslov se ob ponovni povezavi spremeni in vsaka sprememba tiho zaklene ekipo izven gruče, dokler nekdo ne posodobi seznama iz omrežja, ki je še dovoljeno. Če imate dve izhodni točki VPN za redundanco, navedite obe, ker filter ne pozna pojma prednostne poti.

Zaporedje spremembe naj bo takšno, da je prvi dovoljeni poskus tudi preizkus. Objavite novi seznam, uporabite ga in se takoj povežite z VPN; če to storite v obratnem vrstnem redu, ostane okno, v katerem nihče ne more doseči strežnika API, da bi popravil tipkarsko napako v bloku CIDR.

Česa seznam dovoljenih ni nikoli zajel

Ne naredi strežnika API zasebnega. Zasebna gruča uporablja zasebno končno točko in zasebni DNS, seznam dovoljenih razponov pa ni nadzor, ki bi to nadomestil. Prav tako ne spremeni, kaj sme sprejeti klicatelj storiti, zato uhajani skrbniški kubeconfig še vedno deluje s katerega koli dovoljenega naslova. Poverilnice obravnavajte kot varnostno mejo, seznam pa kot omrežno udobje.

Nima nič skupnega z delovnimi obremenitvami. Pods in Services delujeta naprej z omogočenim seznamom, in doseganje aplikacije prek VPN je ločena težava: Service, ki ima samo gručni IP, še vedno potrebuje notranji razporejevalnik obremenitve, ingress ali port-forward, preden ga prenosnik lahko odpre. Mešanje teh dveh zasnov ustvari zahtevek za spremembo, ki trdi, da omejuje razvijalce, v resnici pa ne omejuje ničesar pri aplikacijah.

Preverite z obeh strani, nato izvedite eno resnično operacijo

Preizkusite z novim odjemalcem na VPN in z odjemalcem zunaj njega. Poskus od zunaj bi moral biti zavrnjen na strežniku API, ne pri razreševanju imen; če se ime ne razreši, preizkušate DNS in se o filtru niste naučili ničesar. Nato izvedite operacijo, ki ni interaktivni klic kubectl, na primer skaliranje node pool-a ali preverjanje nadgradnje, in potrdite, da se zaključi, namesto da predpostavljate, da se bo.

Prejšnjo vrednost seznama zabeležite ob spremembi in po posodobitvi znova preberite dejansko vrednost, namesto da zaupate vtipkanemu ukazu. dokumentacija AKS o dovoljenih razponih IP navaja podprte parametre in zahteve platforme, ki spadajo na isti seznam, in to je del, ki ga večina opisov zahtevkov izpusti.