Avete mai sentito parlare di air gap? Si tratta di un concetto cruciale nel mondo della sicurezza informatica che implica l’isolamento di un sistema, o di una rete di sistemi, da qualsiasi connessione diretta o indiretta con reti esterne, compresa internet.

Gli ambiti in cui viene utilizzato questo approccio sono svariati, e quasi sempre viene implementato per mitigare i rischi di sicurezza, proteggere dati sensibili e garantire l’integrità delle operazioni in ambienti critici. Per citare il primo esempio che viene in mente basti pensare alle infrastrutture finanziarie, dove vengono generate le carte di credito: oltre ad essere asettici (letteralmente con persone vestite in modalità rischio batteriologico) questi ambienti hanno anche la peculiarità di essere, per ovvie ragioni di sicurezza, ovviamente disconnesse da qualsiasi rete esterna.

Se però l’airgap può rappresentare una difesa formidabile contro molte minacce, quando si tratta di far funzionare le applicazioni presenta sfide significative, se poi si pensa a sistemi complessi come Kubernetes, che per natura in fase di installazione la prima cosa che fa è scaricare pacchetti da internet, si fa in fretta a capire come le cose possano complicarsi.

In un recente articolo dal titolo Bootstrap an Air Gapped Cluster With Kubeadm vengono esplorate proprio le funzionalità implementate per kubeadm il comando base per l’inizializzazione/installazione di un cluster Kubernetes.

La modalità con cui questo tipo di installazioni funziona è riassunta da un chiarissimo schema:

In cui la legenda spiega quali sono le fasi pratiche da svolgere per creare il cluster.

Di seguito il riassunto estremamente sintetizzato delle fasi, che ovviamente è possibile seguire in maniera dettagliata nel documento.

I “normali” step di installazione per i singoli nodi vengano sempre e comunque rispettati (per i dettagli si può far riferimento a Kubelab, un ruolo Ansible che abbiamo sviluppato a fini didattici proprio per spiegare quali sono le varie fasi di installazione di Kubernetes), ma a far la differenza sono le fasi manuali che prevedono lo scaricamento dei pacchetti e di tutte le immagini dei container di componenti Kubernetes che dovranno essere usate poi sui vari nodi.

Perché tutti i lettori sanno come Kubernetes, che è un sistema di orchestrazione di container, funziona per mezzo di container, vero? Fortunatamente come spiega l’articolo i pacchetti e le immagini sono tutti di facile reperimento (basti pensare che recentemente anche i pacchetti della runtime CRI-O sono stati resi disponibili nei repository ufficiali).

Da qui in poi, pacchetti e immagini verranno trasportati sulla macchina workstation all’interno dell’ambiente airgapped ed a colpi di tar e docker load si finirà per abilitare un registry locale che farà da “pancia” a tutte le immagini necessarie all’inizializzazione.

Sarà quindi il momento di utilizzare kubeadm affinché punti alla workstation contenente tutti gli i pacchetti e le immagini, in modo che il cluster possa essere inizializzato.

Il consueto file di configurazione kubeadm_config.yaml conterrà i puntamenti alle risorse interne:

apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
clusterName: kubernetes
kubernetesVersion: v1.27.3
networking:
    dnsDomain: cluster.local
    podSubnet: 10.244.0.0/16 # --pod-network-cidr
    serviceSubnet: 10.96.0.0/12
---
apiVersion: kubeadm.k8s.io/v1beta3
kind: InitConfiguration
localAPIEndpoint:
    advertiseAddress: 10.10.10.10 # Update to the IP address of the air gap VM
    bindPort: 6443
nodeRegistration:
    criSocket: unix:///run/containerd/containerd.sock # or rely on autodetection
    name: airgap # this must match the hostname of the air gap VM

Dove infatti si nota il commento “Update to the IP address of the air gap VM“, quello sarà appunto l’indirizzo della macchina ponte.

L’inizializzazione avverrà quindi usando kubeadm:

kubeadm init --config kubeadm_config.yaml

Ed i puntamenti interni sono appunto la chiave per comprendere questa modalità di installazione poiché, come è facile immaginare, qualsiasi applicazione si vorrà poi lanciare all’interno dell’ambiente isolato dovrà essere presente nel repository interno, altrimenti non potrà essere eseguita.

Quindi per dirla alla Gene Wilder: Si. Può. Fare.

Certamente complicato, ma assolutamente sicuro!

Raoul Scarazzini

Da sempre appassionato del mondo open-source e di Linux nel 2009 ho fondato il portale Mia Mamma Usa Linux! per condividere articoli, notizie ed in generale tutto quello che riguarda il mondo del pinguino, con particolare attenzione alle tematiche di interoperabilità, HA e cloud.
E, sì, mia mamma usa Linux dal 2009.