Pse kubectl funksionon përmes VPN-së, por AKS ndalon shkallëzimin

Ju shtoni adresën publike të VPN-së së zyrës në listën e lejuar të serverit AKS API, dhe kubectl funksionon. Një javë më vonë shkallëzimi i një node pool dështon, një punë CI nuk arrin dot klasterin, dhe portali shfaq një gabim që nuk përmend asgjë për gamet IP. Askush nuk e ndryshoi listën e lejuar. Kontrolli që aktivizuat është një filtër IP publik përpara serverit API, dhe ai nuk e di kush po thërret, vetëm nga cila adresë erdhi thirrja. VPN është një adresë mes disa që klasteri ka nevojë, dhe rrallë është ajo që thyhet e para.

Lista e lejuar përputh një adresë, jo një person

--api-server-authorized-ip-ranges pranon blloqe CIDR, jo përdorues ose grupe. Kur kërkesa e një zhvilluesi largohet nga serveri VPN drejt Azure, adresa burimore në serverin API është dalja publike e serverit VPN. Prandaj çdo person në atë VPN ndan një hyrje të vetme, dhe kushdo jashtë VPN-së refuzohet para se të ndodhë vërtetimi.

Kjo do të thotë gjithashtu se hyrja pranon më shumë njerëz sesa synoni. Një kontraktor me akses VPN, një laptop personal në të njëjtin koncentrator dhe një llogari e kompromentuar vijnë të gjithë nga e njëjta adresë. Autorizimi i klasterit nuk ka ndryshuar, kështu që kontrolli i aksesit bazuar në role vazhdon të vendosë çfarë mund të bëjë thirrësi, por lista e lejuar nuk është kontroll identiteti dhe nuk duhet përshkruar kurrë si i tillë.

Ajo që thyhet e para zakonisht nuk është kubectl

Lista e lejuar zbatohet për pikën fundore publike të serverit API, kështu që çdo gjë jashtë adresave tuaja të listuara ndalon së funksionuari menjëherë. Viktimat e dukshme janë zyra e dytë pa rrugë VPN, një ekzekutues CI në një tubacion të hostuar dhe një laptop që harroi të lidhet. Këto njihen lehtë sepse një njeri po pret.

Rasti më pak i dukshëm është automatizimi që drejtohet nga Azure ose mjetet tuaja. Disa operacione të nisura nga platforma arrijnë serverin API nga adresa që nuk janë VPN-ja juaj, dhe kur njëri prej tyre fillon të dështojë menjëherë pas shtrëngimit të listës, koha është indicja. Mos supozoni se lista është e plotë sepse aksesi interaktiv funksionon; kontrolloni çfarë kërkon funksioni për rajonin dhe abonimet tuaja përpara se të përfundoni se klasteri është prishur.

Nënshkrimi i dështimit ndihmon. Nëse kërkesa nuk arrin kurrë në vërtetim, është filtri. Nëse vërtetohet dhe më pas merr një gabim leje, filtri ka bërë punën e vet dhe problemi është kontrolli i aksesit bazuar në role, të cilin lista e lejuar nuk e prek kurrë.

Ndërtoni të gjithë listën me një komandë

Parametri i përditësimit zëvendëson të gjithë listën në vend që të shtojë një hyrje, kështu që një komandë që mban vetëm adresën VPN hedh në heshtje çdo gjë tjetër që ishte atje. Lexoni fillimisht vlerën aktuale, mbajeni dhe dërgoni bashkimin:

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

Përdorni një IP publike të rezervuar për serverin VPN përpara se të mbështeteni në këtë. Një adresë dinamike ndryshon në rilidhje, dhe çdo ndryshim e mbyll ekipin në heshtje jashtë klasterit derisa dikush të përditësojë listën nga një rrjet që është ende i lejuar. Nëse keni dy pika daljeje VPN për tepricë, listoni të dyja, sepse filtri nuk ka konceptin e rrugës së preferuar.

Renditni ndryshimin në mënyrë që përpjekja e parë e lejuar të jetë edhe testi. Njoftoni listën e re, zbatoni atë dhe lidhuni menjëherë nga VPN; ta bëni në rendin e kundërt lë një dritare ku askush nuk mund të arrijë serverin API për të rregulluar një gabim shtypi në një bllok CIDR.

Çfarë lista e lejuar nuk mbuloi kurrë

Ajo nuk e bën serverin API privat. Një klaster privat përdor një pikë fundore private dhe DNS privat, dhe lista e gameve të autorizuara nuk është kontrolli që e zëvendëson atë. Gjithashtu nuk ndryshon çfarë mund të bëjë një thirrës i pranuar, kështu që një kubeconfig administratori i rrjedhur vazhdon të funksionojë nga çdo adresë e lejuar. Trajtoni kredencialet si kufirin e sigurisë dhe listën si një lehtësi rrjeti.

Nuk ka lidhje me ngarkesat e punës. Pods dhe Services vazhdojnë të ekzekutohen me listën të aktivizuar, dhe arritja e një aplikacioni përmes VPN-së është problem më vete: një Service që ka vetëm një IP klasteri ende ka nevojë për një balancues të brendshëm ngarkese, një ingress ose një port-forward përpara se një laptop ta hapë. Përzierja e këtyre dy modeleve prodhon një tiketë ndryshimi që pretendon se kufizon zhvilluesit dhe në fakt nuk kufizon asgjë në lidhje me aplikacionet.

Verifikoni nga të dyja anët, pastaj ekzekutoni një operacion të vërtetë

Testoni me një klient të ri në VPN dhe me një klient jashtë saj. Përpjekja nga jashtë duhet të refuzohet në serverin API, jo në zgjidhjen e emrave; nëse emri nuk zgjidhet, ju po testoni DNS dhe nuk keni mësuar asgjë për filtrin. Pastaj ekzekutoni një operacion që nuk është një thirrje kubectl interaktive, si shkallëzimi i një node pool ose një kontroll përditësimi, dhe konfirmoni se përfundon në vend që të supozoni se do të përfundojë.

Mbani vlerën e mëparshme të listës të regjistruar pranë ndryshimit, dhe rilexoni vlerën efektive pas përditësimit në vend që t'i besoni komandës së shtypur. dokumentacioni i AKS për gamet IP të autorizuara liston parametrat e mbështetur dhe kërkesat e platformës që i përkasin të njëjtës listë, dhe kjo është pjesa që shumica e përshkrimeve të tiketave e lënë jashtë.