Wêrom kubectl oer de VPN wurket mar AKS stopet mei skaaljen

Jo foegje it publike adres fan 'e kantoar-VPN ta oan 'e tastiene list fan 'e AKS-API-tsjinner, en kubectl wurket. In wike letter mislearret in node-pool-skaalging, in CI-taak kin it cluster net berikke, en it portaal toant in flater dy't neat oer IP-berikken seit. Nimmen hat de tastiene list feroare. De kontrôle dy't jo ynskeakele hawwe is in publike IP-filter foar de API-tsjinner, en dy wit net wa't skilget, allinnich fan hokker adres it skil kaam. De VPN is ien adres fan ferskate dy't it cluster nedich hat, en it is selden dejinge dy't as earste brekt.

De tastiene list past by in adres, net by in persoan

--api-server-authorized-ip-ranges nimt CIDR-blokken, net brûkers of groepen. As it fersyk fan in ûntwikkelder de VPN-tsjinner ferlitten hat nei Azure, is it boarne-adres by de API-tsjinner de publike útgong fan 'e VPN-tsjinner. Dêrom dielt elk persoan op dy VPN ien yngong, en elkenien bûten de VPN wurdt wegere foar't autentikaasje sels bart.

Dat betsjut ek dat de yngong mear minsken talit as jo fan doel binne. In oannimmer mei VPN-tagong, in persoanlike laptop op deselde konsintrator, en in kompromittearre akkount komme allegear fan itselde adres. Cluster-autorisaasje is net feroare, dus rol-basearre tagongskontrôle beslút noch wat de skilger dwaan mei, mar de tastiene list is gjin identiteitskontrôle en moat nea sa beskreaun wurde.

Wat as earste brekt is meastentiids net kubectl

De tastiene list jildt foar it publike einpunt fan 'e API-tsjinner, dus alles bûten jo fermelde adressen stopet daliks mei wurkjen. De fanselssprekkende slachtoffers binne it twadde kantoar sûnder VPN-rûte, in CI-runner yn in hoste pipeline, en in laptop dy't fergetten is te ferbinen. Dy binne maklik te werkenne om't in minske wachtet.

It minder fanselssprekkende gefal is automatisearring dy't Azure of jo eigen ark driuwt. Guon platfoarm-ynisjearre operaasjes berikke de API-tsjinner fan adressen dy't net jo VPN binne, en as ien fan harren krekt nei it oanskerpjen fan 'e list begjint te mislearjen, is de timing de oanwizing. Nim net oan dat de list folslein is om't ynteraktive tagong wurket; kontrolearje wat de funksje foar jo regio en abonneminten fereasket foar't jo konkludearje dat it cluster stikken is.

De mislearingssignatuer helpt. As it fersyk nea autentikaasje berikt, is it de filter. As it autentisearret en dan in tastimmingsflater krijt, hat de filter syn wurk dien en is it probleem rol-basearre tagongskontrôle, dy't de tastiene list nea oanrekket.

Bou de hiele list yn ien kommando

De bywurkingsparameter ferfangt de hiele list yn stee fan in yngong ta te foegjen, dus in kommando dat allinnich it VPN-adres draacht, lit stilwei alles falle wat der wie. Lês earst de hjoeddeistige wearde, hâld dy, en stjoer de feriening:

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

Brûk in reservearre publike IP foar de VPN-tsjinner foar't jo hjir op fertrouwe. In dynamysk adres feroaret by it opnij ferbinen, en elke feroaring slút it team stilwei bûten it cluster oant immen de list bywurket fan in netwurk dat noch tastien is. As jo twa VPN-útgongspunten hawwe foar redundantheid, fermeld beide, want de filter hat gjin begryp fan in foarkarspaad.

Oarderje de feroaring sa dat de earste tastiene poging ek de test is. Kundigje de nije list oan, pas dy ta, en ferbynje daliks fan 'e VPN; it oarsom dwaan lit in finster wêryn nimmen de API-tsjinner berikke kin om in typflater yn in CIDR-blok te reparearjen.

Wat de tastiene list nea dutsen hat

It makket de API-tsjinner net privee. In privee cluster brûkt in privee einpunt en privee DNS, en de list mei autorisearre berikken is net de kontrôle dy't dat ferfangt. It feroaret ek net wat in tastien skilger dwaan mei, dus in lekke admin-kubeconfig wurket noch fan elk tastien adres. Behannelje de oanmeldgegevens as de feiligensgrins en de list as in netwurkgerak.

It hat neat te meitsjen mei wurklêsten. Pods en Services bliuwe draaien mei de list ynskeakele, en in applikaasje berikke oer de VPN is in apart probleem: in Service dy't allinnich in cluster-IP hat, hat noch in ynterne load-balancer, in ingress of in port-forward nedich foar't in laptop it iepenje kin. It mingen fan dy twa ûntwerpen produsearret in feroaringskaartsje dat beweart ûntwikkelders te beheinen en eins neat oan 'e applikaasjes beheint.

Kontrolearje fan beide kanten, doch dan ien echte operaasje

Test mei in farske klant op 'e VPN en mei in klant bûten de VPN. De poging fan bûten moat by de API-tsjinner wegere wurde, net by namme-oplossing; as de namme net oplost, test jo DNS en hawwe jo neat oer de filter leard. Doch dan in operaasje dy't gjin ynteraktive kubectl-oprop is, lykas in node-pool-skaalging of in fernijingskontrôle, en befêstigje dat dy foltôget yn stee fan oan te nimmen dat it sil.

Hâld de foarige listwearde by de feroaring fêst, en lês de effektive wearde nei de bywurking opnij yn stee fan it yntype kommando te fertrouwen. De AKS-dokumintaasje oer autorisearre IP-berikken listet de stipe parameters en de platfoarm-easken dy't yn deselde list hearre, en dat is it diel dat de measte kaartsje-beskriuwings weilitten.