Mettere l’API di EKS dietro una VPN: ordine delle operazioni

Abilitate l’endpoint privato, dimostrate che kubectl lo ha raggiunto, poi chiudete quello pubblico. Un runbook a fasi con i comandi e i controlli tra ogni passo.

La versione pericolosa di questa modifica è un solo comando che ribalta l’endpoint e blocca fuori tutti gli amministratori nello stesso momento. La versione sicura tiene aperti entrambi i percorsi, dimostra che quello privato funziona dalla VPN, e solo allora ritira l’endpoint pubblico. Date per scontati un cluster esistente, un tunnel approvato verso il suo VPC e un kubeconfig che già funziona; il lavoro è l’accesso privato all’API di Kubernetes, non i nodi privati e non un nuovo modello di autorizzazioni. Ogni passo qui sotto ha un controllo su cui potete fallire in sicurezza.

1. Inventariate l’endpoint e conservate una via di ritorno

Registrate lo stato attuale prima di modificarlo, compresa la lista CIDR pubblica degli indirizzi consentiti e il gruppo di sicurezza del cluster. Sono quei due che confronterete quando qualcosa smetterà di funzionare, e la lista consentita è anche la vostra via di rollback se il percorso privato si rivela sbagliato.

aws eks describe-cluster --region REGION --name CLUSTER \
  --query 'cluster.{endpoint:endpoint,public:resourcesVpcConfig.endpointPublicAccess,private:resourcesVpcConfig.endpointPrivateAccess,cidrs:resourcesVpcConfig.publicAccessCidrs}'

REGION e CLUSTER qui sono segnaposto. Notate cosa indica ora il flag privato, perché un cluster creato con l’accesso privato già abilitato richiede un primo passo diverso da uno che non l’ha mai avuto. Mantenete aperta almeno una via amministrativa approvata durante la transizione; una VPN che dipende dalla raggiungibilità dello stesso cluster non è una via di ripristino.

2. Abilitate l’accesso privato con il percorso di rete già pronto

Accendere il flag è la metà facile. Il tunnel ha bisogno di una rotta verso gli indirizzi privati dell’endpoint, e il gruppo di sicurezza del cluster ha bisogno di TCP 443 dalla sorgente che la VPN presenta davvero. Un’associazione Client VPN, un gateway site-to-site e un VPC con peering possono tutti presentare indirizzi di origine diversi, quindi usate il modello che avete distribuito invece di un intervallo privato generico.

aws eks update-cluster-config --region REGION --name CLUSTER \
  --resources-vpc-config endpointPublicAccess=true,endpointPrivateAccess=true

aws eks describe-update --region REGION --name CLUSTER --update-id UPDATE_ID

L’aggiornamento è asincrono. Interrogate l’id di aggiornamento finché non segnala successo invece di aspettare un numero fisso di secondi e darlo per scontato. Lasciate in pace il traffico dei nodi e del piano di controllo mentre fate questo: sostituire l’intero gruppo di sicurezza del cluster con una regola per il vostro portatile è il modo in cui un piano dati funzionante diventa un secondo incidente.

La documentazione sugli endpoint di EKS merita una lettura completa, perché dice che l’accesso solo privato può arrivare dal VPC o da una rete connessa. Quella frase è tutta la ragione per cui questa migrazione è possibile, ed è anche il motivo per cui esiste il passo successivo.

3. Dimostrate che la workstation ha usato il percorso privato

Con entrambi gli endpoint abilitati, un kubectl get ns riuscito non dimostra nulla su quale abbia risposto. Risolvete il nome host dell’endpoint e controllate se l’indirizzo ottenuto appartiene all’intervallo privato o a quello pubblico. Se la vostra rete connessa non riceve la vista privata tramite DNS, il comando riuscirà sull’endpoint pubblico e ritirerete il percorso pubblico su prove false. È il modo più comune in cui questa migrazione va storta, e sembra esattamente un successo.

nslookup HASH.gr7.REGION.eks.amazonaws.com
kubectl cluster-info
kubectl get ns --request-timeout=10s

Mantenete il nome host e la validazione del certificato esattamente come sono. Sostituire con un IP privato nel kubeconfig e saltare la verifica TLS non è la migrazione che avete descritto nel record di modifica, e fallirà di nuovo nel momento in cui l’endpoint ruoterà.

4. Ritirate l’accesso pubblico deliberatamente

Una volta dimostrato il percorso privato e approvato il flusso di ripristino, chiudete l’endpoint pubblico. Questa è una modifica reale e non un’anteprima, quindi eseguitela sull’account e sulle impostazioni che intendete davvero.

aws eks update-cluster-config --region REGION --name CLUSTER \
  --resources-vpc-config endpointPublicAccess=false,endpointPrivateAccess=true

In modalità solo privata il nome DNS pubblico si risolve negli indirizzi privati dell’endpoint dall’interno del VPC, quindi risoluzione e raggiungibilità smettono di essere la stessa cosa. Tutto ciò che dipendeva dall’indirizzo pubblico, compresi i runner CI o un portatile su un’altra rete, ora ha bisogno del proprio percorso di ingresso.

5. Tenete separate la politica di rete e la politica di identità

La lista CIDR dell’accesso pubblico governa solo l’endpoint pubblico. Non vincola l’endpoint privato, che invece è delimitato dal gruppo di sicurezza del cluster e dalla politica della rete connessa. Se mantenete l’endpoint pubblico, la sua lista consentita deve corrispondere all’egress pubblico che i vostri client API e nodi usano davvero; un indirizzo del pool VPN raramente è quella sorgente.

Niente di tutto questo cambia IAM o Kubernetes RBAC. Le impostazioni dell’endpoint sono un’azione amministrativa, e gli utenti ordinari non dovrebbero ricevere il permesso di allentare il confine solo per raggiungere l’API. Scrivete lo stato finale, la data e il percorso di ripristino nel runbook, poi provate il percorso di ripristino una volta mentre è ancora facile.

Articoli correlati