Por que kubectl funciona pola VPN pero AKS deixa de escalar

Engades o enderezo público da VPN da oficina á lista de autorizados do servidor API de AKS e kubectl funciona. Unha semana despois, unha ampliación dun node pool falla, unha tarefa de CI non pode chegar ao clúster e o portal mostra un erro que non di nada sobre rangos IP. Ninguén cambiou a lista. O control que activaches é un filtro de IP pública diante do servidor API e non sabe quen chama, só de que enderezo vén a chamada. A VPN é un enderezo entre varios que o clúster necesita e raramente é o primeiro que rompe.

A lista de autorizados coincide cun enderezo, non cunha persoa

--api-server-authorized-ip-ranges acepta bloques CIDR, non usuarios nin grupos. Cando a petición dun desenvolvedor sae do servidor VPN cara a Azure, o enderezo de orixe no servidor API é a saída pública do servidor VPN. Por iso todas as persoas desa VPN comparten unha entrada e a calquera que estea fóra da VPN négaselle antes de que ocorra a autenticación.

Isto tamén significa que a entrada admite máis xente da que pretendes. Un contratista con acceso á VPN, un portátil persoal no mesmo concentrador e unha conta comprometida chegan todos desde o mesmo enderezo. A autorización do clúster non cambia, así que o control de acceso por roles segue decidindo que pode facer o solicitante, pero a lista de autorizados non é un control de identidade e nunca debería describirse como tal.

O que rompe primeiro normalmente non é kubectl

A lista de autorizados aplícase ao punto final público do servidor API, así que todo o que quede fóra dos enderezos listados deixa de funcionar de inmediato. As vítimas evidentes son a segunda oficina sen ruta VPN, un executor de CI nun pipeline aloxado e un portátil que esqueceu conectarse. Son fáciles de recoñecer porque hai unha persoa esperando.

O caso menos evidente é a automatización que impulsan Azure ou as túas propias ferramentas. Algunhas operacións iniciadas pola plataforma chegan ao servidor API desde enderezos que non son a túa VPN, e cando unha comeza a fallar xusto despois de apertar a lista, o momento é a pista. Non deas por feito que a lista está completa porque o acceso interactivo funciona; comproba que require a función para a túa rexión e subscricións antes de concluír que o clúster está roto.

A sinatura do fallo axuda. Se a petición nunca chega á autenticación, é o filtro. Se se autentica e despois recibe un erro de permisos, o filtro fixo o seu traballo e o problema é o control de acceso por roles, que a lista de autorizados nunca toca.

Constrúe a lista enteira cunha soa orde

O parámetro de actualización substitúe a lista enteira en lugar de engadir unha entrada, así que unha orde que só leva o enderezo da VPN descarta silenciosamente todo o demais que había. Le primeiro o valor actual, gárdao e envía a unión:

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

Usa unha IP pública reservada para o servidor VPN antes de confiar nisto. Un enderezo dinámico cambia ao reconectar e cada cambio deixa o equipo fóra do clúster en silencio ata que alguén actualice a lista desde unha rede que aínda está permitida. Se tes dous puntos de saída VPN por redundancia, lista os dous, porque o filtro non ten concepto de camiño preferido.

Ordena o cambio para que o primeiro intento permitido sexa tamén a proba. Anuncia a lista nova, aplícaa e conéctate desde a VPN de inmediato; facelo na orde inversa deixa unha xanela na que ninguén pode chegar ao servidor API para corrixir un erro de tecleado nun bloque CIDR.

O que a lista de autorizados nunca cubriu

Non fai o servidor API privado. Un clúster privado usa un punto final privado e DNS privado, e a lista de rangos autorizados non é o control que o substitúe. Tampouco cambia o que pode facer un solicitante admitido, así que un kubeconfig de administrador filtrado segue funcionando desde calquera enderezo permitido. Trata a credencial como a fronteira de seguridade e a lista como unha comodidade de rede.

Non ten nada que ver coas cargas de traballo. Os Pods e os Services seguen funcionando coa lista activada, e chegar a unha aplicación pola VPN é un problema aparte: un Service que só ten unha IP de clúster aínda necesita un balanceador de carga interno, un ingress ou un port-forward antes de que un portátil poida abrirlo. Mesturar estes dous deseños produce un tícket de cambio que di restrinxir os desenvolvedores e en realidade non restrinxe nada das aplicacións.

Verifica desde ambos os lados e despois executa unha operación real

Proba cun cliente novo na VPN e cun cliente fóra dela. O intento de fóra debería rexeitarse no servidor API, non na resolución de nomes; se o nome non se resolve, estás probando o DNS e non aprendiches nada sobre o filtro. Despois executa unha operación que non sexa unha chamada interactiva de kubectl, como unha ampliación de node pool ou unha comprobación de actualización, e confirma que remata en lugar de supoñer que o fará.

Anota o valor anterior da lista xunto ao cambio e volve ler o valor efectivo despois da actualización en lugar de confiar na orde tecleada. A documentación de AKS sobre rangos IP autorizados lista os parámetros admitidos e os requisitos de plataforma que pertencen á mesma lista, que é a parte que a maioría das descricións de tíquets omiten.