Per què kubectl funciona per la VPN però AKS deixa d'escalar

Afegiu l'adreça pública de la VPN de l'oficina a la llista d'autoritzats del servidor API d'AKS i kubectl funciona. Una setmana després, una ampliació d'un node pool falla, una tasca de CI no pot arribar al clúster i el portal mostra un error que no diu res sobre rangs IP. Ningú no ha canviat la llista. El control que heu activat és un filtre d'IP pública davant del servidor API i no sap qui truca, només de quina adreça ve la trucada. La VPN és una adreça entre diverses que el clúster necessita i poques vegades és la primera que es trenca.

La llista d'autoritzats encaixa amb una adreça, no amb una persona

--api-server-authorized-ip-ranges accepta blocs CIDR, no usuaris ni grups. Quan la petició d'un desenvolupador surt del servidor VPN cap a Azure, l'adreça d'origen al servidor API és l'egress públic del servidor VPN. Per tant, tothom en aquesta VPN comparteix una entrada i a qualsevol que sigui fora de la VPN se li denega abans que passi l'autenticació.

Això també vol dir que l'entrada admet més gent de la que voldríeu. Un contractista amb accés a la VPN, un portàtil personal al mateix concentrador i un compte compromès arriben tots des de la mateixa adreça. L'autorització del clúster no canvia, així que el control d'accés per rols segueix decidint què pot fer el sol·licitant, però la llista d'autoritzats no és un control d'identitat i no s'hauria de descriure mai com a tal.

El que es trenca primer normalment no és kubectl

La llista d'autoritzats s'aplica al punt final públic del servidor API, així que tot el que queda fora de les adreces llistades deixa de funcionar de cop. Les víctimes evidents són la segona oficina sense ruta VPN, un executor de CI en un pipeline allotjat i un portàtil que va oblidar connectar-se. Són fàcils de reconèixer perquè hi ha una persona esperant.

El cas menys evident és l'automatització que impulsen Azure o les vostres eines. Algunes operacions iniciades per la plataforma arriben al servidor API des d'adreces que no són la vostra VPN, i quan una comença a fallar just després d'estrènyer la llista, el moment és la pista. No doneu per fet que la llista és completa perquè l'accés interactiu funciona; comproveu què requereix la funció per a la vostra regió i subscripcions abans de concloure que el clúster està trencat.

La signatura del fracàs ajuda. Si la petició no arriba mai a l'autenticació, és el filtre. Si s'autentica i després rep un error de permisos, el filtre ha fet la feina i el problema és el control d'accés per rols, que la llista d'autoritzats no toca mai.

Construïu la llista sencera amb una ordre

El paràmetre d'actualització substitueix la llista sencera en lloc d'afegir una entrada, així que una ordre que només porta l'adreça de la VPN descarta silenciosament tot la resta que hi havia. Llegiu primer el valor actual, conserveu-lo i envieu la unió:

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

Feu servir una IP pública reservada per al servidor VPN abans de confiar-hi. Una adreça dinàmica canvia en reconnectar-se, i cada canvi tanca silenciosament l'equip fora del clúster fins que algú actualitza la llista des d'una xarxa que encara està permesa. Si teniu dos punts d'egress de VPN per redundància, llisteu-los tots dos, perquè el filtre no té cap concepte de camí preferit.

Ordeneu el canvi perquè el primer intent permès sigui també la prova. Anuncieu la llista nova, apliqueu-la i connecteu-vos des de la VPN immediatament; fer-ho a l'inrevés deixa una finestra en què ningú pot arribar al servidor API per corregir una errata en un bloc CIDR.

Què no ha cobert mai la llista d'autoritzats

No fa que el servidor API sigui privat. Un clúster privat utilitza un punt final privat i DNS privat, i la llista de rangs autoritzats no és el control que el substitueix. Tampoc no canvia què pot fer un sol·licitant admès, així que un kubeconfig d'administrador filtrat encara funciona des de qualsevol adreça permesa. Tracteu la credencial com la frontera de seguretat i la llista com una comoditat de xarxa.

No té res a veure amb les càrregues de treball. Els Pods i els Services continuen funcionant amb la llista activada, i arribar a una aplicació per la VPN és un problema a part: un Service que només té una IP de clúster encara necessita un balancejador de càrrega intern, un ingress o un port-forward abans que un portàtil el pugui obrir. Barrejar aquests dos dissenys produeix un tiquet de canvi que diu restringir els desenvolupadors i en realitat no restringeix res de les aplicacions.

Verifiqueu des de tots dos costats i després executeu una operació real

Proveu amb un client nou a la VPN i amb un client fora d'ella. L'intent de fora s'hauria de rebutjar al servidor API, no a la resolució de noms; si el nom no es resol, esteu provant el DNS i no heu après res del filtre. Després executeu una operació que no sigui una crida interactiva de kubectl, com ara una ampliació de node pool o una comprovació d'actualització, i confirmeu que acaba en lloc de suposar que ho farà.

Anoteu el valor anterior de la llista al costat del canvi i torneu a llegir el valor efectiu després de l'actualització en lloc de confiar en l'ordre teclejada. La documentació d'AKS sobre rangs IP autoritzats llista els paràmetres suportats i els requisits de plataforma que pertanyen a la mateixa llista, que és la part que la majoria de descripcions de tiquets ometen.