Kubernetes 1.37 compie un importante passo avanti verso l'esecuzione dei propri componenti senza privilegi di amministratore: la funzione KubeletInUserNamespace, conosciuta più semplicemente come Rootless mode, è stata promossa alla fase Beta.
La novità permette ai principali componenti che gestiscono un nodo Kubernetes — kubelet, runtime CRI e OCI, plugin CNI e kube-proxy — di essere eseguiti come utenti non root sul sistema host attraverso gli user namespace del kernel Linux.
Può sembrare una modifica destinata soltanto agli amministratori di grandi infrastrutture, ma riguarda uno dei principi fondamentali della sicurezza informatica: un programma dovrebbe ricevere soltanto i privilegi realmente necessari per svolgere il proprio lavoro.
Tradizionalmente molti componenti delle infrastrutture container vengono eseguiti con privilegi elevati perché devono configurare rete, filesystem, namespace, cgroup e altre risorse del sistema operativo. Questa impostazione semplifica alcune operazioni, ma aumenta anche le conseguenze potenziali di una vulnerabilità: compromettere un processo che opera come root può offrire all'attaccante possibilità molto maggiori rispetto alla compromissione di un processo confinato.
Il Rootless mode cerca di ridurre questa superficie.
La tecnologia fondamentale utilizzata da Kubernetes è rappresentata dagli user namespace di Linux. Il kernel permette di creare uno spazio nel quale un processo può possedere apparentemente determinati privilegi senza possederli realmente sull'intero sistema host.
In altre parole, un processo può essere “root” all'interno del proprio namespace ma corrispondere a un normale utente non privilegiato all'esterno.
È una forma di isolamento particolarmente interessante perché consente di applicare più concretamente il principio del minimo privilegio.
Il lavoro di Kubernetes su questa possibilità non nasce oggi. Gli sviluppatori hanno iniziato gli esperimenti nel 2018 e la funzionalità KubeletInUserNamespace è entrata nel progetto come Alpha con Kubernetes 1.22, pubblicato nel 2021. Dopo cinque anni di sviluppo e sperimentazione, Kubernetes 1.37 la considera abbastanza matura da promuoverla in Beta.
È importante però non confondere due tecnologie differenti.
Kubernetes dispone già del supporto agli user namespace per i Pod, diventato stabile con Kubernetes 1.36. In quel caso vengono isolati i processi eseguiti all'interno dei container, mentre i componenti che amministrano il nodo continuano normalmente a funzionare come root.
Il nuovo Rootless mode interviene a un livello differente: riguarda proprio l'infrastruttura che gestisce il nodo.
Le due tecnologie possono inoltre essere utilizzate insieme.
Questa combinazione apre scenari particolarmente interessanti, tra cui la possibilità di eseguire Kubernetes dentro Kubernetes senza dover necessariamente concedere al cluster interno il tradizionale privileged: true, un'autorizzazione estremamente potente che riduce significativamente l'isolamento rispetto al sistema host.
La nuova funzione non significa comunque che Kubernetes sia improvvisamente diventato completamente privo di privilegi.
Gli sviluppatori indicano ancora alcune limitazioni. Determinate configurazioni di rete, storage e funzionalità dipendenti dall'accesso diretto all'hardware possono richiedere capacità particolari o configurazioni aggiuntive. La classificazione Beta indica proprio che il progetto considera la tecnologia sufficientemente matura per un utilizzo più ampio, ma il percorso non è ancora concluso.
La novità si inserisce in una versione particolarmente ricca.
Kubernetes 1.37 “Garhwal” contiene complessivamente 67 miglioramenti: 16 funzionalità sono diventate stabili, 23 sono passate in Beta e 27 entrano per la prima volta nella fase Alpha.
Tra queste troviamo anche la possibilità, ora Beta e abilitata per impostazione predefinita, di portare determinati workload automaticamente fino a zero repliche attraverso HorizontalPodAutoscaler.
È una funzione importante soprattutto per elaborazioni batch, code di lavoro e carichi che utilizzano risorse costose come CPU dedicate o GPU: quando non c'è nulla da elaborare, l'ultimo Pod può essere spento e successivamente ricreato quando torna il lavoro.
La versione 1.37 porta inoltre allo stato stabile la Metrics API utilizzata, tra le altre cose, dal comando kubectl top e dai meccanismi di autoscaling basati sulle risorse.
Dietro queste funzioni esiste però un aspetto più generale.
Kubernetes è diventato una componente fondamentale di una parte enorme delle moderne infrastrutture informatiche. Permette di distribuire e amministrare applicazioni containerizzate su cluster che possono andare da poche macchine a enormi infrastrutture cloud.
Ed è proprio quando un progetto libero raggiunge questo livello di diffusione che la questione della sicurezza assume una dimensione particolare.
Non basta aggiungere continuamente nuove funzioni. Bisogna anche ridurre progressivamente la quantità di fiducia e privilegi richiesta a ciascun componente.
Il Rootless mode segue esattamente questa direzione.
È anche un buon esempio di come differenti tecnologie del Software Libero possano costruirsi l'una sull'altra: Kubernetes utilizza funzionalità degli user namespace offerte dal kernel Linux, runtime e strumenti container collaborano con questi meccanismi e l'intera infrastruttura può essere studiata e migliorata da comunità differenti.
Naturalmente utilizzare Kubernetes non significa automaticamente possedere una infrastruttura indipendente.
Un cluster Kubernetes può essere eseguito sui propri server oppure essere completamente ospitato nell'infrastruttura di un grande fornitore cloud. Il codice aperto della piattaforma non elimina quindi, da solo, i problemi di dipendenza tecnologica.
Offre però qualcosa di fondamentale: uno standard tecnologico aperto e un'implementazione libera che possono essere eseguiti su infrastrutture differenti.
Ed è proprio questa separazione tra software e fornitore a rappresentare una delle caratteristiche più importanti del Software Libero.
Kubernetes 1.37 continua ora a lavorare anche su un'altra separazione: quella tra un componente e privilegi di sistema che non dovrebbe necessariamente possedere.
Essere root è potente, ma proprio per questo la sicurezza moderna dovrebbe partire da una domanda molto semplice: è davvero necessario esserlo?
Con Kubernetes 1.37, sempre più spesso, la risposta può diventare no.