Kwa nini kubectl hufanya kazi kupitia VPN lakini AKS huacha kupanua
Masafa ya IP yaliyoruhusiwa huona toka la umma la seva ya VPN, si msanidi. Ongeza masafa ya jukwaa, vinginevyo uendeshaji otomatiki na upanuzi vitashindikana baada ya mabadiliko.
Unaongeza anwani ya umma ya VPN ya ofisi kwenye orodha ya kuruhusiwa ya seva ya AKS API, na kubectl hufanya kazi. Wiki moja baadaye upanuzi wa node pool unashindikana, kazi ya CI haiwezi kufikia kikundi, na lango linaonyesha hitilafu isiyotaja chochote kuhusu masafa ya IP. Hakuna aliyebadilisha orodha ya kuruhusiwa. Udhibiti uliouwezesha ni kichujio cha IP cha umma mbele ya seva ya API, na haujui ni nani anapiga simu, kinajua tu simu ilikotoka kwa anwani gani. VPN ni anwani moja kati ya kadhaa ambazo kikundi kinahitaji, na mara chache ndiyo inayovunjika kwanza.
Orodha ya kuruhusiwa inalingana na anwani, si mtu
--api-server-authorized-ip-ranges inapokea vitalu vya CIDR, si watumiaji au vikundi. Ombi la msanidi linapoondoka kwenye seva ya VPN kuelekea Azure, anwani ya chanzo kwenye seva ya API ni toka la umma la seva ya VPN. Kwa hiyo kila mtu kwenye VPN hiyo anashiriki ingizo moja, na yeyote aliye nje ya VPN anakataliwa kabla uthibitishaji haujatokea.
Hiyo inamaanisha pia kwamba ingizo linawapa ruhusa watu wengi kuliko ulivyokusudia. Mkandarasi mwenye ufikiaji wa VPN, kompyuta ndogo ya kibinafsi kwenye konsentrata hiyo hiyo, na akaunti iliyoathirika wote wanatoka kwenye anwani moja. Uidhinishaji wa kikundi haujabadilika, kwa hiyo udhibiti wa ufikiaji unaotegemea jukumu bado huamua mwitaji anaweza kufanya nini, lakini orodha ya kuruhusiwa si udhibiti wa utambulisho na haipaswi kuelezewa hivyo kamwe.
Kinachovunjika kwanza kwa kawaida si kubectl
Orodha ya kuruhusiwa inatumika kwa kituo cha mwisho cha umma cha seva ya API, kwa hiyo chochote kilicho nje ya anwani ulizoorodhesha huacha kufanya kazi mara moja. Waathirika dhahiri ni ofisi ya pili isiyo na njia ya VPN, kikimbizaji cha CI kwenye bomba linalopangishwa, na kompyuta ndogo iliyosahau kuunganisha. Hivi ni rahisi kutambua kwa sababu mtu anasubiri.
Kesi isiyo dhahiri ni uendeshaji otomatiki unaoendeshwa na Azure au zana zako mwenyewe. Baadhi ya shughuli zinazoanzishwa na jukwaa hufikia seva ya API kutoka anwani ambazo si VPN yako, na mojawapo inapoanza kushindikana mara moja baada ya orodha kukazwa, muda ndio kidokezo. Usidhani orodha imekamilika kwa sababu ufikiaji wa mwingiliano unafanya kazi; angalia kile kipengele kinachohitaji kwa eneo lako na usajili wako kabla ya kuhitimisha kwamba kikundi kimeharibika.
Alama ya kushindikana inasaidia. Ikiwa ombi halifikii uthibitishaji kamwe, ni kichujio. Ikiwa linathibitishwa kisha linapata hitilafu ya ruhusa, kichujio kimefanya kazi yake na tatizo ni udhibiti wa ufikiaji unaotegemea jukumu, ambao orodha ya kuruhusiwa haigusi kamwe.
Jenga orodha yote kwa amri moja
Kigezo cha kusasisha hubadilisha orodha yote badala ya kuongeza ingizo, kwa hiyo amri inayobeba anwani ya VPN pekee hutupa kimya kila kitu kingine kilichokuwa hapo. Kwanza soma thamani ya sasa, iweke, na utume muungano:
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/24Tumia IP ya umma iliyohifadhiwa kwa seva ya VPN kabla ya kutegemea hii. Anwani inayobadilika hubadilika unapounganisha tena, na kila mabadiliko hufunga timu kimya nje ya kikundi hadi mtu asasishe orodha kutoka mtandao ambao bado unaruhusiwa. Ikiwa una pointi mbili za toka za VPN kwa ajili ya upungufu, orodhesha zote mbili, kwa sababu kichujio hakina dhana ya njia inayopendelewa.
Panga mabadiliko ili jaribio la kwanza lililoruhusiwa liwe pia mtihani. Tangaza orodha mpya, itumie, na unganisha kutoka VPN mara moja; kufanya hivyo kwa mpangilio wa kinyume huacha dirisha ambapo hakuna anayeweza kufikia seva ya API kurekebisha makosa ya uchapaji kwenye kitalu cha CIDR.
Kile orodha ya kuruhusiwa haikuwahi kufunika
Haifanyi seva ya API kuwa ya faragha. Kikundi cha faragha hutumia kituo cha mwisho cha faragha na DNS ya faragha, na orodha ya masafa yaliyoruhusiwa si udhibiti unaobadilisha hilo. Pia haibadilishi kile mwitaji aliyeruhusiwa anaweza kufanya, kwa hiyo kubeconfig ya msimamizi iliyovuja bado inafanya kazi kutoka anwani yoyote iliyoruhusiwa. Chukulia vitambulisho kama mpaka wa usalama na orodha kama urahisi wa mtandao.
Haina uhusiano wowote na mizigo ya kazi. Pods na Services zinaendelea kufanya kazi orodha ikiwa imewezeshwa, na kufikia programu kupitia VPN ni tatizo tofauti: Service iliyo na IP ya kikundi pekee bado inahitaji kusawazisha mzigo wa ndani, ingress au port-forward kabla kompyuta ndogo haijaweza kuifungua. Kuchanganya miundo hii miwili huzalisha tikiti ya mabadiliko inayodai kuwazuia wasanidi na kwa kweli haizuii chochote kuhusu programu.
Thibitisha kutoka pande zote mbili, kisha endesha operesheni moja halisi
Jaribu kwa mteja mpya kwenye VPN na kwa mteja aliye nje yake. Jaribio la nje linapaswa kukataliwa kwenye seva ya API, si kwenye utatuzi wa majina; ikiwa jina halitatuliki, unajaribu DNS na hujajifunza chochote kuhusu kichujio. Kisha endesha operesheni ambayo si wito wa kubectl wa mwingiliano, kama vile upanuzi wa node pool au ukaguzi wa uboreshaji, na thibitisha inakamilika badala ya kudhani itakamilika.
Hifadhi thamani ya awali ya orodha karibu na mabadiliko, na usome tena thamani yenye matokeo baada ya kusasisha badala ya kuamini amri iliyochapwa. nyaraka za AKS kuhusu masafa ya IP yaliyoruhusiwa zinaorodhesha vigezo vinavyotumika na mahitaji ya jukwaa ambayo ni sehemu ya orodha hiyo hiyo, na hii ndiyo sehemu ambayo maelezo mengi ya tikiti huiacha.