Perché Kubernetes comporta rischi diversi?
Kubernetes è potente perché automatizza la distribuzione, il dimensionamento e l'orchestrazione, ma questo stesso piano di controllo aumenta anche il numero di ambiti in cui un errore può avere conseguenze di vasta portata. Una progettazione RBAC inadeguata può concedere un accesso eccessivo all'infrastruttura sottostante, incluse risorse sensibili e, in alcuni casi, il controllo amministrativo. Una configurazione permissiva del controllo di ammissione può consentire l'introduzione di carichi di lavoro rischiosi nell'ambiente di produzione. Un criterio di rete eccessivamente permissivo può facilitare i movimenti laterali.
Kubernetes modifica anche il modello operativo. Si trovano a proteggere infrastrutture basate su API, carichi di lavoro effimeri, componenti aggiuntivi dei cluster, account di servizio, immagini dei contenitori e manifesti di distribuzione che possono cambiare continuamente.
Quali sono i principali rischi per la sicurezza di Kubernetes?
Configurazioni non sicure dei carichi di lavoro: impostazioni di sicurezza dei pod poco rigorose, contenitori con privilegi, capability eccessivamente ampie, file system radice scrivibili o impostazioni predefinite non sicure nei manifesti possono esporre inutilmente il cluster. In molti casi, è qui che il rischio inizia a concretizzarsi sul piano operativo.
- Autorizzazioni eccessive ed errori RBAC: se utenti, account di servizio o carichi di lavoro dispongono di più privilegi del necessario, aumenta l'entità dei potenziali danni. Una progettazione inadeguata degli accessi può facilitare l'escalation dei privilegi e rendere più difficile il ripristino.
- Vulnerabilità della catena di approvvigionamento: le immagini dei contenitori possono includere vulnerabilità note, segreti esposti, dipendenze non attendibili o componenti manomessi. La scansione delle immagini è utile, ma sono importanti anche la provenienza, l'applicazione delle patch e la corretta gestione delle immagini.
- Applicazione inadeguata dei criteri: se il cluster non convalida ciò che può essere distribuito, le configurazioni rischiose possono passare direttamente all'ambiente di esecuzione. I controlli basati sui criteri sono utili solo se vengono applicati in modo coerente.
- Rete piatta o segmentazione inadeguata: la rete Kubernetes può rendere efficienti gli spostamenti est-ovest sia per le applicazioni sia per gli autori degli attacchi, se i confini sono troppo labili. Una segmentazione inadeguata rende più difficile il contenimento quando si verifica un problema.
- Registrazione e monitoraggio inadeguati: se i team non raccolgono e analizzano i log pertinenti, gli autori degli attacchi possono agire con minori probabilità di rilevamento e gli investigatori dispongono di meno prove per le indagini successive.
Come si manifestano questi rischi negli ambienti reali?
In pratica, il rischio legato a Kubernetes raramente si manifesta sotto forma di un unico fallimento eclatante. Di solito si manifesta come un accumulo di vulnerabilità minori e risolvibili: immagini non sottoposte a scansione, autorizzazioni eccessivamente ampie per gli account di servizio, criteri dei namespace incoerenti, responsabilità dei cluster poco chiare, controlli di ammissione poco rigorosi o un monitoraggio che si limita al nodo anziché estendersi al carico di lavoro.
È per questo che la sicurezza di Kubernetes è difficile da gestire sul piano operativo. I team devono proteggere la piattaforma e il modello di distribuzione ad essa associato. Lo sviluppo, l'ingegneria delle piattaforme, la gestione operativa del cloud e la sicurezza influiscono tutti sul risultato finale.
Perché questi rischi persistono?
Persistono perché Kubernetes offre ai team un'enorme flessibilità, che comporta sempre un costo in termini di sicurezza se le misure di protezione sono insufficienti. I team possono operare rapidamente, eseguire distribuzioni frequenti e supportare applicazioni distribuite complesse, ma il modello di controllo diventa più difficile da gestire se gli standard non sono coerenti tra i diversi cluster o team.
Un altro motivo è la frammentazione delle responsabilità. La funzione di sicurezza può essere responsabile delle linee guida sui criteri, i team di piattaforma delle operazioni dei cluster e i team di ingegneria dei manifesti e dei flussi di lavoro di distribuzione. Ma se questi gruppi non sono allineati, il risultato è in genere un cluster tecnicamente funzionale, ma disomogeneo sul piano operativo in termini di sicurezza.
A cosa dovrebbero prestare maggiore attenzione i team?
Le principali aree su cui concentrarsi sono generalmente il controllo degli accessi, i criteri di distribuzione, la configurazione dei carichi di lavoro e la visibilità. In altre parole, i team devono concentrarsi innanzitutto su chi può fare cosa, su cosa è autorizzato a essere eseguito, su quanto è sicura la configurazione dei carichi di lavoro e sulla disponibilità di elementi sufficienti per rilevare e analizzare eventuali comportamenti sospetti.
Questo aspetto è importante perché raramente la sicurezza di Kubernetes migliora semplicemente aggiungendo un'altra dashboard. Migliora quando l'organizzazione rende più rigorose le decisioni che regolano la distribuzione, l'accesso e il comportamento in fase di esecuzione.
Quali errori commettono le organizzazioni in materia di sicurezza di Kubernetes?
Un errore consiste nel concentrarsi troppo sul contenitore e non abbastanza sul cluster. Le immagini dei contenitori sono importanti, ma la sicurezza di Kubernetes dipende anche dal controllo delle ammissioni, da RBAC, dalla progettazione degli account di servizio, dai criteri di rete e dalla configurazione dei carichi di lavoro.
Un altro errore consiste nel presumere che le impostazioni predefinite siano sufficientemente solide per gli ambienti di produzione. Kubernetes offre controlli di sicurezza avanzati, ma molti di essi richiedono una progettazione e una manutenzione mirate.
Un terzo errore consiste nel separare eccessivamente la sicurezza dal processo di distribuzione. Se i controlli di sicurezza vengono eseguiti solo alla fine, le configurazioni errate e le immagini rischiose vengono rilevate troppo tardi, quando la correzione è più problematica e ha meno probabilità di essere accolta favorevolmente dai team di ingegneria.
Punto chiave
I rischi per la sicurezza di Kubernetes sono dovuti principalmente a carenze dei controlli su larga scala: accessi eccessivi, criteri insufficienti, impostazioni poco sicure dei carichi di lavoro, segmentazione inadeguata e visibilità limitata. I cluster più sicuri non sono quelli dotati del maggior numero di strumenti, bensì quelli con misure di protezione ben definite, applicate già prima della distribuzione e mantenute durante l'esecuzione.
Rafforza la sicurezza di Kubernetes con Kaspersky
I rischi per la sicurezza di Kubernetes spesso derivano da configurazioni errate, accessi eccessivi, un'applicazione poco rigorosa dei criteri e una visibilità limitata nei vari cluster. Kaspersky Container Security aiuta a proteggere gli ambienti di orchestrazione tramite controlli della configurazione, monitoraggio dell'autenticazione e dell'autorizzazione, controllo dei processi e della rete e visibilità sulle risorse dei cluster.
Fonti e approfondimenti:
