kubectl virker via VPN, men AKS holder op med at skalere: hvorfor

Du tilføjer kontorets VPN-offentlige adresse til AKS API-servers tilladelsesliste, og kubectl virker. En uge senere fejler en opskalering af en nodepulje, et CI-job kan ikke nå klyngen, og portalen viser en fejl, der intet nævner om IP-intervaller. Ingen ændrede tilladelseslisten. Den kontrol, du aktiverede, er et offentligt IP-filter foran API-serveren, og den ved ikke, hvem der ringer, kun hvilken adresse opkaldet kommer fra. VPN er én adresse blandt flere, som klyngen har brug for, og det er sjældent den, der først går i stykker.

Tilladelseslisten matcher en adresse, ikke en person

--api-server-authorized-ip-ranges tager CIDR-blokke, ikke brugere eller grupper. Når en udviklers anmodning forlader VPN-serveren mod Azure, er kildeadressen på API-serveren VPN-serverens offentlige udgang. Derfor deler alle på den VPN én post, og alle uden for VPN'en afvises, før godkendelsen overhovedet begynder.

Det betyder også, at posten lukker flere personer ind, end du måske tilsigter. En underleverandør med VPN-adgang, en personlig bærbar computer på den samme koncentrator og en kompromitteret konto kommer alle fra samme adresse. Klyngens autorisation er uændret, så rollebaseret adgangskontrol afgør stadig, hvad kalderen må gøre, men tilladelseslisten er ikke en identitetskontrol og bør aldrig beskrives som en.

Det, der først går i stykker, er normalt ikke kubectl

Tilladelseslisten gælder API-serverens offentlige slutpunkt, så alt uden for dine angivne adresser holder straks op med at virke. De tydelige ofre er det andet kontor uden VPN-rute, en CI-runner i en hostet pipeline og en bærbar computer, der glemte at oprette forbindelse. De er lette at genkende, fordi et menneske venter.

Det mindre indlysende tilfælde er automatisering, som Azure eller dine egne værktøjer driver. Nogle platformsinitierede handlinger når API-serveren fra adresser, der ikke er din VPN, og når en af dem begynder at fejle lige efter tilladelseslisten er strammet, er tidspunktet ledetråden. Antag ikke, at listen er komplet, fordi interaktiv adgang virker; kontroller, hvad funktionen kræver for din region og dine abonnementer, før du konkluderer, at klyngen er i stykker.

Fejlsignaturen hjælper. Hvis anmodningen aldrig når godkendelsen, er det filteret. Hvis den godkendes og derefter får en tilladelsesfejl, har filteret gjort sit arbejde, og problemet er rollebaseret adgangskontrol, som tilladelseslisten aldrig rører.

Byg hele listen med én kommando

Opdateringsparameteren erstatter hele listen i stedet for at tilføje en post, så en kommando, der kun indeholder VPN-adressen, dropper stille alt andet, der var der. Læs den aktuelle værdi først, behold den, og send foreningen:

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

Brug en reserveret offentlig IP til VPN-serveren, før du stoler på dette. En dynamisk adresse ændres ved genopkobling, og hver ændring låser stille teamet ude af klyngen, indtil nogen opdaterer listen fra et netværk, der stadig er tilladt. Hvis du har to VPN-udgange til redundans, angiv begge, fordi filteret ikke har noget begreb om en foretrukken vej.

Tilretelæg ændringen, så det første tilladte forsøg også er testen. Annoncer den nye liste, anvend den, og opret straks forbindelse fra VPN'en; i omvendt rækkefølge efterlades et vindue, hvor ingen kan nå API-serveren for at rette en tastefejl i en CIDR-blok.

Hvad tilladelseslisten aldrig dækkede

Den gør ikke API-serveren privat. En privat klynge bruger et privat slutpunkt og privat DNS, og listen over autoriserede intervaller er ikke den kontrol, der erstatter det. Den ændrer heller ikke, hvad en tilladt kalder kan gøre, så en lækket admin-kubeconfig virker stadig fra enhver tilladt adresse. Behandl legitimationsoplysningen som sikkerhedsgrænsen og listen som en netværksbekvemmelighed.

Den har intet med arbejdsbelastninger at gøre. Pods og tjenester kører videre med listen aktiveret, og at nå en applikation over VPN er et separat problem: en tjeneste, der kun har en klynge-IP, har stadig brug for en intern load balancer, en ingress eller en port-forward, før en bærbar computer kan åbne den. At blande de to design giver en ændringsbillet, der hævder at begrænse udviklere og i virkeligheden ikke begrænser noget af applikationerne.

Kontroller fra begge sider, og kør derefter én rigtig handling

Test med en ny klient på VPN'en og med en klient uden for den. Forsøget udefra bør afvises ved API-serveren, ikke ved navneopslag; hvis navnet ikke slås op, tester du DNS og har ikke lært noget om filteret. Kør derefter en handling, der ikke er et interaktivt kubectl-kald, såsom en nodepuljes skalering eller en opgraderingskontrol, og bekræft, at den fuldføres i stedet for at antage det.

Noter den tidligere listeværdi ved siden af ændringen, og læs den gældende værdi igen efter opdateringen i stedet for at stole på kommandoen, der blev skrevet. dokumentationen for AKS' autoriserede IP-intervaller viser de understøttede parametre og de platformskrav, der hører i samme liste, hvilket er den del, de fleste billetbeskrivelser udelader.