Whitelisting degli indirizzi IP su Kubernetes: Cosa abbiamo imparato

L'ingegnere di sistemi Linode Jon "jfred" Frederickson condivide la sua esperienza nella creazione della funzione di whitelisting IP per l'esecuzione di Kubernetes su Linode.

Mentre il team di ingegneri di Linode costruiva le nostre funzionalità Kubernetes, abbiamo incontrato molti ostacoli, come previsto. Tuttavia, è emersa una sfida che non avevamo previsto: come inserire nella whitelist le applicazioni che girano in Kubernetes sull'infrastruttura che già abbiamo.

Qui a Linode gestiamo diverse applicazioni interne. Utilizzando le regole del firewall, queste applicazioni sono accessibili solo alle reti e ai sistemi che ne hanno bisogno.

Se si dispone di un'applicazione con un proprio database, probabilmente il database deve essere raggiungibile solo dalle istanze di quell'applicazione. Se entrambi sono in esecuzione in un cluster Kubernetes, è abbastanza semplice; le NetworkPolicies consentono di bloccare questo aspetto. D'altra parte, se un servizio è in esecuzione al di fuori del cluster, le cose iniziano a complicarsi.

Avevamo già una certa automazione della whitelist degli IP, ma i cluster Kubernetes hanno il potenziale per essere più dinamici di qualsiasi altra cosa nella nostra infrastruttura. Per questo motivo dovevamo assicurarci di poter mantenere aggiornate le nostre whitelist man mano che i nodi venivano aggiunti e rimossi dai cluster. Abbiamo pensato che si trattasse di un problema abbastanza comune per chi introduce Kubernetes in un'infrastruttura esistente, ma non abbiamo trovato altre soluzioni pubbliche al problema.

Il problema

La mia sfida era: se volessi inserire nella whitelist tutti i nodi di un cluster specifico su un server esterno al cluster, come sarebbe la mia configurazione ideale?

Senza gli strumenti Kubernetes-aware, sarei costretto a inserire manualmente nella whitelist i singoli indirizzi IP dei nodi del cluster, uno per uno. Questo non solo richiede molto tempo, ma introduce un maggiore potenziale di errore umano, che rappresenta un ostacolo importante nel processo di sviluppo.

La soluzione

Nelle due settimane successive ho costruito una soluzione che (per lo più) rende il whitelisting di un cluster Kubernetes semplice come il whitelisting manuale di un singolo IP.

Utilizziamo Salt per gestire la nostra infrastruttura e avevamo già una formula Salt per gestire le regole del firewall. Tra le infrastrutture iscritte a Salt, avevamo già dei meccanismi per trovare i sistemi di una determinata classe durante la creazione delle whitelist, quindi stavamo cercando qualcosa di simile per i nostri cluster Kubernetes.

Salt è estremamente flessibile e rende facile la scrittura di moduli personalizzati. Per esempio, la nostra formula iptables ne utilizza una per generare regole iptables dalla configurazione per nodo di Salt(dati "pillar"). Lo facciamo costruendo una regola alla volta da un elenco di regole memorizzate in pillar. Si tratta di un sacco di concatenazioni di stringhe, che a dire il vero sembrano un po' brutte. Fortunatamente, il formato delle regole di iptables è abbastanza stabile da funzionare abbastanza bene. Ecco un frammento di ciò che appare:

Grazie alla flessibilità di Kubernetes APIquesta integrazione non è stata poi così difficile dal punto di vista concettuale. In sostanza, abbiamo aggiunto un nuovo tipo di regola per i cluster K8s: quando la formula incontra una regola di quel tipo, si rivolge a quel cluster per recuperare gli IP dei suoi nodi, li memorizza nella cache locale e inserisce le regole iptables per ogni IP. La cache serve a garantire che i guasti intermittenti della rete non causino problemi. Ecco come appare l'utilizzo:

Cosa c'è dopo?

In definitiva, vorrei rendere open source l'intera formula per sviluppare ulteriormente le capacità dello strumento con l'aiuto della comunità Linode.

Il prossimo passo, però, è quello di far sì che queste regole si aggiornino automaticamente quando nuovi nodi entrano ed escono da un cluster. L'obiettivo è che il whitelisting persistente di un cluster sia semplice come il whitelisting di un singolo IP, ma non ci siamo ancora arrivati.

La formula attuale prevede il rilevamento di nuovi nodi solo quando viene applicata la configurazione del firewall, ma non automaticamente. Questo non è un problema, perché si può aggirare il problema riapplicando periodicamente la configurazione del firewall.

Tuttavia, vorrei trovare un modo per renderlo più reattivo. Il mio meccanismo immaginato dovrebbe ascoltare l'evento (la creazione di un nuovo oggetto Node in Kubernetes) e attivare un aggiornamento (probabilmente attraverso il bus di eventi Salt ). Idealmente, questo non richiederebbe alcun passaggio manuale, a parte la configurazione di una regola del firewall di Kubernetes. Forse, una volta che avremo reso open source la formula, potrete aiutarci a capirlo!

Per ora sono molto soddisfatto di ciò che abbiamo creato e credo che sarà una risorsa per gli utenti Linode che sperimentano Kubernetes.

Grazie per aver appreso il processo di ingegneria dei sistemi di Linode. Fatemi sapere nella sezione commenti se avete domande su ciò che abbiamo fatto.

Siete interessati a Kubernetes su Linode?

Il nostro team è orgoglioso di presentare la versione beta di Linode Kubernetes Engine (LKE), un motore di orchestrazione di container completamente gestito per la distribuzione e la gestione di applicazioni e carichi di lavoro containerizzati.

Abbiamo però bisogno del vostro feedback. Iscrivetevi alla beta di LKE qui per provarla e per guadagnare un premio Linode gratuito.