Firwat kubectl iwwer de VPN funktionéiert, awer AKS ophält ze skaléieren
Autoriséiert IP-Beräicher gesinn den ëffentlechen Ausgang vum VPN-Server, net den Entwéckler. Füügt d'Beräicher vun der Plattform derbäi, soss schléit d'Automatiséierung an d'Skaléierung nom Ännerung fehl.
Dir füügt déi ëffentlech Adress vum Büro-VPN an d'Erlaabneslëscht vum AKS API-Server derbäi, an kubectl funktionéiert. Eng Woch méi spéit schléit d'Skaléierung vun engem node pool fehl, eng CI-Aufgab kann de Cluster net erreechen, an de Portal weist e Feeler, deen näischt iwwer IP-Beräicher seet. Keen huet d'Erlaabneslëscht geännert. D'Kontroll, déi Dir ageschalt hutt, ass en ëffentleche IP-Filter virum API-Server, an et weess net wien urifft, just vu wéi enger Adress den Uruff kënnt. De VPN ass eng Adress ënner puer, déi de Cluster braucht, an et ass seelen déi, déi als éischt briecht.
D'Erlaabneslëscht passt op eng Adress, net op eng Persoun
--api-server-authorized-ip-ranges hëlt CIDR-Bléck, net Benotzer oder Gruppen. Wann d'Ufro vun engem Entwéckler de VPN-Server verléisst Richtung Azure, ass d'Quelladress um API-Server den ëffentlechen Ausgang vum VPN-Server. Dofir deelt jiddereen op deem VPN eng eenzeg Andro, an all deen ausserhalb vum VPN gëtt refuséiert, ier d'Authentifikatioun iwwerhaapt geschitt.
Dat heescht och, datt d'Andro méi Leit erlaabt wéi Dir geduecht hutt. En Handwierker mat VPN-Zougrëff, en private Laptop um selwechte Konzentrator an e kompromittéierte Kont kommen alleguer vun der selwechter Adress. D'Autorisatioun vum Cluster ännert sech net, sou datt d'Roll-baséiert Zougrëffskontroll nach ëmmer entscheet, wat den Uruffer maache kann, awer d'Erlaabneslëscht ass keng Identitéitskontroll an dat soll een och ni esou beschreiwen.
Wat als éischt briecht, ass meeschtens net kubectl
D'Erlaabneslëscht gëllt fir den ëffentlechen Endpunkt vum API-Server, dofir hält alles baussent Ären opgezielten Adressen direkt op ze funktionéieren. Déi evident Affer sinn deen zweeten Büro ouni VPN-Route, en CI-Runner an enger gehosteter Pipeline an e Laptop, deen vergiess huet sech ze verbannen. Déi si liicht z'erkennen, well en Mënsch drop waart.
De manner evidente Fall ass d'Automatiséierung, déi Azure oder Är eege Werkzeuge bedreiwen. E puer Operationen, déi vun der Plattform ausgeléist ginn, erreechen den API-Server vun Adressen, déi net Äre VPN sinn, an wann eng dovun direkt nom Verschéiere vun der Lëscht ufänkt ze versoen, ass den Timing de Hiweis. Gitt net dovun aus, datt d'Lëscht komplett ass, well den interaktiven Zougrëff funktionéiert; préift wat d'Funktioun fir Är Regioun an Abonnementer verlaangt, ier Dir schléisst, datt de Cluster futti ass.
D'Feelerzeeche hëlleft. Wann d'Ufro ni d'Authentifikatioun erreecht, ass et de Filter. Wann et sech authentifizéiert an duerno e Berechtegungsfeeler kritt, huet de Filter seng Aarbecht gemaach an de Problem ass d'Roll-baséiert Zougrëffskontroll, déi d'Erlaabneslëscht ni beréiert.
Baut déi ganz Lëscht an engem Befehl
Den Update-Parameter ersetzt déi ganz Lëscht, amplaz eng Andro derbäizesetzen, dofir e Befehl, deen nëmmen d'VPN-Adress dréit, fällt alles anescht, wat do war, still eraus. Liest d'aktuell Wäert als éischt, haalt en, a schéckt d'Vereenegung:
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/24Benotzt eng reservéiert ëffentlech IP fir de VPN-Server, ier Dir Iech op dëst verloosst. Eng dynamesch Adress ännert sech bei der Reconnectioun, an all Ännerung späert d'Team still aus dem Cluster aus, bis een d'Lëscht vun engem Netz aktualiséiert, dat nach erlaabt ass. Wann Dir zwee VPN-Ausgäng fir Redundanz hutt, zielt béid op, well de Filter kee Konzept vun engem bevorzugte Wee huet.
Ordnert d'Ännerung esou, datt den éischte erlaabten Versuch och den Test ass. Annonciert déi nei Lëscht, setzt se ëm, a verbënnt Iech direkt vum VPN; et an der anerer Reihenfolge ze maachen hannerléisst eng Fënster, wou keen den API-Server erreeche kann, fir en Tippfeeler an engem CIDR-Bléck ze korrigéieren.
Wat d'Erlaabneslëscht ni ofgedeckt huet
Et mécht den API-Server net privat. E private Cluster benotzt en private Endpunkt a privaten DNS, an d'Lëscht vun den autoriséierte Beräicher ass net d'Kontroll, déi dat ersetzt. Et ännert och net, wat en erlaabten Uruffer maache kann, dofir funktionéiert e geleekten Administratiouns-kubeconfig nach ëmmer vun enger erlaabter Adress. Betruecht d'Zertifikat als Sécherheetsgrenz an d'Lëscht als Netzwierkkomfort.
Et huet näischt mat Aarbechtslaaschten ze dinn. Pods a Services lafe weider, wann d'Lëscht ageschalt ass, an eng Applikatioun iwwer de VPN z'erreechen ass e separat Problem: engem Service, deen nëmmen eng Cluster-IP huet, brauch et nach ëmmer en internen Load-Balancer, en Ingress oder e Port-Forward, ier e Laptop en opmaache kann. Dës zwee Designen ze vermëschen, produzéiert en Ännerungs-Ticket, deen behaapt Entwéckler ze beschränken an tatsächlech näischt un den Applikatiounen beschränkt.
Iwwerpréift vun zwou Säiten, da maacht eng richteg Operatioun
Test mat engem neie Client um VPN an engem Client dobaussen. Den Ausprobéieren vun dobausse soll um API-Server refuséiert ginn, net bei der Numm-Opléisung; wann den Numm sech net opléisst, test Dir DNS an hutt näischt iwwer de Filter geléiert. Da maacht eng Operatioun, déi keen interaktiven kubectl-Uruff ass, wéi eng node pool-Skaléierung oder eng Upgrade-Préifung, a bestätegt, datt se fäerdeg gëtt, amplaz unzehuelen datt se et wäert.
Hält de fréiere Lëschtwäert nieft der Ännerung fest, a liest den effektive Wäert nom Update nach eng Kéier, amplaz op de Befehl ze vertrauen, deen agetippt gouf. D'AKS-Dokumentatioun iwwer autoriséiert IP-Beräicher zielt déi ënnerstëtzt Parameteren an d'Plattform-Ufuerderungen op, déi an déiselwecht Lëscht gehéieren, an dat ass den Deel, deen déi meescht Ticket-Beschreiwungen ewechloossen.