Lisate kontori VPN-i avaliku aadressi AKS-i API-serveri lubatud loendisse ja kubectl töötab. Nädal hiljem ebaõnnestub sõlmepooli suurendamine, CI-töö ei jõua klasterini ja portaal näitab viga, mis ei maini midagi IP-vahemike kohta. Keegi ei muutnud lubatud loendit. Lubatud kontroll on avalik IP-filter API-serveri ees ja see ei tea, kes helistab, ainult milliselt aadressilt kõne tuleb. VPN on üks mitmest aadressist, mida klaster vajab, ja harva see, mis esimesena katki läheb.

Lubatud loend vastab aadressile, mitte inimesele

--api-server-authorized-ip-ranges võtab CIDR-plokke, mitte kasutajaid ega rühmi. Kui arendaja taotlus lahkub VPN-serverist Azure'i poole, on API-serveri lähteaadress VPN-serveri avalik väljund. Seega jagab iga inimene selles VPN-is ühte kirjet ja igaüks väljaspool VPN-i lükatakse tagasi juba enne autentimist.

See tähendab ka, et kirje lubab rohkem inimesi, kui võib-olla kavatsete. VPN-i juurdepääsuga töövõtja, samas kontsentraatoris olev isiklik sülearvuti ja kompromiteeritud konto tulevad kõik samalt aadressilt. Klastri autoriseerimine ei muutu, seega rollipõhine juurdepääsukontroll otsustab endiselt, mida kutsuja tohib teha, kuid lubatud loend ei ole identiteedikontroll ja seda ei tohiks kunagi nii kirjeldada.

Esimesena läheb tavaliselt katki miski muu kui kubectl

Lubatud loend kehtib API-serveri avaliku lõpp-punkti kohta, seega kõik väljaspool loetletud aadresse lakkab kohe töötamast. Ilmsed ohvrid on teine kontor ilma VPN-marsruudita, hostitud konveieri CI-jooksja ja sülearvuti, mis unustas ühenduda. Neid on lihtne ära tunda, sest inimene ootab.

Vähem ilmne juhtum on automatiseerimine, mida Azure või teie enda tööriistad juhivad. Mõned platvormi algatatud toimingud jõuavad API-serverini aadressidelt, mis ei ole teie VPN, ja kui üks neist hakkab ebaõnnestuma kohe pärast loendi karmistamist, on ajastus vihje. Ärge eeldage, et loend on täielik, sest interaktiivne juurdepääs töötab; kontrollige, mida funktsioon teie piirkonna ja tellimuste jaoks nõuab, enne kui järeldate, et klaster on katki.

Veasignatuur aitab. Kui taotlus ei jõua kunagi autentimiseni, on see filter. Kui see autenditakse ja saab seejärel õigusevea, tegi filter oma töö ja probleem on rollipõhine juurdepääsukontroll, mida lubatud loend kunagi ei puuduta.

Koostage kogu loend ühe käsuga

Värskendusparameeter asendab kogu loendi, mitte ei lisa kirjet, seega käsk, mis sisaldab ainult VPN-i aadressi, viskab vaikselt ära kõik muu, mis seal oli. Lugege kõigepealt praegust väärtust, hoidke see alles ja saatke ühend:

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

Kasutage VPN-serveri jaoks reserveeritud avalikku IP-d enne, kui sellele loote. Dünaamiline aadress muutub uuesti ühendamisel ja iga muudatus lukustab meeskonna vaikselt klastrist välja, kuni keegi värskendab loendi veel lubatud võrgust. Kui teil on koondamiseks kaks VPN-i väljundit, loetlege mõlemad, sest filtril pole eelistatud tee mõistet.

Korraldage muudatus nii, et esimene lubatud katse oleks ka test. Teatage uuest loendist, rakendage see ja ühenduge kohe VPN-ist; vastupidises järjekorras jääb aken, kus keegi ei jõua API-serverini, et CIDR-ploki kirjaviga parandada.

Mida lubatud loend kunagi ei katnud

See ei muuda API-serverit privaatseks. Privaatne klaster kasutab privaatset lõpp-punkti ja privaatset DNS-i ning autoriseeritud vahemike loend ei ole see kontroll, mis selle asendab. See ei muuda ka seda, mida lubatud kutsuja tohib teha, seega lekkinud administraatori kubeconfig töötab endiselt igalt lubatud aadressilt. Käsitlege mandaati turvapiirina ja loendit võrgu mugavusena.

Sellel pole töökoormustega midagi pistmist. Podid ja teenused töötavad loendi lubatud olekus edasi ning rakenduseni jõudmine VPN-i kaudu on eraldi probleem: teenus, millel on ainult klastri IP, vajab endiselt sisemist koormuse jaoturit, ingressi või port-forwardi, enne kui sülearvuti saab selle avada. Nende kahe kavandi segamine loob muudatustaotluse, mis väidab arendajate piiramist ja tegelikult ei piira rakendustest midagi.

Kontrollige mõlemalt poolt ja käivitage seejärel üks tõeline toiming

Testige värske kliendiga VPN-is ja kliendiga väljaspool. Väljastpoolt tehtud katse tuleks tagasi lükata API-serveris, mitte nimede tõlgendamisel; kui nimi ei tõlgendu, testite DNS-i ega ole filtri kohta midagi õppinud. Seejärel käivitage toiming, mis ei ole interaktiivne kubectl-kutse, näiteks sõlmepooli skaleerimine või värskenduse kontroll, ja kinnitage, et see lõpeb, selle asemel et seda eeldada.

Märkige eelmine loendi väärtus muudatuse kõrvale ja lugege pärast värskendust uuesti kehtiv väärtus, selle asemel et usaldada sisestatud käsku. AKS-i autoriseeritud IP-vahemike dokumentatsioon loetleb toetatud parameetrid ja platvorminõuded, mis kuuluvad samasse loendisse, mis on see osa, mille enamik piletikirjeldusi välja jätab.

Seotud artiklid