Чаму kubectl працуе праз VPN, а AKS перастае масштабавацца

Дыяпазоны дазволеных IP бачаць публічны выхад VPN-сервера, а не распрацоўшчыка. Дадайце дыяпазоны платформы, інакш пасля змены аўтаматызацыя і масштабаванне зламаюцца.

Вы дадаяце публічны адрас офіснага VPN у спіс дазволеных для сервера AKS API, і kubectl працуе. Праз тыдзень пашырэнне пула вузлоў зрываецца, заданне CI не можа дасягнуць кластара, а партал паказвае памылку, у якой нічога не сказана пра дыяпазоны IP. Спіс дазволеных ніхто не змяняў. Уключаны вамі кантроль — гэта фільтр публічных IP перад серверам API, і ён не ведае, хто выклікае, а толькі з якога адраса прыйшоў выклік. VPN — адзін адрас сярод некалькіх, патрэбных кластару, і рэдка менавіта ён ламаецца першым.

Спіс дазволеных супастаўляе адрас, а не чалавека

--api-server-authorized-ip-ranges прымае блокі CIDR, а не карыстальнікаў ці групы. Калі запыт распрацоўшчыка пакідае VPN-сервер у бок Azure, крыніцавы адрас на серверы API — гэта публічны выхад VPN-сервера. Таму ўсе людзі ў гэтым VPN дзеляць адзін запіс, а любому па-за VPN адмаўляюць яшчэ да аўтэнтыфікацыі.

Гэта таксама азначае, што запіс прапускае больш людзей, чым вы разлічвалі. Падрадчык з доступам да VPN, асабісты ноўтбук на тым жа канцэнтратары і скампраметаваны ўліковы запіс — усе прыходзяць з аднаго адраса. Аўтарызацыя кластара не змянілася, таму кіраванне доступам на аснове роляў па-ранейшаму вырашае, што можа рабіць выклікальнік, але спіс дазволеных не з'яўляецца кантролем асобы і ніколі не павінен так апісвацца.

Першым ламаецца звычайна не kubectl

Спіс дазволеных дзейнічае для публічнай канчатковай кропкі сервера API, таму ўсё па-за вашымі пералічанымі адрасамі адразу перастае працаваць. Відавочныя ахвяры — другі офіс без маршруту праз VPN, CI-раннер у хостным канвееры і ноўтбук, які забыўся падключыцца. Іх лёгка пазнаць, бо на іх чакае чалавек.

Менш відавочны выпадак — аўтаматызацыя, якой кіруе 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, напрыклад пашырэнне пула вузлоў або праверку абнаўлення, і пацвердзіце, што яна завяршылася, замест таго каб меркаваць гэта.

Захоўвайце папярэдняе значэнне спіса побач са зменай і перачытайце эфектыўнае значэнне пасля абнаўлення, а не давярайце набранай камандзе. Дакументацыя AKS пра дазволеныя дыяпазоны IP пералічвае падтрыманыя параметры і патрабаванні платформы, якія належаць у той жа спіс, і менавіта гэтую частку большасць апісанняў білетаў апускае.

Падобныя артыкулы