Come mettere in sicurezza un cluster Kubernetes in quattro step

Il report tecnico “Kubernetes Hardening Guide” è stato pubblicato dalla NSA e CISA nell’agosto 2021 e recentemente revisionato nel marzo 2022. Tale guida si propone di aiutare nella messa in sicurezza e configurazione di un cluster Kubernetes. Kubernetes è un orchestratore open source che automatizza la distribuzione, lo scaling e la gestione delle applicazioni eseguite in container e spesso ospitato in un ambiente cloud. Questo tipo di infrastruttura fornisce flessibilità e benefit di sicurezza maggiori dei sistemi tradizionali; tuttavia, l’analisi e la gestione della sicurezza dai microservizi all’infrastruttura sottostante introduce molta complessità.

Dati la densità e il dettaglio delle informazioni riportate nel report, i nostri esperti di sicurezza in Kiratech, il team AKIT, hanno riassunto le best practices in un mini vademecum qui di seguito.

Quattro sono le aree messe sotto i riflettori degli analisti ed esperti di security:

1. La sicurezza dei Pod (l’unità atomica in un cluster Kubernetes)
2. La sicurezza della rete e l’hardening del cluster
3. Gli aspetti legati all’autenticazione e autorizzazione (chi e come può accedere)
4. Il monitoraggio e la rilevazione di minacce

andiamo ad analizzarle insieme.

Un POD è una piccola risorsa all’interno del cluster Kubernetes che consente alle applicazioni o servizi di essere eseguiti. Ogni applicazione viene eseguita sulla base di un’immagine di container che racchiude l’eseguibile dell’applicativo e tutto ciò di cui ha bisogno: codice, strumenti di sistema, librerie di sistema e una porzione di sistema operativo. Come dicevamo, il primo step che permette di garantire la sicurezza di un cluster Kubernetes è la creazione di immagini di container sicure:

• È necessario eseguire delle scansioni per poter rilevare vulnerabilità e mal configurazioni
• Nel caso si utilizzino immagini già create da terzi, è importante che siano scaricate da repository trusted

Una volta ottenuta questa immagine è necessario metterla in esecuzione: come si può osservare nella Figura 1, il sistema operativo su cui girano le applicazioni è quello dell’host che li ospita (on-prem, cloud).

Figura 1

È intuitivo pensare che i pod siano direttamente legati con tale livello dell’architettura. Pertanto è necessario implementare alcune pratiche per ridurre la superficie di attacco in modo che un attaccante malintenzionato non possa ottenere accesso all’host sottostante. L’esecuzione dei pod deve avvenire:

• specificando utenti non root (non amministrativi)
• con il minor numero di possibili privilegi
• senza condividere la rete, i PID dei processi dell’host sottostante
• impostare la sola lettura sul file system
• applicare misure di sicurezza quali SELinux, AppArmor, Seccomp
• non utilizzare l’account di servizio di default, crearne uno specifico se necessario.

La soluzione è l’utilizzo di policy che possano controllare, prima della messa in produzione, se le risorse rispettano le best practices riportate sopra. L’applicazione a livello di risorse è molto semplice, si tratta di flag all’interno del file di definizione: la verifica tramite le policy viene effettuata con il meccanismo di Admission Control. Noi suggeriamo di affiancare a questa configurazione anche l’utilizzo di Open Policy Agent (OPA).

2) La sicurezza della rete e hardening del cluster

La connettività all’interno del cluster Kubernetes è un concetto fondamentale per la corretta esecuzione di qualsiasi azione al suo interno. Di default le impostazioni di rete permettono alle risorse di poter comunicare con tutti pertanto è necessario adottare delle misure che isolino e non permettano i movimenti all’interno del cluster ad un potenziale malintenzionato (escalation in particolar modo). Ci sono alcuni accorgimenti che vengono suggeriti:

