<img height="1" width="1" style="display:none;" alt="" src="https://dc.ads.linkedin.com/collect/?pid=43543&amp;fmt=gif">

IT | EN

6 MIN LETTURA

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.

1) La sicurezza dei POD

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

Containerized Applications

È 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? 

Contattaci

 



Categorie: Security, Kubernetes, Cloud Native, DevSecOps


Valentina Ceoletta

scritto da Valentina Ceoletta

ARTICOLI CORRELATI

21/07/22 Posted by Valentina Ceoletta

A cosa serve il PlatformOps e perché la tua organizzazione ne ha bisogno?

Il mondo dello sviluppo applicativo è radicalmente cambiato negli ultimi anni. Le applicazioni monolitiche sono state sostituite da servizi interconnessi attraverso API.

5 MIN LETTURA

Leggi tutto  

21/07/22 Posted by Valentina Ceoletta

DevSecOps cos’è e quali sono i relativi vantaggi

Abbiamo parlato svariate volte della metodologia DevOps, di cosa sia e di come essa coinvolga i team di sviluppo e quello delle IT Operations.

3 MIN LETTURA

Leggi tutto  

21/07/22 Posted by Valentina Ceoletta

Cloud Security: come gestire la sicurezza delle applicazioni in ambienti cloud native

Provvedere alla sicurezza delle applicazioni in cloud è tanto importante quanto il loro sviluppo, e trascurare questo punto può essere un errore molto costoso. 

5 MIN LETTURA

Leggi tutto  

Iscriviti alla nostra Newsletter