Kial kubectl funkcias tra la VPN sed AKS ĉesas skali

Vi aldonas la publikan adreson de la oficeja VPN al la permeslisto de la AKS API-servilo, kaj kubectl funkcias. Semajnon poste skaliĝo de node pool fiaskas, CI-tasko ne povas atingi la klusteron, kaj la portalo montras eraron, kiu mencias nenion pri IP-gamoj. Neniu ŝanĝis la permesliston. La regilo, kiun vi ebligis, estas publika IP-filtro antaŭ la API-servilo, kaj ĝi ne scias, kiu vokas, nur el kiu adreso la voko venis. La VPN estas unu adreso inter pluraj, kiujn la klastro bezonas, kaj ĝi malofte estas tiu, kiu unue rompiĝas.

La permeslisto kongruas al adreso, ne al persono

--api-server-authorized-ip-ranges akceptas CIDR-blokojn, ne uzantojn aŭ grupojn. Kiam peto de programisto forlasas la VPN-servilon al Azure, la fonta adreso ĉe la API-servilo estas la publika eliro de la VPN-servilo. Tial ĉiu persono en tiu VPN dividas unu enskribon, kaj iu ajn ekster la VPN estas rifuzata antaŭ ol aŭtentigo eĉ okazas.

Tio ankaŭ signifas, ke la enskribo enlasas pli da homoj ol vi intencas. Subkontraktisto kun VPN-aliro, persona tekkomputilo sur la sama koncentrilo, kaj kompromitita konto ĉiuj alvenas el la sama adreso. Klastera rajtigo ne ŝanĝiĝas, do rolbaza alirkontrolo ankoraŭ decidas, kion la vokanto rajtas fari, sed la permeslisto ne estas identec-kontrolo kaj neniam devus esti priskribata kiel tia.

Tio, kio unue rompiĝas, kutime ne estas kubectl

La permeslisto validas por la publika finpunkto de la API-servilo, do ĉio ekster viaj listigitaj adresoj tuj ĉesas funkcii. La evidentaj viktimoj estas la dua oficejo sen VPN-itinero, CI-rulilo en gastigita dukto, kaj tekkomputilo, kiu forgesis konektiĝi. Tiujn facilas rekoni, ĉar homo atendas.

La malpli evidenta kazo estas aŭtomatigo, kiun pelas Azure aŭ viaj propraj iloj. Iuj platforme iniciatitaj operacioj atingas la API-servilon el adresoj, kiuj ne estas via VPN, kaj kiam unu el ili komencas fiaski tuj post kiam la listo plistreĉiĝas, la tempo estas la indico. Ne supozu, ke la listo estas kompleta ĉar interaga aliro funkcias; kontrolu, kion la funkcio postulas por via regiono kaj abonoj, antaŭ ol konkludi, ke la klastro rompiĝis.

La fiaskosigno helpas. Se la peto neniam atingas aŭtentigon, temas pri la filtro. Se ĝi aŭtentikiĝas kaj poste ricevas permeseraron, la filtro faris sian taskon kaj la problemo estas rolbaza alirkontrolo, kiun la permeslisto neniam tuŝas.

Konstruu la tutan liston per unu komando

La ĝisdatiga parametro anstataŭigas la tutan liston anstataŭ aldoni enskribon, do komando, kiu portas nur la VPN-adreson, silente forĵetas ĉion alian, kio estis tie. Unue legu la nunan valoron, konservu ĝin, kaj sendu la kunaĵon:

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

Uzu rezervitan publikan IP por la VPN-servilo antaŭ ol vi fidos ĉi tion. Dinamika adreso ŝanĝiĝas ĉe rekonekto, kaj ĉiu ŝanĝo silente ŝlosas la teamon ekster la klastro ĝis iu ĝisdatigas la liston el reto, kiu ankoraŭ estas permesita. Se vi havas du VPN-elirpunktojn por redundo, listigu ambaŭ, ĉar la filtro ne konas la koncepton de preferata vojo.

Ordigi la ŝanĝon tiel, ke la unua permesita provo estu ankaŭ la testo. Anoncu la novan liston, apliku ĝin, kaj konektiĝu el la VPN tuj; fari tion en la mala ordo lasas fenestron, en kiu neniu povas atingi la API-servilon por ripari tajperaron en CIDR-bloko.

Kion la permeslisto neniam kovris

Ĝi ne faras la API-servilon privata. Privata klastro uzas privatan finpunkton kaj privatan DNS, kaj la listo de rajtigitaj gamoj ne estas la regilo, kiu anstataŭas ĝin. Ĝi ankaŭ ne ŝanĝas, kion enlasita vokanto povas fari, do likita administra kubeconfig ankoraŭ funkcias el iu ajn permesita adreso. Traktu la akreditaĵon kiel la sekurecan limon kaj la liston kiel retan oportunon.

Ĝi tute ne rilatas al laborŝarĝoj. Pods kaj Services daŭre funkcias kun la listo ebligita, kaj atingi aplikaĵon tra la VPN estas aparta problemo: Service, kiu havas nur klusteran IP, ankoraŭ bezonas internan ŝarĝbalancilon, ingress aŭ port-forward antaŭ ol tekkomputilo povas malfermi ĝin. Miksi tiujn du dezajnojn produktas ŝanĝbileton, kiu asertas limigi programistojn kaj fakte limigas nenion pri la aplikaĵoj.

Kontrolu el ambaŭ flankoj, poste plenumu unu realan operacion

Testu per freŝa kliento en la VPN kaj per kliento ekster ĝi. La ekstera provo devus esti rifuzata ĉe la API-servilo, ne ĉe nomresolucio; se la nomo ne solviĝas, vi testas DNS kaj lernis nenion pri la filtro. Poste plenumu operacion, kiu ne estas interaga kubectl-voko, kiel skaligon de node pool aŭ kontrolon de ĝisdatigo, kaj konfirmu, ke ĝi finiĝas anstataŭ supozi, ke ĝi faros.

Konservu la antaŭan listovaloron apud la ŝanĝo, kaj relegu la efektivan valoron post la ĝisdatigo anstataŭ fidi la tajpitan komandon. La dokumentaro de AKS pri rajtigitaj IP-gamoj listigas la subtenatajn parametrojn kaj la platformajn postulojn, kiuj apartenas al la sama listo, kaj tion plej multaj biletopriskriboj preterlasas.