• l’utilizzo dei namespace per partizionare lo spazio di lavoro con assegnamento di label per poter applicare regole RBAC o policy di rete: i namespace non sono automaticamente isolati!
• Applicazione di network policy (scegliendo opportunamente un plugin CNI adeguato): creare una regola di deny all in ingresso/uscita dai pod ed eventualmente creare delle eccezioni se necessario
• Utilizzare firewall o altri tool per creare la segmentazione della rete

Successivamente il report riporta una serie di accortezze per rendere sicuro il cluster sempre con un’ottica alla rete:

• Limitazione delle risorse utilizzate dagli oggetti del cluster (consumo di cpu, memoria, …)
• Abilitazione della cifratura TLS nelle comunicazioni tra tutte le componenti (control plane, etcd, api server, worker node, …)

3) Gli aspetti di autenticazione e autorizzazione

L'autenticazione e l'autorizzazione sono i meccanismi principali per limitare l'accesso alle risorse del cluster. Degli attaccanti possono effettuare scansioni sulle porte note di Kubernetes e accedere al database del cluster o effettuare chiamate API senza essere autenticati se il cluster non è configurato correttamente. Diversi meccanismi di autenticazione sono supportati ma non abilitati di default, si suggerisce di abilitarne almeno uno tra: certificati X509, bootstrap token o token OpenID.

Si suggerisce fortemente di abilitare il meccanismo di autenticazione basato su ruoli RBAC. Non abilitato di default, questo metodo permette di rispettare il principio del privilegio minimo: solo un minimo sottoinsieme di privilegi devono essere assegnati all’utente e ogni altra aggiunta deve essere revisionata prima di essere approvata.

Infine è importante disabilitare le autenticazioni anonime che sono di default concesse all’interno di Kubernetes.

4) Il monitoraggio e la rilevazione delle minacce

Ultimo, ma non per questo di minor importanza, l’aspetto della tracciabilità delle attività. Un’efficacie soluzione di logging permette non solo il monitoraggio della dei servizi e delle configurazioni ma anche la sicurezza del cluster. Anche questa configurazione non è abilitata di default, pertanto è fortemente consigliata. Sono molti i livelli in cui è possibile agire:

• Le richieste dell’API server: in questo caso è sufficiente abilitare il meccanismo di logging nativo Kubernetes
• Per i log del worker node/container è consigliato creare un DaemonSet in modo che mantenga consistente una copia di tutti i file che vengono creati (il kubelet automaticamente è di default abilitato alla gestione dei log); se si desidera uniformarli e concentrarli in un unico posto allora è consigliato abilitare l’inoltro via syslog
• Nel caso si sia interessati alle system call, allora si consiglia utilizzare la modalità audit di Seccomp
• L’analisi dei flussi di log è necessaria se si vuole creare un meccanismo di alerting, per questo si consiglia di inoltrare tutte le informazioni raccolte in un SIEM. Qui sarà possibile creare regole di correlazione e automatizzare certi flussi.

Per quanto riguarda il monitoraggio, Kubernetes non supporta nativamente questo aspetto ma sono numerosi gli strumenti compatibili che vengono in aiuto: per esempio Prometheus, Grafana e Elasticsearch.

La sicurezza è un processo continuo e le pratiche riassunte fin qui sono solo un passo verso la messa in sicurezza del cluster Kubernetes, che prevede di base l’aggiornamento costante di tutti i sistemi.

Non importa quali siano le componenti di un cluster, ciò che conta è che ogni pezzo del sistema complessivo rimanga il più sicuro possibile: gli applicativi, Kubernetes stesso, hypervisor, plugin, sistemi operativi, elementi della pipeline CI/CD.

Come abbiamo visto la sicurezza non è un elemento intrinseco di Kubernetes, per questo motivo, secondo il nostro punto di vista, è necessario configurarlo al meglio.

Vuoi approfondire questo tema e ricevere ulteriori consigli per la messa in sicurezza e la configurazione ottimale di un cluster Kubernetes?