Kubernetes è estremamente popolare, ma senza adeguate misure di sicurezza comporta anche dei rischi. L'esperto di sicurezza CyberArk nomina tre rischi specifici e mostra quali misure difensive sono necessarie per tenere sotto controllo i rischi di hardware, server API e container in Kubernetes.
Nello sviluppo del software oggi, la velocità e l'agilità sono fondamentali. La tecnologia dei container viene utilizzata in misura crescente. Kubernetes è emerso come lo standard de facto per la gestione di carichi di lavoro e servizi containerizzati.
Aspetti di sicurezza di Kubernetes
Dal punto di vista della sicurezza, la piattaforma di orchestrazione Kubernetes porta con sé sfide specifiche relative all'identità che devono essere affrontate all'inizio del processo di sviluppo. In caso contrario, gli ambienti containerizzati possono rappresentare un rischio per la sicurezza IT. Ci sono tre principali aree potenzialmente vulnerabili all'interno di Kubernetes su cui le organizzazioni dovrebbero concentrarsi come parte di un vero approccio DevSecOps.
Rischio Kubernetes: hardware
Sia che si esegua Kubernetes on-premise o in un cloud gestito di terze parti, è comunque necessaria una piattaforma hardware. Una volta che un utente malintenzionato ha accesso alla macchina virtuale che esegue Kubernetes e ottiene i privilegi di root, può anche attaccare i cluster Kubernetes.
Per evitare ciò, esistono le seguenti best practice di sicurezza:
- L'applicazione del principio del privilegio minimo è fondamentale per proteggere l'hardware alla base sia di Kubernetes che dei container stessi. Le macchine virtuali dovrebbero essere distribuite con il livello più basso di privilegi (ovvero solo quelli strettamente necessari per motivi funzionali) per rendere più difficile per gli aggressori ottenere l'accesso root.
- Le credenziali devono essere ruotate regolarmente e l'utilizzo di una soluzione di deposito automatico ha senso per aumentare ulteriormente la protezione senza aumentare il sovraccarico.
Rischio Kubernetes: Kubernetes API Server
Oltre alle macchine fisiche, anche il piano di controllo di Kubernetes deve essere protetto. Fornisce l'accesso a tutti i container in esecuzione in un cluster, incluso il server API Kubernetes, che funge da front-end e facilita l'interazione dell'utente all'interno del cluster.
Un attacco al server API può avere un grande impatto. Anche un singolo segreto o credenziale rubato può essere utilizzato per aumentare i diritti di accesso ei privilegi di un utente malintenzionato. Una vulnerabilità inizialmente piccola può trasformarsi rapidamente in un problema a livello di rete.
Le migliori pratiche di sicurezza includono:
- Per mitigare il rischio, le organizzazioni devono innanzitutto proteggere gli endpoint dal furto di credenziali e dalle minacce malware. I computer locali utilizzati dagli utenti con diritti amministrativi in Kubernetes sono particolarmente rilevanti.
- L'autenticazione a più fattori (MFA) per l'accesso ai server API Kubernetes è essenziale. Ad esempio, una credenziale rubata non può essere utilizzata per l'accesso a Kubernetes.
- Una volta che gli utenti sono stati autenticati in Kubernetes, possono accedere a tutte le risorse all'interno del cluster. La gestione delle autorizzazioni è quindi di fondamentale importanza. Con il controllo degli accessi basato sui ruoli, un'azienda può garantire che gli utenti dispongano solo dei diritti di accesso di cui hanno realmente bisogno.
- Il privilegio minimo dovrebbe essere applicato anche agli account di servizio Kubernetes, che vengono creati automaticamente quando viene configurato un cluster, per aiutare ad autenticare i pod. Altrettanto importante è la rotazione regolare dei segreti per eliminare le opportunità di accesso per coloro che non ne hanno più bisogno.
Rischio Kubernetes: container
I pod e i container sono gli elementi costitutivi di un cluster Kubernetes e contengono le informazioni necessarie per eseguire l'applicazione. Esistono diverse potenziali vulnerabilità all'interno di questo ecosistema di container e flusso di lavoro. Questi includono, ad esempio, l'accesso non protetto all'API del contenitore o all'host del contenitore e registri di immagini non protetti.
Le seguenti best practice sono consigliate per la sicurezza dei container:
- I segreti non devono essere incorporati nel codice o in un'immagine contenitore. Altrimenti, chiunque abbia accesso al codice sorgente ha anche accesso alle informazioni nei repository di codice, ad esempio.
- I rischi per la sicurezza sono significativamente ridotti al minimo con il controllo degli accessi basato sui ruoli, la restrizione dell'accesso segreto ai processi all'interno di un contenitore specifico e l'eliminazione dei segreti non più necessari.
- L'utilizzo segreto, inclusa la rotazione o la disattivazione, deve essere registrato. È inoltre vantaggiosa una soluzione di gestione centralizzata dei segreti che consente l'amministrazione automatica e la protezione dei dati di accesso riservati.
"Adottando queste best practice, un'azienda può migliorare significativamente la sicurezza nell'intero ambiente Kubernetes", ha affermato Michael Kleist, vicepresidente di area DACH di CyberArk. “Inoltre, c'è anche la possibilità di supportare gli sviluppatori con funzioni self-service nel loro lavoro quotidiano, ad esempio per quanto riguarda la scansione del codice. Ciò consente loro di dare un ulteriore contributo all'aumento della sicurezza di Kubernetes in modo rapido e conveniente".
Altro su CyberArk.com
A proposito di CyberArk
CyberArk è il leader globale nella sicurezza delle identità. Con Privileged Access Management come componente principale, CyberArk fornisce una sicurezza completa per qualsiasi identità, umana o non umana, attraverso applicazioni aziendali, ambienti di lavoro distribuiti, carichi di lavoro cloud ibridi e cicli di vita DevOps.