kubectl toimii VPN:n yli, mutta AKS lakkaa skaalaamasta: miksi

Lisäät toimiston VPN:n julkisen osoitteen AKS API -palvelimen sallittujen luetteloon, ja kubectl toimii. Viikkoa myöhemmin solmupoolin skaalaus epäonnistuu, CI-työ ei tavoita klusteria ja portaali näyttää virheen, joka ei mainitse mitään IP-alueista. Kukaan ei muuttanut sallittujen luetteloa. Käyttöön ottamasi valvonta on julkinen IP-suodatin API-palvelimen edessä, eikä se tiedä, kuka soittaa, vain mistä osoitteesta kutsu tulee. VPN on yksi useista osoitteista, joita klusteri tarvitsee, ja harvoin se, joka hajoaa ensimmäisenä.

Sallittujen luettelo vastaa osoitetta, ei henkilöä

--api-server-authorized-ip-ranges ottaa CIDR-lohkoja, ei käyttäjiä tai ryhmiä. Kun kehittäjän pyyntö jättää VPN-palvelimen Azureen, lähdeosoite API-palvelimella on VPN-palvelimen julkinen ulostulo. Jokainen tuon VPN:n henkilö jakaa siis yhden merkinnän, ja kuka tahansa VPN:n ulkopuolella hylätään ennen kuin todennus edes alkaa.

Se tarkoittaa myös, että merkintä päästää sisään enemmän ihmisiä kuin ehkä aiot. VPN-käyttöoikeuden omaava urakoitsija, sama konsentraattori käyttävä henkilökohtainen kannettava ja vaarantunut tili tulevat kaikki samasta osoitteesta. Klusterin valtuutus ei muutu, joten roolipohjainen käytönvalvonta päättää edelleen, mitä soittaja saa tehdä, mutta sallittujen luettelo ei ole identiteetin valvonta, eikä sitä pitäisi koskaan kuvata sellaisena.

Ensimmäisenä hajoaa yleensä muu kuin kubectl

Sallittujen luettelo koskee API-palvelimen julkista päätepistettä, joten kaikki lueteltujen osoitteiden ulkopuolella lakkaa toimimasta heti. Ilmeiset uhrit ovat toinen toimisto ilman VPN-reittiä, isännöidyn putken CI-ajuri ja kannettava, joka unohti yhdistää. Ne on helppo tunnistaa, koska ihminen odottaa.

Vähemmän ilmeinen tapaus on automaatio, jota Azure tai omat työkalusi ohjaavat. Jotkin alustan käynnistämät toiminnot tavoittavat API-palvelimen osoitteista, jotka eivät ole VPN:si, ja kun yksi niistä alkaa epäonnistua heti luettelon kiristämisen jälkeen, ajoitus on vihje. Älä oleta luettelon olevan täydellinen siksi, että interaktiivinen käyttö toimii; tarkista, mitä ominaisuus vaatii alueellasi ja tilauksissasi, ennen kuin päättelet klusterin olevan rikki.

Virheen allekirjoitus auttaa. Jos pyyntö ei koskaan saavu todennukseen, se on suodatin. Jos se todennetaan ja saa sitten käyttöoikeusvirheen, suodatin teki tehtävänsä ja ongelma on roolipohjainen käytönvalvonta, jota sallittujen luettelo ei koskaan koske.

Rakenna koko luettelo yhdellä komennolla

Päivitysparametri korvaa koko luettelon sen sijaan, että lisäisi merkinnän, joten komento, joka sisältää vain VPN-osoitteen, pudottaa hiljaa kaiken muun. Lue nykyinen arvo ensin, säilytä se ja lähetä yhdiste:

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

Käytä varattua julkista IP:tä VPN-palvelimelle ennen kuin luotat tähän. Dynaaminen osoite muuttuu uudelleenyhdistettäessä, ja jokainen muutos lukitsee tiimin hiljaa klusterin ulkopuolelle, kunnes joku päivittää luettelon verkosta, joka on yhä sallittu. Jos sinulla on kaksi VPN-ulostuloa redundanssia varten, luettele molemmat, koska suodattimella ei ole käsitettä suositusta polusta.

Järjestä muutos niin, että ensimmäinen sallittu yritys on myös testi. Ilmoita uusi luettelo, ota se käyttöön ja yhdistä VPN:stä heti; päinvastaisessa järjestyksessä jää ikkuna, jossa kukaan ei tavoita API-palvelinta CIDR-lohkon kirjoitusvirheen korjaamiseksi.

Mitä sallittujen luettelo ei koskaan kattanut

Se ei tee API-palvelimesta yksityistä. Yksityinen klusteri käyttää yksityistä päätepistettä ja yksityistä DNS:ää, eikä valtuutettujen alueiden luettelo ole se valvonta, joka sen korvaa. Se ei myöskään muuta sitä, mitä sisään päästetty soittaja voi tehdä, joten vuotanut admin-kubeconfig toimii edelleen mistä tahansa sallitusta osoitteesta. Kohtele kirjautumistietoa turvarajana ja luetteloa verkon mukavuutena.

Sillä ei ole mitään tekemistä työkuormien kanssa. Podit ja palvelut jatkavat toimintaansa luettelon ollessa käytössä, ja sovellukseen pääseminen VPN:n yli on erillinen ongelma: palvelu, jolla on vain klusterin IP, tarvitsee silti sisäisen kuormantasaajan, ingressin tai port-forwardin ennen kuin kannettava voi avata sen. Näiden kahden suunnitelman sekoittaminen tuottaa muutospyynnön, joka väittää rajoittavansa kehittäjiä ja itse asiassa ei rajoita sovelluksista mitään.

Varmista molemmilta puolilta ja suorita sitten yksi oikea toimenpide

Testaa tuoreella asiakkaalla VPN:ssä ja asiakkaalla sen ulkopuolella. Ulkopuolinen yritys pitäisi hylätä API-palvelimella, ei nimien selvityksessä; jos nimeä ei selvitetä, testaat DNS:ää etkä oppinut suodattimesta mitään. Suorita sitten toimenpide, joka ei ole interaktiivinen kubectl-kutsu, kuten solmupoolin skaalaus tai päivitystarkistus, ja varmista, että se valmistuu sen sijaan, että olettaisit niin.

Kirjaa edellinen luetteloarvo muutoksen viereen ja lue voimassa oleva arvo uudelleen päivityksen jälkeen sen sijaan, että luottaisit kirjoitettuun komentoon. AKS:n valtuutettujen IP-alueiden dokumentaatio luettelee tuetut parametrit ja alustavaatimukset, jotka kuuluvat samaan luetteloon, mikä on se osa, jonka useimmat tikettikuvaukset jättävät pois.