Защо kubectl работи през VPN, а AKS спира да мащабира

Добавяте публичния адрес на офис VPN към списъка с разрешени адреси на AKS API сървъра и kubectl работи. Седмица по-късно мащабирането на node pool се проваля, CI задача не може да достигне клъстера, а порталът показва грешка, в която не се споменават IP диапазони. Никой не е променял списъка. Контролът, който включихте, е публичен IP филтър пред API сървъра и той не знае кой се обажда, а само от кой адрес идва връзката. VPN е един адрес сред няколко, необходими на клъстера, и рядко е този, който се чупи пръв.

Списъкът съпоставя адрес, а не човек

--api-server-authorized-ip-ranges приема CIDR блокове, не потребители или групи. Когато заявката на разработчик напусне VPN сървъра към Azure, изходният адрес при API сървъра е публичният изход на VPN сървъра. Затова всеки в този VPN споделя един запис, а всеки извън VPN се отказва още преди да се стигне до удостоверяване.

Това също означава, че записът допуска повече хора, отколкото възнамерявате. Изпълнител с достъп до VPN, личен лаптоп на същия концентратор и компрометиран акаунт всички идват от един и същ адрес. Оторизацията на клъстера не се променя, така че управлението на достъпа по роли все още решава какво може да прави викащият, но списъкът не е контрол на самоличността и никога не бива да се описва като такъв.

Първото, което се чупи, обикновено не е kubectl

Списъкът се отнася за публичната крайна точка на API сървъра, така че всичко извън изброените адреси спира да работи веднага. Очевидните жертви са вторият офис без VPN маршрут, CI runner в хостинг pipeline и лаптоп, който е забравил да се свърже. Те се разпознават лесно, защото човек ги чака.

По-неочевидният случай е автоматизацията, която Azure или собствените ви инструменти управляват. Някои операции, инициирани от платформата, достигат до API сървъра от адреси, които не са вашият VPN, и когато една от тях започне да се проваля веднага след затягането на списъка, времето е уликата. Не приемайте, че списъкът е пълен, защото интерактивният достъп работи; проверете какво изисква функцията за вашия регион и абонаменти, преди да заключите, че клъстерът е счупен.

Сигнатурата на отказа помага. Ако заявката никога не стигне до удостоверяване, това е филтърът. Ако премине удостоверяване и после получи грешка за права, филтърът си е свършил работата и проблемът е в управлението на достъпа по роли, което списъкът никога не засяга.

Изградете целия списък с една команда

Параметърът за актуализация заменя целия списък, вместо да добавя запис, така че команда, която носи само VPN адреса, тихо изхвърля всичко останало, което е било там. Първо прочетете текущата стойност, запазете я и изпратете обединението:

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

Използвайте резервиран публичен IP за VPN сървъра, преди да разчитате на това. Динамичният адрес се променя при повторно свързване и всяка промяна тихо заключва екипа извън клъстера, докато някой не актуализира списъка от мрежа, която все още е разрешена. Ако имате две изходни точки на VPN за резервиране, избройте и двете, защото филтърът няма понятие за предпочитан път.

Подредете промяната така, че първият разрешен опит да е и тестът. Обявете новия списък, приложете го и се свържете от VPN веднага; ако го направите в обратния ред, остава прозорец, в който никой не може да достигне API сървъра, за да поправи печатна грешка в CIDR блок.

Какво списъкът никога не е покривал

Той не прави API сървъра частен. Частният клъстер използва частна крайна точка и частен DNS, а списъкът с разрешени диапазони не е контролът, който го заменя. Той също не променя какво може да прави допуснатият викащ, така че изтекъл администраторски kubeconfig все още работи от всеки разрешен адрес. Третирайте идентификационните данни като границата за сигурност, а списъка — като мрежово удобство.

Той няма нищо общо с работните натоварвания. Pods и Services продължават да работят с включен списък, а достигането до приложение през VPN е отделен проблем: Service, който има само клъстерен IP, все още се нуждае от вътрешен балансьор на натоварването, ingress или port-forward, преди лаптоп да може да го отвори. Смесването на тези два дизайна създава билет за промяна, който твърди, че ограничава разработчиците, а всъщност не ограничава нищо в приложенията.

Проверете от двете страни, после изпълнете една реална операция

Тествайте с нов клиент във VPN и с клиент извън него. Опитът отвън трябва да бъде отказан на API сървъра, не при разрешаване на имена; ако името не се разрешава, тествате DNS и не научихте нищо за филтъра. След това изпълнете операция, която не е интерактивно kubectl извикване, например мащабиране на node pool или проверка за надграждане, и потвърдете, че завършва, вместо да предполагате, че ще стане.

Запазете предишната стойност на списъка до промяната и препрочетете ефективната стойност след актуализацията, вместо да се доверявате на написаната команда. Документацията на AKS за разрешени IP диапазони изброява поддържаните параметри и изискванията на платформата, които принадлежат в същия списък, а именно тази част повечето описания на билети пропускат.