kubectl fungerer over VPN, men AKS slutter å skalere: hvorfor

Du legger til kontorets VPN-offentlige adresse i tillatelseslisten til AKS API-serveren, og kubectl fungerer. En uke senere feiler en oppskalering av en nodepool, en CI-jobb når ikke klyngen, og portalen viser en feil som ikke nevner noe om IP-områder. Ingen endret tillatelseslisten. Kontrollen du aktiverte, er et offentlig IP-filter foran API-serveren, og den vet ikke hvem som ringer, bare hvilken adresse kallet kommer fra. VPN er én adresse blant flere som klyngen trenger, og det er sjelden den som ryker først.

Tillatelseslisten matcher en adresse, ikke en person

--api-server-authorized-ip-ranges tar CIDR-blokker, ikke brukere eller grupper. Når en utviklers forespørsel forlater VPN-serveren mot Azure, er kildeadressen på API-serveren VPN-serverens offentlige utgang. Hver person på den VPN-en deler derfor én oppføring, og alle utenfor VPN-en avvises før autentiseringen i det hele tatt begynner.

Det betyr også at oppføringen slipper inn flere personer enn du kanskje har tenkt. En underleverandør med VPN-tilgang, en personlig bærbar PC på samme konsentrator og en kompromittert konto kommer alle fra samme adresse. Klyngeautorisasjonen er uendret, så rollebasert tilgangskontroll avgjør fortsatt hva kalleren kan gjøre, men tillatelseslisten er ikke en identitetskontroll og bør aldri beskrives som en.

Det som ryker først, er vanligvis ikke kubectl

Tillatelseslisten gjelder API-serverens offentlige endepunkt, så alt utenfor adressene dine slutter å virke umiddelbart. De åpenbare ofrene er det andre kontoret uten VPN-rute, en CI-runner i en hostet pipeline og en bærbar PC som glemte å koble til. De er lette å kjenne igjen fordi et menneske venter.

Det mindre åpenbare tilfellet er automatisering som Azure eller dine egne verktøy driver. Noen plattforminitierte operasjoner når API-serveren fra adresser som ikke er din VPN, og når en av dem begynner å feile rett etter at listen er strammet inn, er tidspunktet ledetråden. Ikke anta at listen er komplett fordi interaktiv tilgang fungerer; sjekk hva funksjonen krever for din region og dine abonnementer før du konkluderer med at klyngen er ødelagt.

Feilsignaturen hjelper. Hvis forespørselen aldri når autentiseringen, er det filteret. Hvis den autentiserer og deretter får en tilgangsfeil, har filteret gjort jobben sin, og problemet er rollebasert tilgangskontroll, som tillatelseslisten aldri rører.

Bygg hele listen med én kommando

Oppdateringsparameteren erstatter hele listen i stedet for å legge til en oppføring, så en kommando som bare inneholder VPN-adressen, slipper stille alt annet som var der. Les gjeldende verdi 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

Bruk en reservert offentlig IP for VPN-serveren før du stoler på dette. En dynamisk adresse endres ved gjenoppkobling, og hver endring låser stille teamet ute av klyngen til noen oppdaterer listen fra et nettverk som fortsatt er tillatt. Hvis du har to VPN-utganger for redundans, før opp begge, fordi filteret ikke har noe begrep om en foretrukket vei.

Ordne endringen slik at det første tillatte forsøket også er testen. Kunngjør den nye listen, bruk den, og koble til fra VPN-en med en gang; i motsatt rekkefølge blir det et vindu der ingen kan nå API-serveren for å rette en skrivefeil i en CIDR-blokk.

Hva tillatelseslisten aldri dekket

Den gjør ikke API-serveren privat. En privat klynge bruker et privat endepunkt og privat DNS, og listen over autoriserte områder er ikke kontrollen som erstatter det. Den endrer heller ikke hva en tillatt kallere kan gjøre, så en lekket admin-kubeconfig fungerer fortsatt fra enhver tillatt adresse. Behandle legitimasjonen som sikkerhetsgrensen og listen som en nettverksbekvemmelighet.

Den har ingenting med arbeidsbelastninger å gjøre. Pods og tjenester fortsetter å kjøre med listen aktivert, og å nå en applikasjon over VPN er et eget problem: en tjeneste som bare har en klynge-IP, trenger fortsatt en intern lastbalanserer, en ingress eller en port-forward før en bærbar PC kan åpne den. Å blande de to designene gir en endringsbillett som hevder å begrense utviklere og faktisk ikke begrenser noe av applikasjonene.

Verifiser fra begge sider, og kjør deretter én ekte operasjon

Test med en fersk klient på VPN-en og med en klient utenfor den. Forsøket utenfra bør avvises ved API-serveren, ikke ved navneoppslag; hvis navnet ikke slås opp, tester du DNS og har ikke lært noe om filteret. Kjør deretter en operasjon som ikke er et interaktivt kubectl-kall, for eksempel en nodepool-skalering eller en oppgraderingssjekk, og bekreft at den fullføres i stedet for å anta det.

Noter den forrige listeverdien ved siden av endringen, og les den gjeldende verdien på nytt etter oppdateringen i stedet for å stole på kommandoen som ble skrevet. dokumentasjonen for AKS' autoriserte IP-områder viser de støttede parameterne og plattformkravene som hører i samme liste, som er den delen de fleste billettbeskrivelser utelater.