Bakit gumagana ang kubectl sa VPN pero humihinto ang AKS sa pag-scale

Idinadagdag mo ang pampublikong address ng VPN sa opisina sa listahan ng pinapayagan ng AKS API server, at gumagana ang kubectl. Makalipas ang isang linggo, nabibigo ang pag-scale ng node pool, hindi maabot ng isang CI job ang cluster, at nagpapakita ang portal ng error na walang binabanggit tungkol sa mga hanay ng IP. Walang nagbago sa listahan ng pinapayagan. Ang kontrol na pinagana mo ay isang pampublikong IP filter sa harap ng API server, at hindi nito alam kung sino ang tumatawag, alam lamang nito kung saang address galing ang tawag. Ang VPN ay isang address sa ilang kailangan ng cluster, at bihirang ito ang unang masisira.

Tumutugma ang listahan ng pinapayagan sa address, hindi sa tao

--api-server-authorized-ip-ranges tumanggap ito ng mga bloke ng CIDR, hindi mga user o grupo. Kapag umalis ang kahilingan ng isang developer sa VPN server patungong Azure, ang source address sa API server ay ang pampublikong egress ng VPN server. Kaya bawat tao sa VPN na iyon ay nagbabahagi ng isang entry, at sinumang nasa labas ng VPN ay tinatanggihan bago pa man mangyari ang authentication.

Ibig sabihin din nito na mas maraming tao ang pinapasok ng entry kaysa sa intensyon mo. Ang isang kontratista na may access sa VPN, isang personal na laptop sa parehong concentrator, at isang nakompromisong account ay nagmumula sa parehong address. Hindi nagbago ang awtorisasyon ng cluster, kaya ang role-based access control pa rin ang nagpapasya kung ano ang maaaring gawin ng tumatawag, ngunit ang listahan ng pinapayagan ay hindi kontrol ng pagkakakilanlan at hindi dapat ilarawan kailanman bilang ganoon.

Ang unang masisira ay karaniwang hindi kubectl

Nalalapat ang listahan ng pinapayagan sa pampublikong endpoint ng API server, kaya ang anumang nasa labas ng mga address na nakalista mo ay agad na humihinto sa paggana. Ang mga halatang biktima ay ang ikalawang opisina na walang ruta ng VPN, isang CI runner sa isang naka-host na pipeline, at isang laptop na nakalimutang kumonekta. Madaling makilala ang mga ito dahil may taong naghihintay.

Ang hindi gaanong halatang kaso ay ang automation na pinapatakbo ng Azure o ng sarili mong mga tool. Ang ilang operasyong sinisimulan ng platform ay umaabot sa API server mula sa mga address na hindi ang VPN mo, at kapag ang isa sa kanila ay nagsimulang mabigo kaagad pagkatapos ng paghigpit ng listahan, ang timing ang palatandaan. Huwag ipagpalagay na kumpleto ang listahan dahil gumagana ang interactive na access; tingnan kung ano ang kailangan ng feature para sa iyong rehiyon at mga subscription bago ka magpasiya na sira ang cluster.

Nakakatulong ang lagda ng pagkabigo. Kung hindi kailanman umabot ang kahilingan sa authentication, ito ang filter. Kung napatotohanan ito at pagkatapos ay nakakuha ng error sa pahintulot, nagawa ng filter ang trabaho nito at ang problema ay nasa role-based access control, na hindi kailanman hinahawakan ng listahan ng pinapayagan.

Buuin ang buong listahan sa isang utos

Pinapalitan ng update parameter ang buong listahan sa halip na magdagdag ng entry, kaya ang isang utos na may dalang address ng VPN lamang ay tahimik na itinatapon ang lahat ng iba pang naroon. Basahin muna ang kasalukuyang halaga, itago ito, at ipadala ang unyon:

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

Gumamit ng nakareserbang pampublikong IP para sa VPN server bago ka umasa dito. Nagbabago ang dynamic na address kapag muling kumonekta, at bawat pagbabago ay tahimik na nagla-lock sa team palabas ng cluster hanggang may mag-update ng listahan mula sa network na pinapayagan pa. Kung mayroon kang dalawang egress point ng VPN para sa redundancy, ilista ang dalawa, dahil walang konsepto ng ginustong landas ang filter.

Ayusin ang pagkakasunod-sunod ng pagbabago upang ang unang pinapayagang pagtatangka ay siya ring pagsubok. Ipaalam ang bagong listahan, ilapat ito, at kumonekta mula sa VPN agad; ang paggawa nito sa kabaligtaran ay nag-iiwan ng window kung saan walang makakaabot sa API server upang ayusin ang typo sa isang bloke ng CIDR.

Ang hindi kailanman sinaklaw ng listahan ng pinapayagan

Hindi nito ginagawang pribado ang API server. Gumagamit ang pribadong cluster ng pribadong endpoint at pribadong DNS, at ang listahan ng mga awtorisadong hanay ay hindi ang kontrol na pumapalit doon. Hindi rin nito binabago kung ano ang maaaring gawin ng pinapayagang tumatawag, kaya ang tumagas na admin kubeconfig ay gumagana pa rin mula sa anumang pinapayagang address. Ituring ang kredensyal bilang hangganan ng seguridad at ang listahan bilang kaginhawahan ng network.

Wala itong kinalaman sa mga workload. Patuloy na gumagana ang Pods at Services habang naka-enable ang listahan, at ang maabot ang isang application sa VPN ay hiwalay na problema: ang Service na may cluster IP lamang ay nangangailangan pa rin ng panloob na load balancer, ingress, o port-forward bago ito mabuksan ng laptop. Ang paghahalo ng dalawang disenyong ito ay gumagawa ng change ticket na nagsasabing nililimitahan ang mga developer at sa totoo lang ay wala namang nililimitahan sa mga application.

I-verify mula sa dalawang panig, pagkatapos ay magpatakbo ng isang tunay na operasyon

Subukan gamit ang bagong client sa VPN at client sa labas nito. Ang pagtatangka mula sa labas ay dapat tanggihan sa API server, hindi sa resolution ng pangalan; kung hindi ma-resolve ang pangalan, sinusubukan mo ang DNS at wala kang natutunan tungkol sa filter. Pagkatapos ay magpatakbo ng operasyong hindi interactive na kubectl call, tulad ng pag-scale ng node pool o pagsusuri ng upgrade, at kumpirmahing natapos ito sa halip na ipagpalagay na matatapos.

Itala ang dating halaga ng listahan sa tabi ng pagbabago, at basahin muli ang epektibong halaga pagkatapos ng update sa halip na magtiwala sa utos na nai-type. dokumentasyon ng AKS tungkol sa mga awtorisadong hanay ng IP naglilista ng mga sinusuportahang parameter at mga kinakailangan ng platform na kabilang sa parehong listahan, at ito ang bahaging madalas iwanan ng mga paglalarawan ng ticket.