kubectl funziona tramite la VPN, ma AKS smette di scalare: perché

Aggiunge l’indirizzo pubblico della VPN dell’ufficio all’elenco consentito del server API AKS, e kubectl funziona. Una settimana dopo il ridimensionamento di un pool di nodi fallisce, un job CI non riesce a raggiungere il cluster e il portale mostra un errore che non menziona gli intervalli IP. Nessuno ha modificato l’elenco consentito. Il controllo che ha abilitato è un filtro di IP pubblici davanti al server API, e non sa chi chiama, solo da quale indirizzo arriva la chiamata. La VPN è uno dei vari indirizzi di cui il cluster ha bisogno, e raramente è quello che si rompe per primo.

L’elenco consentito corrisponde a un indirizzo, non a una persona

--api-server-authorized-ip-ranges accetta blocchi CIDR, non utenti o gruppi. Quando la richiesta di uno sviluppatore lascia il server VPN per Azure, l’indirizzo sorgente sul server API è l’uscita pubblica del server VPN. Ogni persona su quella VPN condivide quindi una sola voce, e chiunque sia fuori dalla VPN viene rifiutato prima ancora dell’autenticazione.

Ciò significa anche che la voce ammette più persone di quante forse intenda. Un collaboratore esterno con accesso VPN, un portatile personale sullo stesso concentratore e un account compromesso arrivano tutti dallo stesso indirizzo. L’autorizzazione del cluster resta invariata, quindi il controllo degli accessi basato sui ruoli decide ancora cosa può fare il chiamante, ma l’elenco consentito non è un controllo di identità e non dovrebbe mai essere descritto come tale.

Ciò che si rompe per primo di solito non è kubectl

L’elenco consentito si applica all’endpoint pubblico del server API, quindi tutto ciò che è fuori dagli indirizzi elencati smette subito di funzionare. Le vittime ovvie sono la seconda sede senza una rotta VPN, un runner CI in una pipeline ospitata e un portatile che ha dimenticato di connettersi. Sono facili da riconoscere perché c’è una persona che aspetta.

Il caso meno ovvio è l’automazione guidata da Azure o dai suoi strumenti. Alcune operazioni avviate dalla piattaforma raggiungono il server API da indirizzi che non sono la sua VPN, e quando una di esse inizia a fallire subito dopo il rafforzamento dell’elenco, il momento è l’indizio. Non presupponga che l’elenco sia completo perché l’accesso interattivo funziona; verifichi cosa richiede la funzionalità per la sua area e le sue sottoscrizioni prima di concludere che il cluster è guasto.

La firma del guasto aiuta. Se la richiesta non arriva mai all’autenticazione, è il filtro. Se si autentica e poi riceve un errore di autorizzazione, il filtro ha fatto il suo lavoro e il problema è il controllo degli accessi basato sui ruoli, che l’elenco consentito non tocca mai.

Crei l’intero elenco con un solo comando

Il parametro di aggiornamento sostituisce l’intero elenco invece di aggiungere una voce, quindi un comando che porta solo l’indirizzo VPN elimina silenziosamente tutto il resto. Legga prima il valore attuale, lo conservi e invii l’unione:

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

Usi un IP pubblico prenotato per il server VPN prima di fare affidamento su questo. Un indirizzo dinamico cambia alla riconnessione, e ogni cambiamento esclude silenziosamente il team dal cluster finché qualcuno non aggiorna l’elenco da una rete ancora consentita. Se ha due punti di uscita VPN per la ridondanza, li elenchi entrambi, perché il filtro non ha alcun concetto di percorso preferito.

Ordini la modifica in modo che il primo tentativo consentito sia anche il test. Annunci il nuovo elenco, lo applichi e si connetta subito dalla VPN; nell’ordine inverso resta una finestra in cui nessuno può raggiungere il server API per correggere un errore di battitura in un blocco CIDR.

Ciò che l’elenco consentito non ha mai coperto

Non rende privato il server API. Un cluster privato usa un endpoint privato e DNS privato, e l’elenco degli intervalli autorizzati non è il controllo che lo sostituisce. Non cambia nemmeno ciò che può fare un chiamante ammesso, quindi un kubeconfig di amministratore trafugato funziona ancora da qualsiasi indirizzo consentito. Tratti la credenziale come il confine di sicurezza e l’elenco come una comodità di rete.

Non ha nulla a che vedere con i carichi di lavoro. I pod e i servizi continuano a funzionare con l’elenco abilitato, e raggiungere un’applicazione tramite la VPN è un problema separato: un servizio che ha solo un IP di cluster ha comunque bisogno di un bilanciatore di carico interno, di un ingress o di un port-forward prima che un portatile possa aprirlo. Mescolare questi due progetti produce un ticket di modifica che dichiara di limitare gli sviluppatori e in realtà non limita nulla delle applicazioni.

Verifichi da entrambi i lati, poi esegua una vera operazione

Provi con un client nuovo sulla VPN e con un client fuori. Il tentativo dall’esterno dovrebbe essere rifiutato sul server API, non nella risoluzione dei nomi; se il nome non si risolve, sta testando il DNS e non ha imparato nulla sul filtro. Poi esegua un’operazione che non sia una chiamata kubectl interattiva, come il ridimensionamento di un pool di nodi o un controllo di aggiornamento, e confermi che termina invece di darlo per scontato.

Conservi il valore precedente dell’elenco accanto alla modifica e rilegga il valore effettivo dopo l’aggiornamento invece di fidarsi del comando digitato. La documentazione sugli intervalli IP autorizzati di AKS elenca i parametri supportati e i requisiti della piattaforma che appartengono allo stesso elenco, che è la parte che la maggior parte delle descrizioni dei ticket omette.