Kubernetes v1.22: “Reaching New Peaks”

Recentemente è stata rilasciata la versione v1.22 di Kubernetes, la seconda release dell’anno, rappresentando un traguardo molto importante.

Parlando di numeri, in questa versione sono stati introdotti ben 53 nuovi miglioramenti: 13 dei quali sono passati in “stable”, 24 in “beta” e 16 in “alfa”. Inoltre 3 funzionalità sono state completamente sostituite.

Anche in questa versione, possiamo apprezzare un numero di modifiche sempre maggiore, questo è dovuto dai recenti cambiamenti di life-cycle di kubernetes introdotti ad aprile dove le release passano da quattro all’anno a tre.

Temi Principali

In questa versione sono stati introdotti numerosi cambiamenti, alcuni davvero molto significativi:

• Sostituzione dei Pod Security Policy (aka PSPs)
• Rootless mode per l’esecuzione dei container
• Supporto dello swap sul nodo
• Introduzione dei Cgroupsv2
• QoS per la memoria
• Etcd aggiornato alla versione 3.5.0
• Seccomp di default
• Rimozione di vecchie API in Beta

Sostituzione delle Pod Security Policy (aka PSPs)

Dopo averle deprecate in Kubernetes v1.21, eravamo già a conoscenza che ci sarebbe stata l’implementazione di una nuova funzionalità che avrebbe sostituito quella delle Pod Security Policy. Ciò che però non sapevamo ancora era con cosa sarebbero state sostituite. Finalmente ora sappiamo che si tratterà di un Admission Controller, il quale riutilizzerà una parte delle funzionalità pregresse.

Il nuovo “PodSecurity Admission Controller” per ora è una funzionalità in alfa ma è già possibile utilizzarlo per rimpiazzare le Pod Security Policies. Questo sarà in grado di impostare degli standard di sicurezza del Pod suddivisi per namespace.

Tale impostazione potrà essere fatta su tre livelli differenti:

• enforce: la violazione della Policy causerà il rigetto del Pod
• audit: La violazione della Policy causerà l’aggiunta di una annotation di controllo, ma l’esecuzione del Pod rimarrà consentita
• warn: La violazione della Policy causerà un warning del kubectl e l’esecuzione del pod rimarrà invariata.

Sarà quindi possibile impostare la configurazione dichiarando un AdmissionConfiguration, come ad esempio il seguente:

Rootless mode per l’esecuzione dei container

Non eseguire i container con privilegi amministrativi è forse una delle regole basilari più importanti in termini di sicurezza che si possa pensare.

In questa nuova versione di Kubernetes questo concetto viene riportato su tutto lo stack, permettendo quindi di eseguire Kubernetes tramite un’utenza standard e non più amministrativa. Questo è un grande passo in avanti per rendere la piattaforma più sicura su tutta la linea. In questo modo, se il cluster è compromesso, per gli attaccanti sarà più difficile accedere al resto dell’infrastruttura.

Per eseguire Kubernetes in rootless mode è sufficiente abilitare la funzionalità KubeletInUserNamespace.

Supporto dello swap sul nodo

Sebbene sia una piccola modifica, è uno di quei dettagli che renderà agli sviluppatori la vita molto più semplice. Grazie a questa miglioria ora è possibile utilizzare lo swap anche sui processi Kubernetes. Poiché questa funzionalità per ora è in alfa è possibile abilitarlo solo a livello globale su tutto il nodo e non può essere configurato per singolo processo.

Per utilizzarlo sarà sufficiente:

1. abilitare l’uso dello swap sul worker node
2. abilitare il flag NodeMemorySwap
3. impostare l’opzione –fail-on-swap
4. (opzionale) è possibile abilitare anche il setting SwapBehavior=UnlimitedSwap per permettere ad i processi Kubernetes di usufruire dello swap.

Introduzione dei Cgroupsv2

Come con lo swap, è bello vedere il supporto di funzionalità native di Linux. In questo caso, Cgroupsv2, permetterà un piu efficace Memory QoS (Quality of Service), che aiuterà ad evitare la degradazione delle prestazioni dei processi.

Cgroups è una funzionalità del kernel Linux che limita, verifica e isola l’utilizzo delle risorse come CPU, memoria, I/O del disco, rete, ecc…, per un insieme di processi. La sua API v2 è stata dichiarata stabile più di due anni fa e molte distribuzioni Linux la stanno già utilizzando di default. Quindi è importante vedere Kubernetes finalmente compatibile con Cgroupsv2, anche se per ora questa funzionalità è in alfa e siamo in trepidante attesa di come verrà implementata la sua versione finale.

QoS sulla memoria con cgroupsv2

Ora che Cgroupsv2 è supportato, è iniziato il supporto per le sue nuove funzionalità.

Infatti, è ora possibile configurare Memory QoS con le seguenti opzioni:

• min: quantità minima di memoria che il cgroup deve sempre conservare.
• max: il limite massimo di utilizzo della memoria, che funge da meccanismo di protezione.
• low: la protezione della memoria in best-effort, una “garanzia” che se il cgroup e tutti i suoi processi sottostanti siano al di sotto di questa soglia, la memoria del cgroup non verrà assegnata a meno che la memoria non possa essere recuperata da dei cgroup non protetti.
• high: se l’utilizzo della memoria di un cgroup supera il limite specificato qui, i processi del cgroup andranno in throttling e in forte reclaim pressure.

Etcd si aggiorna alla versione 3.5.0

Il DB predefinito di Kubernetes, etcd, ha una nuova versione: 3.5.0. La nuova versione include miglioramenti di sicurezza, migliori prestazioni, miglior monitoraggio e una migliorata “developer experience”. Ci sono numerosi bug fix e alcune nuove funzionalità come la migrazione ad una gestione più strutturata dei log e l’implementazione della log rotation. Questa versione include inoltre, una roadmap dettagliata per implementare una soluzione al sovraccarico del traffico.

Seccomp come default

Una cosa è chiara, questa nuova versione di Kubernetes sta andando (finalmente n.d.r.) verso un nuovo approccio di tipo security first. L’aggiunta di questo ulteriore livello di sicurezza come default renderà inutili molti potenziali exploit. Passi come questo, in questa direzione, cambieranno il modo in cui tutti vedremo Kubernetes.

Kubernetes attualmente aumenta la sicurezza dei container, eseguendoli utilizzando un profilo Seccomp (SECure COMPuting mode).

Questo miglioramento abiliterà questa opzione di default, aiutando a prevenire CVE e vulnerabilità zero-day. È possibile abilitare questo comportamento impostando SeccompDefault invece dell’attuale profilo RuntimeDefault, per qualsiasi container rendendo quindi tutto più sicuro e protetto.