kubectl funguje přes VPN, ale AKS přestává škálovat: proč

Přidáte veřejnou adresu firemní VPN do seznamu povolených serveru API AKS a kubectl funguje. O týden později selže navýšení kapacity fondu uzlů, úloha CI se nedostane ke clusteru a portál zobrazí chybu, která o rozsazích IP nic neříká. Nikdo seznam povolených nezměnil. Zapnutá kontrola je filtr veřejných IP před serverem API a neví, kdo volá, pouze z jaké adresy hovor přišel. VPN je jedna z několika adres, které cluster potřebuje, a málokdy je to ta, která se rozbije první.

Seznam povolených odpovídá adrese, ne osobě

--api-server-authorized-ip-ranges přijímá bloky CIDR, ne uživatele ani skupiny. Když požadavek vývojáře opustí server VPN a míří do Azure, zdrojovou adresou na serveru API je veřejný výstup serveru VPN. Každý člověk v této VPN tedy sdílí jeden záznam a kdokoli mimo VPN je odmítnut ještě před samotným ověřením.

To také znamená, že záznam propouští víc lidí, než možná zamýšlíte. Dodavatel s přístupem k VPN, osobní notebook na stejném koncentrátoru a napadený účet přicházejí ze stejné adresy. Autorizace clusteru se nemění, takže řízení přístupu na základě rolí stále rozhoduje, co volající smí dělat, ale seznam povolených není kontrola identity a nikdy by se tak neměl popisovat.

To, co se rozbije první, obvykle není kubectl

Seznam povolených platí pro veřejný koncový bod serveru API, takže vše mimo uvedené adresy okamžitě přestane fungovat. Zřejmými oběťmi jsou druhá pobočka bez trasy VPN, běžec CI v hostovaném kanálu a notebook, který se zapomněl připojit. Snadno je poznáte, protože čeká člověk.

Méně zřejmým případem je automatizace řízená Azure nebo vašimi vlastními nástroji. Některé operace zahájené platformou dosáhnou serveru API z adres, které nejsou vaše VPN, a když jedna z nich začne selhávat hned po zpřísnění seznamu, čas je tou stopou. Nepředpokládejte, že seznam je úplný, jen protože interaktivní přístup funguje; ověřte, co funkce vyžaduje pro váš region a předplatná, než cluster prohlásíte za rozbitý.

Podpis selhání pomáhá. Pokud se požadavek nikdy nedostane k ověření, je to filtr. Pokud se ověří a pak dostane chybu oprávnění, filtr udělal svou práci a problémem je řízení přístupu na základě rolí, kterého se seznam povolených nikdy nedotkne.

Sestavte celý seznam jedním příkazem

Parametr aktualizace nahrazuje celý seznam, místo aby přidal záznam, takže příkaz, který nese jen adresu VPN, tiše zahodí vše ostatní. Nejprve přečtěte aktuální hodnotu, ponechte ji a odešlete sjednocení:

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

Použijte rezervovanou veřejnou IP pro server VPN, než se na to spolehnete. Dynamická adresa se při opětovném připojení mění a každá změna tiše uzamkne tým mimo cluster, dokud někdo neaktualizuje seznam ze sítě, která je stále povolená. Pokud máte dva výstupy VPN pro redundanci, uveďte oba, protože filtr nemá pojem preferované cesty.

Naplánujte změnu tak, aby první povolený pokus byl zároveň testem. Oznamte nový seznam, použijte ho a okamžitě se připojte přes VPN; v opačném pořadí zůstává okno, kdy se nikdo nedostane k serveru API, aby opravil překlep v bloku CIDR.

Co seznam povolených nikdy nepokryl

Neznepřístupňuje server API. Privátní cluster používá privátní koncový bod a privátní DNS a seznam autorizovaných rozsahů není kontrola, která to nahrazuje. Nemění ani to, co smí připuštěný volající dělat, takže uniklý administrátorský kubeconfig stále funguje z jakékoli povolené adresy. Považujte přihlašovací údaj za bezpečnostní hranici a seznam za síťovou pohodlnost.

S pracovním zatížením to nemá nic společného. Pody a služby dál běží se zapnutým seznamem a dostat se k aplikaci přes VPN je samostatný problém: služba, která má jen IP clusteru, stále potřebuje interní vyrovnávání zátěže, ingress nebo port-forward, než ji notebook dokáže otevřít. Míchání těchto dvou návrhů vytváří změnový tiket, který tvrdí, že omezuje vývojáře, a ve skutečnosti na aplikacích nic neomezuje.

Ověřte z obou stran a potom proveďte jednu skutečnou operaci

Otestujte s čerstvým klientem ve VPN a s klientem mimo ni. Pokus zvenčí by měl být odmítnut na serveru API, ne při překladu názvů; pokud se název nepřeloží, testujete DNS a o filtru jste se nic nedozvěděli. Potom proveďte operaci, která není interaktivním voláním kubectl, například navýšení kapacity fondu uzlů nebo kontrolu aktualizace, a potvrďte, že skončí, místo abyste to předpokládali.

Zaznamenejte předchozí hodnotu seznamu vedle změny a po aktualizaci znovu přečtěte účinnou hodnotu, místo abyste věřili zadanému příkazu. Dokumentace autorizovaných rozsahů IP v AKS uvádí podporované parametry a požadavky platformy, které patří do stejného seznamu, což je část, kterou většina popisů tiketů vynechává.