kubectl fungerar över VPN, men AKS slutar skala: varför

Du lägger till kontorets VPN offentliga adress i AKS API-servers tillåtelselista, och kubectl fungerar. En vecka senare misslyckas en uppskalning av en nodpool, ett CI-jobb når inte klustret och portalen visar ett fel som inte nämner något om IP-intervall. Ingen ändrade tillåtelselistan. Kontrollen du aktiverade är ett offentligt IP-filter framför API-servern, och det vet inte vem som ringer, bara från vilken adress anropet kommer. VPN är en av flera adresser som klustret behöver, och det är sällan den som går sönder först.

Tillåtelselistan matchar en adress, inte en person

--api-server-authorized-ip-ranges tar CIDR-block, inte användare eller grupper. När en utvecklares begäran lämnar VPN-servern mot Azure är källadressen på API-servern VPN-serverns offentliga utgång. Varje person på det VPN:et delar därför en enda post, och den som är utanför VPN:et nekas innan autentiseringen ens börjar.

Det betyder också att posten släpper in fler personer än du kanske avser. En entreprenör med VPN-åtkomst, en privat laptop på samma koncentrator och ett komprometterat konto kommer alla från samma adress. Klusterauktoriseringen är oförändrad, så rollbaserad åtkomstkontroll avgör fortfarande vad anroparen får göra, men tillåtelselistan är inte en identitetskontroll och bör aldrig beskrivas som en sådan.

Det som går sönder först är vanligtvis inte kubectl

Tillåtelselistan gäller API-serverns offentliga slutpunkt, så allt utanför dina listade adresser slutar fungera direkt. De uppenbara offren är det andra kontoret utan VPN-rutt, en CI-körare i en värdbaserad pipeline och en laptop som glömde ansluta. De är lätta att känna igen eftersom en människa väntar.

Det mindre uppenbara fallet är automatisering som Azure eller dina egna verktyg driver. Vissa plattformsinitierade åtgärder når API-servern från adresser som inte är ditt VPN, och när en av dem börjar misslyckas direkt efter att listan skärpts är tidpunkten ledtråden. Anta inte att listan är komplett bara för att interaktiv åtkomst fungerar; kontrollera vad funktionen kräver för din region och dina prenumerationer innan du drar slutsatsen att klustret är trasigt.

Felsignaturen hjälper. Om begäran aldrig når autentiseringen är det filtret. Om den autentiserar och sedan får ett behörighetsfel har filtret gjort sitt jobb och problemet är rollbaserad åtkomstkontroll, som tillåtelselistan aldrig rör.

Bygg hela listan i ett enda kommando

Uppdateringsparametern ersätter hela listan i stället för att lägga till en post, så ett kommando som bara innehåller VPN-adressen tappar tyst allt annat som fanns där. Läs det aktuella värdet först, behåll det och skicka unionen:

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

Använd en reserverad offentlig IP för VPN-servern innan du förlitar dig på detta. En dynamisk adress ändras vid återanslutning, och varje ändring låser tyst teamet ute från klustret tills någon uppdaterar listan från ett nätverk som fortfarande är tillåtet. Om du har två VPN-utgångar för redundans, lista båda, eftersom filtret inte har något begrepp om en föredragen väg.

Ordna ändringen så att det första tillåtna försöket också är testet. Meddela den nya listan, tillämpa den och anslut från VPN direkt; i omvänd ordning finns ett fönster där ingen kan nå API-servern för att rätta ett skrivfel i ett CIDR-block.

Vad tillåtelselistan aldrig täckte

Den gör inte API-servern privat. Ett privat kluster använder en privat slutpunkt och privat DNS, och listan över auktoriserade intervall är inte den kontroll som ersätter det. Den ändrar inte heller vad en insläppt anropare kan göra, så en läckt admin-kubeconfig fungerar fortfarande från vilken tillåten adress som helst. Behandla autentiseringsuppgiften som säkerhetsgränsen och listan som en nätverksbekvämlighet.

Den har inget med arbetsbelastningar att göra. Pods och tjänster fortsätter köra med listan aktiverad, och att nå en applikation över VPN är ett separat problem: en tjänst som bara har en kluster-IP behöver fortfarande en intern lastbalanserare, en ingress eller en port-forward innan en laptop kan öppna den. Att blanda de två designerna ger en ändringsbiljett som påstår sig begränsa utvecklare och i själva verket inte begränsar något av applikationerna.

Verifiera från båda sidor och kör sedan en riktig åtgärd

Testa med en ny klient på VPN:et och med en klient utanför det. Försöket utifrån bör nekas vid API-servern, inte vid namnmatchning; om namnet inte matchas, testar du DNS och har inte lärt dig något om filtret. Kör sedan en åtgärd som inte är ett interaktivt kubectl-anrop, till exempel en nodpoolsskalning eller en uppgraderingskontroll, och bekräfta att den slutförs i stället för att anta det.

Anteckna det tidigare listvärdet bredvid ändringen och läs av det gällande värdet igen efter uppdateringen i stället för att lita på kommandot som skrevs. dokumentationen för AKS auktoriserade IP-intervall listar de parametrar som stöds och de plattformskrav som hör till samma lista, vilket är den del som de flesta biljettbeskrivningar utelämnar.