De ce kubectl funcționează prin VPN, dar AKS nu mai scalează

Adăugați adresa publică a VPN-ului de birou în lista de permisiuni a serverului AKS API și kubectl funcționează. O săptămână mai târziu, scalarea unui node pool eșuează, un job CI nu poate ajunge la cluster, iar portalul afișează o eroare care nu spune nimic despre intervalele IP. Nimeni nu a modificat lista. Controlul pe care l-ați activat este un filtru IP public în fața serverului API și nu știe cine apelează, doar de la ce adresă vine apelul. VPN-ul este o adresă dintre mai multe de care clusterul are nevoie și rareori este cea care se rupe prima.

Lista de permisiuni potrivește o adresă, nu o persoană

--api-server-authorized-ip-ranges acceptă blocuri CIDR, nu utilizatori sau grupuri. Când cererea unui dezvoltator părăsește serverul VPN spre Azure, adresa sursă la serverul API este ieșirea publică a serverului VPN. De aceea fiecare persoană din acel VPN împarte o singură intrare, iar oricine din afara VPN-ului este refuzat înainte ca autentificarea să aibă loc.

Asta înseamnă și că intrarea admite mai mulți oameni decât intenționați. Un contractant cu acces VPN, un laptop personal pe același concentrator și un cont compromis ajung toate de la aceeași adresă. Autorizarea clusterului nu se schimbă, așa că controlul accesului bazat pe roluri decide în continuare ce poate face apelantul, dar lista de permisiuni nu este un control de identitate și nu ar trebui descrisă niciodată ca atare.

Ce se rupe primul nu este de obicei kubectl

Lista de permisiuni se aplică punctului final public al serverului API, așa că tot ce este în afara adreselor listate încetează să funcționeze imediat. Victimele evidente sunt al doilea birou fără rută VPN, un runner CI într-o conductă găzduită și un laptop care a uitat să se conecteze. Sunt ușor de recunoscut pentru că un om așteaptă.

Cazul mai puțin evident este automatizarea condusă de Azure sau de propriile instrumente. Unele operațiuni inițiate de platformă ajung la serverul API de la adrese care nu sunt VPN-ul dumneavoastră, iar când una dintre ele începe să eșueze imediat după înăsprirea listei, momentul este indiciul. Nu presupuneți că lista este completă pentru că accesul interactiv funcționează; verificați ce cere funcția pentru regiunea și abonamentele dumneavoastră înainte de a concluziona că clusterul este stricat.

Semnătura eșecului ajută. Dacă cererea nu ajunge niciodată la autentificare, este filtrul. Dacă se autentifică și apoi primește o eroare de permisiune, filtrul și-a făcut treaba, iar problema este controlul accesului bazat pe roluri, pe care lista de permisiuni nu îl atinge niciodată.

Construiți întreaga listă într-o singură comandă

Parametrul de actualizare înlocuiește întreaga listă în loc să adauge o intrare, așa că o comandă care poartă doar adresa VPN aruncă în tăcere tot ce era acolo. Citiți mai întâi valoarea curentă, păstrați-o și trimiteți uniunea:

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

Folosiți un IP public rezervat pentru serverul VPN înainte de a vă baza pe asta. O adresă dinamică se schimbă la reconectare, iar fiecare schimbare încuie echipa în afara clusterului până când cineva actualizează lista dintr-o rețea încă permisă. Dacă aveți două puncte de ieșire VPN pentru redundanță, listați-le pe amândouă, pentru că filtrul nu are noțiunea de cale preferată.

Ordonați schimbarea astfel încât prima încercare permisă să fie și testul. Anunțați lista nouă, aplicați-o și conectați-vă imediat din VPN; făcând-o în ordinea inversă rămâne o fereastră în care nimeni nu poate ajunge la serverul API pentru a corecta o greșeală de tastare într-un bloc CIDR.

Ce nu a acoperit niciodată lista de permisiuni

Nu face serverul API privat. Un cluster privat folosește un punct final privat și DNS privat, iar lista intervalelor autorizate nu este controlul care îl înlocuiește. De asemenea, nu schimbă ce poate face un apelant admis, așa că un kubeconfig de administrator scurs funcționează în continuare de la orice adresă permisă. Tratați acreditările ca graniță de securitate și lista ca o comoditate de rețea.

Nu are nimic de-a face cu sarcinile de lucru. Pods și Services continuă să ruleze cu lista activată, iar a ajunge la o aplicație prin VPN este o problemă separată: un Service care are doar un IP de cluster are nevoie în continuare de un balansator de încărcare intern, un ingress sau un port-forward înainte ca un laptop să îl poată deschide. Amestecarea acestor două modele produce un tichet de modificare care pretinde că restricționează dezvoltatorii și, de fapt, nu restricționează nimic la aplicații.

Verificați din ambele părți, apoi rulați o operațiune reală

Testați cu un client nou în VPN și cu un client din afara lui. Încercarea din exterior ar trebui refuzată la serverul API, nu la rezoluția numelor; dacă numele nu se rezolvă, testați DNS și nu ați învățat nimic despre filtru. Apoi rulați o operațiune care nu este un apel kubectl interactiv, cum ar fi o scalare de node pool sau o verificare de actualizare, și confirmați că se finalizează în loc să presupuneți că o va face.

Păstrați valoarea anterioară a listei lângă modificare și recitiți valoarea efectivă după actualizare în loc să vă încredeți în comanda tastată. documentația AKS despre intervalele IP autorizate enumeră parametrii acceptați și cerințele de platformă care aparțin aceleiași liste, iar aceasta este partea pe care majoritatea descrierilor de tichete o omit.