kubectl működik VPN-en keresztül, de az AKS leáll a skálázással: miért

Hozzáadja az irodai VPN nyilvános címét az AKS API-kiszolgáló engedélyezési listájához, és a kubectl működik. Egy héttel később meghiúsul egy csomópontkészlet felskálázása, egy CI-feladat nem éri el a fürtöt, és a portál olyan hibát mutat, amely semmit sem említ az IP-tartományokról. Senki nem módosította az engedélyezési listát. Az engedélyezett vezérlés egy nyilvános IP-szűrő az API-kiszolgáló előtt, és nem tudja, ki hív, csak azt, melyik címről érkezik a hívás. A VPN egy a fürt által igényelt több cím közül, és ritkán az, amelyik először elromlik.

Az engedélyezési lista címhez, nem személyhez illeszkedik

--api-server-authorized-ip-ranges CIDR-blokkokat fogad, nem felhasználókat vagy csoportokat. Amikor egy fejlesztő kérése elhagyja a VPN-kiszolgálót Azure felé, a forráscím az API-kiszolgálón a VPN-kiszolgáló nyilvános kimenete. Ezért a VPN minden embere egyetlen bejegyzést oszt, és bárkit, aki a VPN-en kívül van, még a hitelesítés előtt elutasítanak.

Ez azt is jelenti, hogy a bejegyzés több embert enged be, mint amennyit talán szándékozik. Egy VPN-hozzáféréssel rendelkező alvállalkozó, egy személyes laptop ugyanazon a koncentrátoron és egy feltört fiók mind ugyanarról a címről érkezik. A fürt engedélyezése változatlan, így a szerepköralapú hozzáférés-vezérlés továbbra is eldönti, mit tehet a hívó, de az engedélyezési lista nem identitásvezérlés, és soha nem szabad annak leírni.

Ami először elromlik, az általában nem a kubectl

Az engedélyezési lista az API-kiszolgáló nyilvános végpontjára vonatkozik, így minden, ami a listázott címeken kívül esik, azonnal leáll. A nyilvánvaló áldozatok a második iroda VPN-útvonal nélkül, egy CI-futtató egy hosztolt folyamatban és egy laptop, amely elfelejtett csatlakozni. Ezeket könnyű felismerni, mert egy ember vár.

A kevésbé nyilvánvaló eset az Azure vagy a saját eszközei által vezérelt automatizálás. Néhány platform által indított művelet olyan címekről éri el az API-kiszolgálót, amelyek nem az Ön VPN-je, és amikor az egyik közvetlenül a lista szigorítása után kezd meghiúsulni, az időzítés a nyom. Ne feltételezze, hogy a lista teljes, csak mert az interaktív hozzáférés működik; ellenőrizze, mit igényel a funkció az Ön régiójában és előfizetéseiben, mielőtt arra jutna, hogy a fürt elromlott.

A hiba-aláírás segít. Ha a kérés soha nem ér el a hitelesítésig, akkor a szűrő a hibás. Ha hitelesít, majd engedélyhibát kap, a szűrő végezte a dolgát, és a probléma a szerepköralapú hozzáférés-vezérlés, amelyhez az engedélyezési lista soha nem nyúl.

Építse fel a teljes listát egyetlen paranccsal

A frissítési paraméter a teljes listát lecseréli, nem egy bejegyzést ad hozzá, így a csak a VPN-címet tartalmazó parancs csendben eldobja minden más, ott lévő elemet. Először olvassa ki az aktuális értéket, tartsa meg, és küldje el az uniót:

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

Használjon fenntartott nyilvános IP-címet a VPN-kiszolgálóhoz, mielőtt erre támaszkodna. A dinamikus cím újracsatlakozáskor megváltozik, és minden változás csendben kizárja a csapatot a fürtből, amíg valaki frissíti a listát egy még engedélyezett hálózatról. Ha két VPN-kimenettel rendelkezik a redundancia érdekében, sorolja fel mindkettőt, mert a szűrő nem ismeri az előnyben részesített útvonal fogalmát.

Úgy ütemezze a változtatást, hogy az első engedélyezett kísérlet egyben a teszt legyen. Jelentse be az új listát, alkalmazza, és azonnal csatlakozzon a VPN-ről; fordított sorrendben marad egy ablak, amikor senki nem éri el az API-kiszolgálót, hogy kijavítsa egy CIDR-blokk elírását.

Amit az engedélyezési lista soha nem fedett

Nem teszi priváttá az API-kiszolgálót. Egy privát fürt privát végpontot és privát DNS-t használ, és az engedélyezett tartományok listája nem az a vezérlés, amely ezt helyettesíti. Az sem változtatja meg, hogy egy beengedett hívó mit tehet, így egy kiszivárgott admin kubeconfig továbbra is működik bármely engedélyezett címről. Kezelje a hitelesítő adatot biztonsági határként, a listát pedig hálózati kényelemként.

Semmi köze a munkaterhelésekhez. A podok és szolgáltatások tovább működnek az engedélyezett listával, és egy alkalmazás elérése VPN-en keresztül külön probléma: egy csak fürt IP-vel rendelkező szolgáltatásnak továbbra is szüksége van belső terheléselosztóra, ingressre vagy port-forwardra, mielőtt egy laptop megnyithatja. A két terv összekeverése olyan változtatási jegyet eredményez, amely azt állítja, hogy korlátozza a fejlesztőket, és valójában semmit nem korlátoz az alkalmazásokon.

Ellenőrizze mindkét oldalról, majd hajtson végre egy valódi műveletet

Teszteljen friss klienssel a VPN-en és a VPN-en kívüli klienssel. A kívülről érkező kísérletet az API-kiszolgálón kell elutasítani, nem a névfeloldásnál; ha a név nem oldódik fel, akkor a DNS-t teszteli, és semmit nem tanult a szűrőről. Ezután hajtson végre egy olyan műveletet, amely nem interaktív kubectl-hívás, például egy csomópontkészlet skálázását vagy egy frissítésellenőrzést, és erősítse meg, hogy befejeződik, ahelyett hogy feltételezné.

Jegyezze fel az előző listaértéket a változtatás mellé, és a frissítés után olvassa újra a tényleges értéket, ahelyett hogy megbízna a beírt parancsban. Az AKS engedélyezett IP-tartományainak dokumentációja felsorolja a támogatott paramétereket és a platformkövetelményeket, amelyek ugyanabba a listába tartoznak, és ez az a rész, amelyet a legtöbb jegyleírás kihagy.