kubectl funciona por la VPN, pero AKS deja de escalar: por qué

Añada la dirección pública de la VPN de la oficina a la lista de permitidos del servidor de API de AKS, y kubectl funciona. Una semana después falla el escalado de un grupo de nodos, un trabajo de CI no puede llegar al clúster y el portal muestra un error que no menciona nada sobre rangos IP. Nadie cambió la lista de permitidos. El control que activó es un filtro de IP pública delante del servidor de API, y no sabe quién llama, solo de qué dirección viene la llamada. La VPN es una dirección entre varias que el clúster necesita, y rara vez es la que falla primero.

La lista de permitidos coincide con una dirección, no con una persona

--api-server-authorized-ip-ranges acepta bloques CIDR, no usuarios ni grupos. Cuando la solicitud de un desarrollador sale del servidor VPN hacia Azure, la dirección de origen en el servidor de API es la salida pública del servidor VPN. Por tanto, cada persona de esa VPN comparte una sola entrada, y cualquiera fuera de la VPN es rechazado antes de que siquiera ocurra la autenticación.

Eso también significa que la entrada admite más personas de las que quizá pretenda. Un contratista con acceso a la VPN, un portátil personal en el mismo concentrador y una cuenta comprometida llegan todos desde la misma dirección. La autorización del clúster no cambia, así que el control de acceso basado en roles sigue decidiendo qué puede hacer quien llama, pero la lista de permitidos no es un control de identidad y nunca debería describirse como tal.

Lo que falla primero normalmente no es kubectl

La lista de permitidos se aplica al punto de conexión público del servidor de API, así que todo lo que esté fuera de las direcciones incluidas deja de funcionar de inmediato. Las víctimas obvias son la segunda oficina sin ruta VPN, un ejecutor de CI en una canalización alojada y un portátil que olvidó conectarse. Son fáciles de reconocer porque hay una persona esperando.

El caso menos obvio es la automatización que impulsa Azure o sus propias herramientas. Algunas operaciones iniciadas por la plataforma llegan al servidor de API desde direcciones que no son su VPN, y cuando una de ellas empieza a fallar justo después de endurecer la lista, el momento es la pista. No suponga que la lista está completa porque el acceso interactivo funcione; compruebe qué exige la característica para su región y sus suscripciones antes de concluir que el clúster está roto.

La firma del fallo ayuda. Si la solicitud nunca llega a la autenticación, es el filtro. Si se autentica y luego recibe un error de permisos, el filtro hizo su trabajo y el problema es el control de acceso basado en roles, que la lista de permitidos nunca toca.

Cree la lista completa con un solo comando

El parámetro de actualización sustituye toda la lista en lugar de añadir una entrada, así que un comando que solo lleva la dirección VPN descarta en silencio todo lo demás que había. Lea primero el valor actual, consérvelo y envíe la 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

Use una IP pública reservada para el servidor VPN antes de depender de esto. Una dirección dinámica cambia al reconectar, y cada cambio deja al equipo fuera del clúster en silencio hasta que alguien actualiza la lista desde una red que aún está permitida. Si tiene dos puntos de salida VPN por redundancia, incluya ambos, porque el filtro no concibe una ruta preferida.

Ordene el cambio para que el primer intento permitido sea también la prueba. Anuncie la nueva lista, aplíquela y conéctese desde la VPN de inmediato; hacerlo al revés deja una ventana en la que nadie puede llegar al servidor de API para corregir una errata en un bloque CIDR.

Lo que la lista de permitidos nunca cubrió

No hace que el servidor de API sea privado. Un clúster privado usa un punto de conexión privado y DNS privado, y la lista de rangos autorizados no es el control que lo sustituye. Tampoco cambia lo que puede hacer quien llama una vez admitido, así que un kubeconfig de administrador filtrado sigue funcionando desde cualquier dirección permitida. Trate la credencial como el límite de seguridad y la lista como una comodidad de red.

No tiene nada que ver con las cargas de trabajo. Los pods y los servicios siguen funcionando con la lista activada, y llegar a una aplicación por la VPN es un problema aparte: un servicio que solo tiene una IP de clúster aún necesita un balanceador de carga interno, un ingress o un port-forward antes de que un portátil pueda abrirlo. Mezclar esos dos diseños produce un ticket de cambio que dice restringir a los desarrolladores y en realidad no restringe nada de las aplicaciones.

Verifique desde ambos lados y luego ejecute una operación real

Pruebe con un cliente nuevo en la VPN y con un cliente fuera de ella. El intento desde fuera debería rechazarse en el servidor de API, no en la resolución de nombres; si el nombre no se resuelve, está probando DNS y no ha aprendido nada sobre el filtro. Después ejecute una operación que no sea una llamada interactiva de kubectl, como escalar un grupo de nodos o una comprobación de actualización, y confirme que termina en lugar de suponerlo.

Registre el valor anterior de la lista junto al cambio y vuelva a leer el valor efectivo después de la actualización en lugar de confiar en el comando escrito. La documentación de rangos IP autorizados de AKS enumera los parámetros admitidos y los requisitos de plataforma que deben figurar en la misma lista, que es la parte que omiten la mayoría de las descripciones de tickets.