kubectl werkt via de VPN, maar AKS stopt met schalen: waarom

U voegt het openbare adres van de kantoor-VPN toe aan de acceptatielijst van de AKS-API-server, en kubectl werkt. Een week later mislukt het opschalen van een knooppuntpool, een CI-taak bereikt het cluster niet en de portal toont een fout die niets over IP-bereiken zegt. Niemand heeft de acceptatielijst gewijzigd. De beheerlaag die u hebt ingeschakeld is een openbaar IP-filter voor de API-server, en hij weet niet wie er belt, alleen van welk adres het gesprek komt. De VPN is één adres van de verschillende die het cluster nodig heeft, en het is zelden het adres dat als eerste breekt.

De acceptatielijst koppelt een adres, geen persoon

--api-server-authorized-ip-ranges neemt CIDR-blokken, geen gebruikers of groepen. Wanneer een verzoek van een ontwikkelaar de VPN-server verlaat richting Azure, is het bronadres op de API-server de openbare uitgang van de VPN-server. Iedereen op die VPN deelt dus één vermelding, en wie niet op de VPN zit, wordt geweigerd voordat authenticatie zelfs maar begint.

Dat betekent ook dat de vermelding meer mensen toelaat dan u misschien bedoelt. Een contractor met VPN-toegang, een persoonlijke laptop op dezelfde concentrator en een gecompromitteerd account komen allemaal van hetzelfde adres. De clusterautorisatie verandert niet, dus op rollen gebaseerde toegangscontrole beslist nog steeds wat de aanroeper mag doen, maar de acceptatielijst is geen identiteitscontrole en mag nooit als zodanig worden beschreven.

Wat het eerst breekt, is meestal niet kubectl

De acceptatielijst geldt voor het openbare eindpunt van de API-server, dus alles buiten uw vermelde adressen werkt onmiddellijk niet meer. De duidelijke slachtoffers zijn het tweede kantoor zonder VPN-route, een CI-runner in een gehoste pijplijn en een laptop die vergat verbinding te maken. Die zijn makkelijk te herkennen omdat er een mens wacht.

Het minder voor de hand liggende geval is automatisering die Azure of uw eigen tooling aanstuurt. Sommige door het platform gestarte bewerkingen bereiken de API-server vanaf adressen die niet uw VPN zijn, en wanneer een daarvan meteen na het aanscherpen van de lijst begint te falen, is de timing de aanwijzing. Ga er niet van uit dat de lijst compleet is omdat interactieve toegang werkt; controleer wat de functie voor uw regio en abonnementen vereist voordat u concludeert dat het cluster stuk is.

De faalhandtekening helpt. Als het verzoek nooit bij de authenticatie komt, is het filter de oorzaak. Als het authenticeert en daarna een machtigingsfout krijgt, heeft het filter zijn werk gedaan en is het probleem op rollen gebaseerde toegangscontrole, die de acceptatielijst nooit raakt.

Bouw de hele lijst in één opdracht

De updateparameter vervangt de hele lijst in plaats van een vermelding toe te voegen, dus een opdracht die alleen het VPN-adres bevat, laat stilzwijgend al het andere vallen. Lees eerst de huidige waarde, houd die vast en stuur de vereniging:

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 een gereserveerd openbaar IP voor de VPN-server voordat u hierop vertrouwt. Een dynamisch adres verandert bij opnieuw verbinden, en elke wijziging sluit het team stilletjes buiten het cluster tot iemand de lijst bijwerkt vanaf een netwerk dat nog is toegestaan. Als u twee VPN-uitgangen voor redundantie hebt, vermeld ze dan beide, want het filter kent geen voorkeurspad.

Plan de wijziging zo dat de eerste toegestane poging ook de test is. Kondig de nieuwe lijst aan, pas hem toe en verbind meteen vanaf de VPN; in de omgekeerde volgorde blijft er een venster waarin niemand de API-server kan bereiken om een typefout in een CIDR-blok te herstellen.

Wat de acceptatielijst nooit dekte

Hij maakt de API-server niet privé. Een privécluster gebruikt een privé-eindpunt en privé-DNS, en de lijst met geautoriseerde bereiken is niet de beheerlaag die dat vervangt. Hij verandert ook niet wat een toegelaten aanroeper kan doen, dus een uitgelekt admin-kubeconfig werkt nog steeds vanaf elk toegestaan adres. Behandel de referentie als de beveiligingsgrens en de lijst als netwerkgemak.

Hij heeft niets met workloads te maken. Pods en services blijven draaien met de lijst ingeschakeld, en een toepassing via de VPN bereiken is een apart probleem: een service met alleen een cluster-IP heeft nog steeds een interne load balancer, een ingress of een port-forward nodig voordat een laptop hem kan openen. Het mengen van die twee ontwerpen levert een wijzigingsticket op dat claimt ontwikkelaars te beperken en in werkelijkheid niets aan de toepassingen beperkt.

Controleer vanaf beide kanten en voer daarna één echte bewerking uit

Test met een nieuwe client op de VPN en met een client daarbuiten. De poging van buitenaf moet bij de API-server worden geweigerd, niet bij naamresolutie; als de naam niet wordt opgelost, test u DNS en hebt u niets over het filter geleerd. Voer daarna een bewerking uit die geen interactieve kubectl-aanroep is, zoals een knooppuntpool opschalen of een upgradecontrole, en bevestig dat die voltooit in plaats van het aan te nemen.

Leg de vorige lijstwaarde naast de wijziging vast en lees na de update de effectieve waarde opnieuw in plaats van de getypte opdracht te vertrouwen. De documentatie over geautoriseerde IP-bereiken van AKS vermeldt de ondersteunde parameters en de platformvereisten die in dezelfde lijst horen, wat het deel is dat de meeste ticketbeschrijvingen weglaten.