Kubernetes è la piattaforma di orchestrazione più scelta per gestire carichi di lavoro e servizi containerizzati, automatizzare i processi e muoversi più velocemente e in modo scalabile.
A ricordarlo citando uno studio di Red Hat del 2021 è Massimo Carlotti, Presales Team Leader di CyberArk, secondo cui, oggi, la velocità vince su quasi tutto quando si tratta di sviluppo software, e con l’evoluzione dei requisiti del business digitale, agli sviluppatori viene chiesto di lavorare in modo ancora più rapido e agile. Per farlo, questi ultimi si rivolgono sempre più spesso ai container, impacchettando il software con le necessarie dipendenze.
Kubernetes e la sfida della sicurezza
Nonostante la sua popolarità, e forse in parte a causa di essa, la piattaforma di orchestrazione Kubernetes introduce, però, nuove sfide di sicurezza incentrate sull’identità, sfide che devono essere affrontate all’inizio del ciclo di sviluppo, per evitare che anche i piccoli problemi possano crescere rapidamente, causando ritardi e difetti costosi.
Lo stesso studio di Red Hat rivela che quasi tutti gli sviluppatori (94%) hanno sperimentato almeno un incidente di sicurezza legato a Kubernetes negli ultimi 12 mesi, mentre più della metà ha ritardato il deployment delle applicazioni in produzione a causa di problemi di sicurezza.
Negli ambienti dinamici cloud-native, i secret – come password, chiavi SSH, certificati e token API – sono ampiamente utilizzati per garantire l’accesso a chiunque o qualsiasi cosa li conosca. Le organizzazioni diventano vulnerabili quando questi trapelano nei log, vengono esposti nel codice dell’applicazione o gestiti male. Esacerbando il problema, i secret hanno la capacità unica di garantire l’accesso ad altri secret e privilegi, noto come il “problema del secret zero”.
Tre rischi chiave di Kubernetes e misure di mitigazione
Proteggere i secret negli ambienti containerizzati richiede la collaborazione di tutti i team coinvolti nelle attività di sviluppo, gestione e sicurezza. Ecco tre aree potenzialmente vulnerabili all’interno di Kubernetes su cui concentrarsi come parte di un vero approccio DevSecOps:
Rischio #1: hardware
Sia che venga eseguito on-premise o in un cloud gestito da una terza parte, Kubernetes richiede ancora una piattaforma hardware. Se un attaccante può violare la macchina virtuale che esegue Kubernetes e ottenere l’accesso ai privilegi di root, può continuare a violarne il cluster.
Best practice:
- Applicare il principio del minimo privilegio può fare molto per proteggere l’hardware che sta alla base sia di Kubernetes che dei container stessi. Fornire alle macchine virtuali il minor numero di privilegi necessari per operare, al fine di rendere difficile agli attaccanti ottenere l’accesso root.
- Ruotare spesso le credenziali e considerare anche il vaulting per rafforzare ulteriormente le protezioni.
Rischio #2: il server API di Kubernetes
Oltre alle macchine fisiche, è necessario proteggere anche il control plane di Kubernetes che ha accesso a tutti i container in esecuzione in un cluster, compreso il server API di Kubernetes, che agisce come front-end del control plane e facilita l’interazione degli utenti all’interno del cluster.
Un attacco al server API può avere notevoli implicazioni. Anche pochi secret o credenziali rubati possono essere utilizzati per aumentare l’accesso e i privilegi di un attaccante, e quella che all’inizio era una piccola falla può rapidamente trasformarsi in un problema per tutta la rete.
Best practice:
- Per minimizzare il rischio, si raccomanda di iniziare bloccando il furto di credenziali e le minacce malware sull’endpoint – da dove iniziano molti attacchi – facendo molta attenzione alle macchine locali utilizzate dagli utenti con privilegi amministrativi in Kubernetes.
- Utilizzare l’autenticazione a più fattori (MFA) per l’accesso al server API di Kubernetes. In questo modo, anche se una credenziale venisse rubata, non potrebbe essere autenticata o utilizzata per accedere a Kubernetes. I team di sviluppo possono anche impostare il flag experimental-encryption-provider-config sul server API di Kubernetes per rafforzare la protezione dei secret.
- Una volta che un utente è autenticato in Kubernetes, in base al suo profilo autorizzativo, potrebbe accedere a tutte le risorse all’interno del cluster, di conseguenza la gestione dei permessi è fondamentale. Il controllo di accesso basato sui ruoli (RBAC) aiuterà a garantire che gli utenti abbiano solo i diritti di accesso di cui hanno bisogno e non siano eccessivamente autorizzati.
- Allo stesso modo, il minimo privilegio dovrebbe essere applicato agli account di servizio Kubernetes che vengono creati automaticamente quando un cluster viene impostato per aiutare ad autenticare i Pod. I secret dovrebbero anche essere ruotati su base regolare per mantenere l’accesso fuori dalla disponibilità di chi non ne ha bisogno.
Rischio #3: container
I Pod e i container al loro interno sono i mattoni di un cluster Kubernetes e contengono le informazioni necessarie per eseguire l’applicazione. Ci sono diverse aree chiave di vulnerabilità all’interno di questo ecosistema di container e del flusso di lavoro.
Best practice:
- Anche se può sembrare logico, non includere secret nel codice o nell’immagine del container, altrimenti chiunque abbia accesso al codice sorgente avrà anche accesso alle informazioni nei repository del codice, nei log e altrove.
- Evitare di usare variabili d’ambiente per informazioni sensibili. Questo aiuterà a prevenire che gli attaccanti scoprano i segreti in chiaro con semplici comandi se compromettono l’accesso all’API del container.
- Implementare RBAC, limitare l’accesso segreto ai processi in esecuzione all’interno di un determinato container e cancellare i secret/revocare l’accesso alle risorse quando non sono più necessari per minimizzare l’esposizione.
- Registrare l’utilizzo, compreso quando un secret viene iniettato, ruotato o rimosso da un container e controllare regolarmente l’accesso ai sistemi critici. Inoltre, considerare la centralizzazione della gestione dei secret per rendere più gestibile l’audit, il controllo degli accessi e l’amministrazione dei segreti.
Fare in modo che i team di sviluppo applichino queste best practice permette di rafforzare la sicurezza nell’intero ambiente Kubernetes dell’organizzazione, cercando anche modi per integrare capacità self-service nei processi quotidiani degli sviluppatori (ad esempio, la scansione del codice) per semplificare la vita di tutti – e far sì che le cose si muovano rapidamente.
Quando i team di sicurezza e di sviluppo collaborano per aiutare a difendersi dagli attacchi, guidare l’efficienza operativa e soddisfare i requisiti di audit e conformità, è una vittoria per tutti.
