Hvers vegna kubectl virkar í gegnum VPN en AKS hættir að stækka

Þú bætir opinberu vistfangi skrifstofu-VPN-sins við leyfðan lista AKS API-þjónsins, og kubectl virkar. Viku síðar mistekst stækkun node pool, CI-vinna nær ekki klasanum, og gáttin sýnir villu sem nefnir ekkert um IP-svið. Enginn breytti leyfða listanum. Stjórnin sem þú virkjaðir er opinbert IP-sía fyrir framan API-þjóninn, og hún veit ekki hver er að hringja, aðeins frá hvaða vistfangi kallið kom. VPN er eitt vistfang af nokkrum sem klasinn þarf, og það er sjaldan það sem brotnar fyrst.

Leyfði listinn passar við vistfang, ekki manneskju

--api-server-authorized-ip-ranges tekur CIDR-blokkir, ekki notendur eða hópa. Þegar beiðni forritara yfirgefur VPN-þjóninn til Azure er upprunavistfangið hjá API-þjóninum opinber útgangur VPN-þjónsins. Þess vegna deilir hver maður á því VPN einni færslu, og hver sem er utan VPN er hafnað áður en auðkenning á sér stað.

Það þýðir líka að færslan hleypir fleiri inn en þú ætlaðir. Verktaki með VPN-aðgang, einkatölva á sama safnara, og stolið reikningur koma öll frá sama vistfangi. Heimild klasans er óbreytt, svo aðgangsstýring byggð á hlutverkum ræður enn hvað símtalandi má gera, en leyfði listinn er ekki auðkennisstýring og ætti aldrei að vera lýst sem slíkri.

Það sem brotnar fyrst er venjulega ekki kubectl

Leyfði listinn gildir um opinbert endapunkt API-þjónsins, svo allt utan skráðra vistfanga hættir að virka samstundis. Augljósu fórnarlömbin eru önnur skrifstofan án VPN-leiðar, CI-keyrsla í hýstri pípu, og tölva sem gleymdi að tengjast. Þau eru auðþekkjanleg vegna þess að manneskja bíður.

Síst augljósa tilfellið er sjálfvirkni sem Azure eða eigin verkfæri þín keyra. Sumar aðgerðir sem kerfið hefur frumkvæði að ná til API-þjónsins frá vistföngum sem eru ekki VPN-ið þitt, og þegar ein þeirra byrjar að mistakast rétt eftir að listinn er hertur er tímasetningin vísbendingin. Ekki gera ráð fyrir að listinn sé fullkominn af því að gagnvirkur aðgangur virkar; athugaðu hvað eiginleikinn krefst fyrir héraðið og áskriftirnar þínar áður en þú ályktar að klasinn sé biluð.

Bilunareinkennið hjálpar. Ef beiðnin nær aldrei til auðkenningar er það sían. Ef hún auðkennist og fær síðan heimildarvillu hefur sían gert sitt og vandamálið er aðgangsstýring byggð á hlutverkum, sem leyfði listinn snertir aldrei.

Byggðu allan listann með einni skipun

Uppfærslubreytan kemur í stað alls listans í stað þess að bæta við færslu, svo skipun sem ber aðeins VPN-vistfangið sleppir hljóðlega öllu öðru sem var þar. Lestu núgildið fyrst, haltu því, og sendu sambandið:

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

Notaðu frátekið opinbert IP fyrir VPN-þjóninn áður en þú treystir á þetta. Kvikt vistfang breytist við endurtengingu, og sérhver breyting lokar liðinu hljóðlega úti úr klasanum þar til einhver uppfærir listann frá neti sem er enn leyft. Ef þú hefur tvo VPN-útganga fyrir varasjóð skaltu skrá báða, því sían hefur enga hugmynd um æskilega leið.

Raðaðu breytingunni þannig að fyrsta leyfða tilraunin sé líka prófið. Tilkynntu nýja listann, beittu honum, og tengstu VPN-inu samstundis; að gera það í hinni röðinni skilur eftir glugga þar sem enginn kemst að API-þjóninum til að laga prentvillu í CIDR-blokki.

Það sem leyfði listinn huldi aldrei

Hann gerir API-þjóninn ekki einkarekinn. Einkaklasi notar einkanlegan endapunkt og einkanlegt DNS, og listi heimilaðra sviða er ekki stjórnin sem kemur í staðinn fyrir hann. Hann breytir heldur ekki því hvað leyfður símtalandi má gera, svo lekið admin-kubeconfig virkar enn frá hvaða leyfðu vistfangi sem er. Líttu á skírteinið sem öryggismörkin og listann sem netþægindi.

Hann hefur ekkert með vinnuálag að gera. Pods og Services halda áfram að keyra með listann virkan, og að ná í forrit í gegnum VPN er sérstakt vandamál: Service sem hefur aðeins klasa-IP þarf enn innri hleðsludreifir, ingress eða port-forward áður en tölva getur opnað það. Að blanda þessum tveimur hönnunum framleiðir breytingamiða sem fullyrðir að takmarka forritara og takmarkar í raun ekkert í forritunum.

Sannprófaðu frá báðum hliðum og keyrðu svo eina raunverulega aðgerð

Prófaðu með nýjum biðlara á VPN-inu og biðlara utan þess. Tilkallið utan frá ætti að vera hafnað hjá API-þjóninum, ekki við nafnaupplausn; ef nafnið leysist ekki, ertu að prófa DNS og hefur ekkert lært um síuna. Keyrðu síðan aðgerð sem er ekki gagnvirk kubectl-kall, eins og stækkun node pool eða athugun uppfærslu, og staðfestu að henni ljúki í stað þess að gera ráð fyrir því.

Skráðu fyrra gildi listans við breytinguna, og lestu virka gildið aftur eftir uppfærsluna í stað þess að treysta skipuninni sem var slegin inn. AKS-skjöl um leyfð IP-svið telja upp studdar breytur og kröfur kerfisins sem tilheyra sama lista, og það er hlutinn sem flestar miðalýsingar sleppa.