Зошто 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 во хостирана патека и лаптоп што заборавил да се поврзе. Нив лесно се препознаваат затоа што човек чека.

Помалку очигледен е случајот на автоматизација што ја водат 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 опсези ги наведува поддржаните параметри и барањата на платформата што припаѓаат во истата листа, а тоа е делот што повеќето описи на тикети го испуштаат.