kubectl działa przez VPN, ale AKS przestaje skalować: dlaczego

Dodajesz publiczny adres VPN biura do listy dozwolonych serwera API AKS i kubectl działa. Tydzień później skalowanie puli węzłów kończy się niepowodzeniem, zadanie CI nie może dotrzeć do klastra, a portal pokazuje błąd, który nic nie mówi o zakresach IP. Nikt nie zmienił listy dozwolonych. Włączona kontrola to filtr publicznych IP przed serwerem API, który nie wie, kto dzwoni, tylko z jakiego adresu przyszło wywołanie. VPN to jeden z kilku adresów potrzebnych klastrowi i rzadko jest tym, który psuje się pierwszy.

Lista dozwolonych dopasowuje adres, a nie osobę

--api-server-authorized-ip-ranges przyjmuje bloki CIDR, a nie użytkowników ani grupy. Gdy żądanie dewelopera opuszcza serwer VPN i trafia do Azure, adres źródłowy na serwerze API to publiczne wyjście serwera VPN. Każda osoba w tym VPN dzieli więc jeden wpis, a każdy poza VPN jest odrzucany jeszcze przed uwierzytelnieniem.

Oznacza to również, że wpis wpuszcza więcej osób, niż możesz zamierzać. Wykonawca z dostępem do VPN, prywatny laptop na tym samym koncentratorze i przejęte konto przychodzą z tego samego adresu. Autoryzacja klastra się nie zmienia, więc kontrola dostępu oparta na rolach nadal decyduje, co może zrobić wywołujący, ale lista dozwolonych nie jest kontrolą tożsamości i nigdy nie powinna być tak opisywana.

To, co psuje się pierwsze, zwykle nie jest kubectl

Lista dozwolonych dotyczy publicznego punktu końcowego serwera API, więc wszystko poza wymienionymi adresami natychmiast przestaje działać. Oczywiste ofiary to drugie biuro bez trasy VPN, runner CI w hostowanym potoku i laptop, który zapomniał się połączyć. Łatwo je rozpoznać, bo czeka człowiek.

Mniej oczywisty przypadek to automatyzacja sterowana przez Azure lub własne narzędzia. Niektóre operacje inicjowane przez platformę docierają do serwera API z adresów innych niż twój VPN, a gdy jedna z nich zaczyna zawodzić zaraz po zaostrzeniu listy, czas jest wskazówką. Nie zakładaj, że lista jest kompletna, bo dostęp interaktywny działa; sprawdź, czego funkcja wymaga dla twojego regionu i subskrypcji, zanim uznasz klaster za zepsuty.

Sygnatura awarii pomaga. Jeśli żądanie nigdy nie dociera do uwierzytelniania, to filtr. Jeśli uwierzytelnia się i dostaje błąd uprawnień, filtr zrobił swoje, a problemem jest kontrola dostępu oparta na rolach, której lista dozwolonych nigdy nie dotyka.

Zbuduj całą listę jedną komendą

Parametr aktualizacji zastępuje całą listę zamiast dodawać wpis, więc komenda zawierająca tylko adres VPN po cichu usuwa wszystko inne. Najpierw odczytaj bieżącą wartość, zachowaj ją i wyślij sumę:

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

Użyj zarezerwowanego publicznego IP dla serwera VPN, zanim na tym polegniesz. Adres dynamiczny zmienia się przy ponownym połączeniu, a każda zmiana po cichu zamyka zespół poza klastrem, dopóki ktoś nie zaktualizuje listy z sieci wciąż dozwolonej. Jeśli masz dwa punkty wyjścia VPN dla redundancji, wymień oba, bo filtr nie zna pojęcia preferowanej ścieżki.

Ułóż zmianę tak, aby pierwsza dozwolona próba była także testem. Ogłoś nową listę, zastosuj ją i od razu połącz się przez VPN; w odwrotnej kolejności pozostaje okno, w którym nikt nie może dotrzeć do serwera API, aby poprawić literówkę w bloku CIDR.

Czego lista dozwolonych nigdy nie obejmowała

Nie czyni serwera API prywatnym. Prywatny klaster używa prywatnego punktu końcowego i prywatnego DNS, a lista autoryzowanych zakresów nie jest kontrolą, która to zastępuje. Nie zmienia też tego, co może zrobić dopuszczony wywołujący, więc ujawniony kubeconfig administratora nadal działa z każdego dozwolonego adresu. Traktuj poświadczenie jako granicę bezpieczeństwa, a listę jako wygodę sieciową.

Nie ma to nic wspólnego z obciążeniami. Pody i usługi nadal działają przy włączonej liście, i dotarcie do aplikacji przez VPN to osobny problem: usługa, która ma tylko IP klastra, nadal potrzebuje wewnętrznego load balancera, ingress lub port-forward, zanim laptop będzie mógł ją otworzyć. Mieszanie tych dwóch projektów tworzy zgłoszenie zmiany, które twierdzi, że ogranicza deweloperów, a w rzeczywistości niczego w aplikacjach nie ogranicza.

Sprawdź z obu stron, a potem wykonaj jedną prawdziwą operację

Przetestuj ze świeżym klientem w VPN i z klientem poza nią. Próba z zewnątrz powinna zostać odrzucona na serwerze API, a nie przy rozwiązywaniu nazw; jeśli nazwa się nie rozwiązuje, testujesz DNS i nie dowiedziałeś się niczego o filtrze. Następnie wykonaj operację, która nie jest interaktywnym wywołaniem kubectl, na przykład skalowanie puli węzłów lub sprawdzenie aktualizacji, i potwierdź, że się kończy, zamiast tego zakładać.

Zapisz poprzednią wartość listy obok zmiany i odczytaj ponownie wartość efektywną po aktualizacji, zamiast ufać wpisanej komendzie. Dokumentacja autoryzowanych zakresów IP w AKS wymienia obsługiwane parametry i wymagania platformy, które należą do tej samej listy, a to część, którą większość opisów zgłoszeń pomija.