Waarom kubectl oor die VPN werk maar AKS ophou skaleer

Jy voeg die kantoor se VPN openbare adres by die AKS API-bediener se toelaatlys, en kubectl werk. ’n Week later misluk ’n nodepoel-uitskaal, ’n CI-werk kan nie die cluster bereik nie, en die portaal wys ’n fout wat niks oor IP-reekse sê nie. Niemand het die toelaatlys verander nie. Die beheer wat jy geaktiveer het, is ’n openbare IP-filter voor die API-bediener, en dit weet nie wie bel nie, net watter adres die oproep vandaan kom. Die VPN is een adres onder verskeie wat die cluster nodig het, en dit is selde die een wat eerste breek.

Die toelaatlys pas by ’n adres, nie ’n persoon nie

--api-server-authorized-ip-ranges neem CIDR-blokke, nie gebruikers of groepe nie. Wanneer ’n ontwikkelaar se versoek die VPN-bediener na Azure verlaat, is die bronadres by die API-bediener die VPN-bediener se openbare uitgang. Elke persoon op daardie VPN deel dus een inskrywing, en enigiemand buite die VPN word geweier nog voordat verifikasie plaasvind.

Dit beteken ook dat die inskrywing meer mense toelaat as wat jy bedoel. ’n Kontrakteur met VPN-toegang, ’n persoonlike skootrekenaar op dieselfde konsentrator en ’n gekompromitteerde rekening kom almal van dieselfde adres. Cluster-magtiging bly onveranderd, so rolgebaseerde toegangsbeheer besluit steeds wat die oproeper mag doen, maar die toelaatlys is nie ’n identiteitsbeheer nie en moet nooit so beskryf word nie.

Wat eerste breek, is gewoonlik nie kubectl nie

Die toelaatlys geld vir die API-bediener se openbare eindpunt, so enigiets buite jou gelyste adresse hou dadelik op werk. Die ooglopende slagoffers is die tweede kantoor sonder ’n VPN-roete, ’n CI-loper in ’n gehoste pyplyn en ’n skootrekenaar wat vergeet het om te koppel. Dié is maklik om te herken omdat ’n mens daarop wag.

Die minder ooglopende geval is outomatisering wat Azure of jou eie gereedskap aandryf. Sommige platform-geïnisieerde bewerkings bereik die API-bediener vanaf adresse wat nie jou VPN is nie, en wanneer een van hulle kort ná die verskerping van die lys begin misluk, is die tydsberekening die leidraad. Moenie aanvaar die lys is volledig omdat interaktiewe toegang werk nie; kyk wat die funksie vir jou streek en intekeninge vereis voordat jy aflei die cluster is stukkend.

Die foutpatroon help. As die versoek nooit verifikasie bereik nie, is dit die filter. As dit verifieer en dan ’n toestemmingsfout kry, het die filter sy werk gedoen en is die probleem rolgebaseerde toegangsbeheer, wat die toelaatlys nooit raak nie.

Bou die hele lys in een opdrag

Die opdateringsparameter vervang die hele lys in plaas van om ’n inskrywing by te voeg, so ’n opdrag wat net die VPN-adres dra, laat alles anders wat daar was stilweg val. Lees eers die huidige waarde, hou dit, en stuur die unie:

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

Gebruik ’n gereserveerde openbare IP vir die VPN-bediener voordat jy hierop staatmaak. ’n Dinamiese adres verander by heraansluiting, en elke verandering sluit die span stilweg uit die cluster totdat iemand die lys opdateer vanaf ’n netwerk wat nog toegelaat word. As jy twee VPN-uitgange vir oorbodigheid het, lys albei, want die filter het geen begrip van ’n voorkeurpad nie.

Rangskik die verandering so dat die eerste toegelate poging ook die toets is. Kondig die nuwe lys aan, pas dit toe en koppel dadelik vanaf die VPN; om dit in die ander volgorde te doen, laat ’n venster waarin niemand die API-bediener kan bereik om ’n tikfout in ’n CIDR-blok reg te maak nie.

Wat die toelaatlys nooit gedek het nie

Dit maak nie die API-bediener privaat nie. ’n Privaat cluster gebruik ’n privaat eindpunt en privaat DNS, en die gemagtigde-reekse-lys is nie die beheer wat dit vervang nie. Dit verander ook nie wat ’n toegelate oproeper mag doen nie, so ’n uitgelekte admin-kubeconfig werk steeds vanaf enige toegelate adres. Beskou die geloofsbrief as die sekuriteitsgrens en die lys as ’n netwerkgerief.

Dit het niks met werklading te doen nie. Pods en Services bly werk met die lys geaktiveer, en om ’n toepassing oor die VPN te bereik is ’n aparte probleem: ’n Service met net ’n cluster-IP het steeds ’n interne lasbalanseerder, ’n ingress of ’n port-forward nodig voordat ’n skootrekenaar dit kan oopmaak. Om daardie twee ontwerpe te meng lewer ’n veranderingskaartjie op wat beweer dit beperk ontwikkelaars en eintlik niks aan die toepassings beperk nie.

Verifieer van beide kante, en voer dan een werklike bewerking uit

Toets met ’n nuwe kliënt op die VPN en met ’n kliënt buite dit. Die poging van buite moet by die API-bediener geweier word, nie by naamresolusie nie; as die naam nie oplos nie, toets jy DNS en het jy niks oor die filter geleer nie. Voer dan een bewerking uit wat nie ’n interaktiewe kubectl-oproep is nie, soos ’n nodepoel-uitskaal of ’n opgraderingstoets, en bevestig dat dit voltooi in plaas daarvan om aan te neem dit sal.

Hou die vorige lyswaarde langs die verandering aangeteken, en lees die effektiewe waarde ná die opdatering weer eerder as om die opdrag wat getik is te vertrou. Die AKS-dokumentasie oor gemagtigde IP-reekse lys die ondersteunde parameters en die platformvereistes wat in dieselfde lys hoort, wat die deel is wat die meeste kaartjiebeskrywings uitlaat.