Kvifor kubectl fungerer over VPN-en, men AKS sluttar å skalere

Du legg den offentlege adressa til kontor-VPN-en til i tillatingslista til AKS API-tenaren, og kubectl fungerer. Ei veke seinare feilar skaleringa av ein node pool, ein CI-jobb når ikkje klynga, og portalen viser ein feil som ikkje nemner noko om IP-område. Ingen har endra tillatingslista. Kontrollen du slo på, er eit offentleg IP-filter framom API-tenaren, og det veit ikkje kven som ringjer, berre kva adresse samtalen kom frå. VPN-en er éi adresse blant fleire som klynga treng, og det er sjeldan ho som ryker fyrst.

Tillatingslista passar til ei adresse, ikkje ein person

--api-server-authorized-ip-ranges tar CIDR-blokker, ikkje brukarar eller grupper. Når ein utviklar sin førespurnad forlèt VPN-tenaren mot Azure, er kjeldeadressa ved API-tenaren den offentlege utgangen til VPN-tenaren. Difor deler kvar person på den VPN-en éin oppføring, og alle utanfor VPN-en vert avviste før autentiseringa i det heile skjer.

Det tyder òg at oppføringa slepp inn fleire folk enn du meiner. Ein entreprenør med VPN-tilgang, ein personleg berbar PC på same konsentratoren og ein kompromittert konto kjem alle frå same adresse. Autorisasjonen i klynga er uendra, så tilgangsstyringa basert på roller avgjer framleis kva den som ringjer, får gjere, men tillatingslista er ikkje ei identitetsstyring og bør aldri skildrast som det.

Det som ryker fyrst, er vanlegvis ikkje kubectl

Tillatingslista gjeld den offentlege endepunktet til API-tenaren, så alt utanfor adressene du har lista, sluttar å virke med ein gong. Dei openberre offera er det andre kontoret utan VPN-rute, ein CI-køyrar i ein hosta pipeline og ein berbar PC som gløymde å kopla til. Dei er lette å kjenne att fordi eit menneske ventar.

Det mindre openberre tilfellet er automatisering som Azure eller dine eigne verktøy styrer. Nokre operasjonar som plattforma startar, når API-tenaren frå adresser som ikkje er VPN-en din, og når éin av dei byrjar å feile rett etter at lista vart stramma inn, er tidspunktet hintet. Ikkje gå ut frå at lista er fullstendig fordi interaktiv tilgang fungerer; sjekk kva funksjonen krev for regionen og abonnementa dine før du konkluderer med at klynga er øydelagd.

Feilsignaturen hjelper. Viss førespurnaden aldri når autentiseringa, er det filteret. Viss han autentiserer og deretter får ein tilgangsfeil, har filteret gjort jobben sin, og problemet er tilgangsstyringa basert på roller, som tillatingslista aldri rører.

Bygg heile lista i éin kommando

Oppdateringsparameteren byter ut heile lista i staden for å leggje til ei oppføring, så ein kommando som berre har med VPN-adressa, slepp stille alt anna som var der. Les den gjeldande verdien fyrst, hald på han, og send 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

Bruk ein reservert offentleg IP for VPN-tenaren før du byggjer på dette. Ei dynamisk adresse endrar seg ved attkopling, og kvar endring låser teamet stille ute frå klynga til nokon oppdaterer lista frå eit nett som framleis er tillate. Viss du har to VPN-utgangspunkt for redundans, list opp begge, for filteret har ikkje noko omgrep om ein føretrekt veg.

Set endringa i ei rekkjefølgje slik at det fyrste tillatne forsøket òg er testen. Kunngjer den nye lista, bruk ho, og kople til frå VPN-en med ein gong; gjer du det i motsett rekkjefølgje, står det att eit vindauge der ingen når API-tenaren for å rette ein skrivefeil i ein CIDR-blokk.

Kva tillatingslista aldri dekte

Ho gjer ikkje API-tenaren privat. Ei privat klynge brukar eit privat endepunkt og privat DNS, og lista over autoriserte område er ikkje kontrollen som erstattar det. Ho endrar heller ikkje kva ein innsleppt som ringjer får gjere, så ein lekt admin-kubeconfig fungerer framleis frå kvar ei tillaten adresse. Sjå på legitimasjonen som tryggingsgrensa og på lista som ein nettverkskomfort.

Ho har ingenting med arbeidslaster å gjere. Pods og Services held fram med å køyre med lista slått på, og å nå ein applikasjon over VPN-en er eit separat problem: ein Service som berre har ei klynge-IP, treng framleis ein intern lastbalansar, ein ingress eller ein port-forward før ein berbar PC kan opne han. Å blande dei to designa gjev ein endringsbillett som hevdar å avgrense utviklarar og i røynda ikkje avgrensar noko som helst ved applikasjonane.

Stadfest frå begge sider, og køyr så éin reell operasjon

Test med ein fersk klient på VPN-en og med ein klient utanfor. Forsøket utanfrå bør verte avvist ved API-tenaren, ikkje ved namneoppløysing; viss namnet ikkje vert løyst opp, testar du DNS og har ikkje lært noko om filteret. Køyr så ein operasjon som ikkje er eit interaktivt kubectl-kall, til dømes ei skalering av ein node pool eller ein oppgraderingssjekk, og stadfest at han fullførast i staden for å gå ut frå at han vil gjere det.

Hald den førre listeverdien registrert ved sida av endringa, og les den effektive verdien på nytt etter oppdateringa i staden for å stole på kommandoen som vart skriven. AKS-dokumentasjonen om autoriserte IP-område listar opp dei støtta parametrane og plattformkrava som høyrer til i same liste, og det er den delen dei fleste billettskildringar hoppar over.