Le 10 principali scoperte su Kubernetes del nostro team di pentesting

I nostri 10 principali problemi di Kubernetes (e come risolverli)

Kubernetes: la piattaforma gigante che ogni eroe IT ama! Abbracciare Kubernetes è facile, grazie all'incredibile flessibilità e scalabilità che offre alle applicazioni moderne. Kubernetes è intenzionalmente aperto per design, dando agli utenti un grande controllo.

Tuttavia, questa apertura significa anche che gli utenti hanno una responsabilità significativa nella gestione e nella configurazione efficace. Come dice il famoso detto: 'Da un grande potere derivano grandi responsabilità'.

Siamo onesti, Kubernetes ha molti vantaggi, ma può anche essere complesso. Ha molti componenti e funzionalità, quindi non c'è da stupirsi che possano sorgere vulnerabilità di sicurezza se non viene gestito correttamente. Ad esempio: API esposte, diritti di accesso maldestri e altri problemi di sicurezza.

In Bureau Veritas Cybersecurity ci occupiamo molto di valutazioni della sicurezza di Crystal Box Kubernetes. Siamo più che felici di condividere le nostre intuizioni. Ecco perché abbiamo stilato una 'Top 10' dei risultati più comuni che incontriamo durante le nostre valutazioni di sicurezza Kubernetes. E naturalmente non la lasciamo in sospeso: condividiamo anche come risolvere questi problemi...

1. Accesso alla rete senza restrizioni per impostazione predefinita

Questa constatazione evidenzia che per impostazione predefinita le risorse come i pod e i servizi all'interno di uno spazio dei nomi possono comunicare tra loro senza alcuna regola o restrizione di rete aggiuntiva.

Immagini il seguente scenario: Ha configurato un cluster Kubernetes per la distribuzione delle sue applicazioni. Nel suo stato predefinito, ogni volta che un nuovo pod viene distribuito all'interno di un namespace nel cluster, può connettersi a tutti gli altri pod all'interno dello stesso namespace, nonché a servizi esterni, come un database ospitato da un cloud provider, senza alcuna restrizione iniziale.

Gli aggressori possono approfittare di questa connettività illimitata. Se ottengono l'accesso a un pod, possono ottenere un accesso illimitato a tutti gli altri pod nello stesso spazio dei nomi, il che potrebbe potenzialmente esporre informazioni sensibili. Di conseguenza, gli aggressori potrebbero svolgere diverse attività dannose, come rubare dati sensibili, manomettere l'applicazione alterandone il codice o il comportamento, iniettare codice dannoso o persino interrompere i servizi.

Per mitigare questo rischio, imposti delle regole di ingresso e di uscita per tutti i pod all'interno di uno spazio dei nomi, assicurando che solo pod specifici possano comunicare tra loro.

2. I file system dei container non sono immutabili.

Ciò significa che i container hanno accesso in scrittura al file system. Ciò potrebbe consentire a un aggressore di modificare i file di configurazione essenziali o di installare un software dannoso.

Immaginiamo che la sua applicazione sia distribuita su un cluster Kubernetes e gestisca informazioni altamente sensibili sui clienti. In questo scenario, un aggressore identifica una vulnerabilità nell'applicazione che gli garantisce un accesso non autorizzato al container, consentendogli di scrivere sul file system. Con questo accesso, l'aggressore potrebbe eseguire script dannosi per rubare dati personali o addirittura modificare le configurazioni dell'applicazione per esporre informazioni sensibili.

Per ridurre questo rischio, è possibile rendere immutabili i file system dei container. Quando un container richiede realmente l'accesso in scrittura al file system, può utilizzare i montaggi per abilitare aree specifiche alla scrittura, mantenendo la maggior parte del file system in sola lettura.

3. Namespace vuoti

Questo risultato indica che nel cluster ci sono spazi dei nomi che non contengono risorse.

In uno spazio dei nomi vuoto, senza pod o servizi attivi che generano traffico, qualsiasi traffico generato, ad esempio da attività dannose, può passare inosservato agli amministratori, rendendo difficile il rilevamento di azioni sospette. Ciò offre agli aggressori maggiori opportunità di nascondere le azioni dannose e di portare a termine attacchi efficaci. Inoltre, si crea un inutile disordine e si aggiunge all'onere amministrativo della manutenzione del cluster.

Per migliorare la sicurezza e la gestibilità del cluster, è buona norma identificare e rimuovere gli spazi dei nomi inutilizzati.

4. Risorse Kubernetes senza limiti di CPU e memoria

In questo caso, alcuni pod e container non hanno limiti di utilizzo della CPU e della memoria.

Senza impostare limiti di CPU e memoria, un aggressore può potenzialmente sovraccaricare i server elaborando e inviando grandi volumi di dati. Questo può portare alla congestione della rete, consumando la larghezza di banda del cluster e sovraccaricando i nodi che ospitano i pod dell'attaccante. Tali attacchi potrebbero provocare un denial-of-service, causando una potenziale perdita di fatturato per l'azienda. Inoltre, se i servizi sono configurati per autoscalarsi sotto carico, ciò può portare a costi elevati inaspettati.

Per mantenere la stabilità del cluster, è importante impostare limiti di risorse dei pod per prevenire questi attacchi e garantire un'allocazione efficiente delle risorse.

5. La Politica di sicurezza dei pod non limita le distribuzioni

Nel cluster, non ci sono restrizioni sulle misure di sicurezza per la distribuzione dei pod.

Nello scenario in cui la Pod Security Policy (PSP) è configurata in modo improprio in un cluster, si espongono vulnerabilità nei container dell'applicazione. Questa mancanza di restrizioni consente ai container di operare in modalità privilegiata, con capacità extra come NET_ADMIN e mount dell'host.

In effetti, concede a chiunque gestisca il cluster l'autorità di assegnare queste capacità senza un livello di sicurezza fondamentale, portando potenzialmente ad assegnazioni di capacità casuali per rendere funzionali le distribuzioni, senza considerare le implicazioni per la sicurezza.

Inoltre, queste capacità non controllate possono provocare la fuga di un container, consentendo a un aggressore di ottenere un accesso non autorizzato alle risorse del cluster e di eseguire azioni dannose. In assenza di un PSP che limiti le loro azioni, gli aggressori hanno una libertà illimitata di portare a termine le loro intenzioni malevole.

Per mitigare questo rischio di sicurezza, è importante stabilire e applicare adeguate Politiche di sicurezza Pod. Questa misura proattiva aiuta a salvaguardare il cluster Kubernetes e a prevenire potenziali attacchi limitando le azioni e le capacità dei container.

6. Uscita senza restrizioni dai cluster Kubernetes

Il traffico in uscita dai pod nel cluster non è limitato.

In un cluster con un'uscita senza restrizioni, i pod possono comunicare liberamente con risorse esterne e persino con altri pod, con il rischio di configurazioni errate in cui servizi che non dovrebbero avere accesso a Internet sono connessi al mondo esterno.

Può mitigare questo rischio di sicurezza imponendo restrizioni sulle risorse esterne a cui i pod possono accedere. Questo si può ottenere implementando configurazioni di uscita e regole di politica di rete, controllando e limitando in modo efficace la comunicazione del pod con le risorse esterne.

7. Utenti amministratori di cluster senza PIM

Questo risultato è specifico di Microsoft Azure, dove alcuni utenti possiedono un accesso illimitato e permanente al ruolo di amministratore di cluster nel cluster Kubernetes, senza meccanismi di controllo come il Privileged Identity Management (PIM).

Senza PIM, gli utenti potrebbero avere un accesso permanente al ruolo di amministratore del cluster, mentre PIM fornirebbe solo un accesso temporaneo. Nel caso in cui un aggressore ottenga l'accesso alle credenziali di accesso dell'amministratore, ad esempio attraverso un attacco di phishing, potrebbe sfruttare questo accesso per ottenere il pieno controllo amministrativo del cluster Kubernetes. Ciò include l'accesso alla dashboard di gestione e la possibilità di controllare tutti i pod, i servizi e le configurazioni.

Negli ambienti cloud, l'impiego del PIM è consigliabile per gestire e monitorare gli accessi privilegiati, riducendo così i rischi per la sicurezza grazie all'applicazione delle autorizzazioni just-in-time.

8. Container obsoleti

Si tratta di un problema di sicurezza in Kubernetes, dove un container nel cluster non utilizza la versione più recente di un'immagine.

Questa situazione può portare a una vulnerabilità, poiché alcuni container possono eseguire software obsoleti o mancare di patch di sicurezza essenziali. Gli aggressori possono potenzialmente sfruttare le vulnerabilità note e le debolezze di sicurezza in questi container obsoleti per aggirare la sicurezza dei container e ottenere l'accesso al cluster.

Per ridurre questo rischio, è essenziale aggiornare regolarmente i container alle loro ultime versioni, assicurandosi che abbiano le correzioni e i miglioramenti di sicurezza più recenti.

9. API Kubernetes accessibile da internet

Il server Kubernetes API è esposto a Internet senza che siano state adottate misure di sicurezza adeguate.

Un aggressore può cercare attivamente indirizzi IP pubblici con porte aperte per l'API Kubernetes. Se trova un'API vulnerabile senza alcuna restrizione, l'aggressore può accedervi senza bisogno di credenziali o verifiche.

Con un accesso non autorizzato all'API Kubernetes, l'aggressore può tentare di distribuire un pod dannoso all'interno del cluster, ottenendo potenzialmente l'accesso ad altri pod, come un database con i dati dei clienti. Ciò potrebbe comportare il furto di dati, la compromissione di informazioni finanziarie o addirittura il controllo completo del cluster, con conseguente perdita di profitti.

Anche quando vengono imposte delle restrizioni, il rischio rimane, in quanto gli aggressori possono ancora cercare delle vulnerabilità per accedere al cluster.

Per affrontare questo problema di sicurezza, è fondamentale limitare l'accesso al server API.

10. Il registro è accessibile da tutte le reti

Il registro dei container nel cluster Kubernetes è accessibile da tutte le reti senza alcuna restrizione.

In questo scenario, il cluster Kubernetes si affida ai container di un registro container esterno aperto a tutte le reti senza limitazioni. Ciò rappresenta un rischio per la sicurezza, in quanto gli aggressori potrebbero iniettare codice dannoso in un'immagine, creare un'immagine personalizzata con questo codice e caricarla nel registro.

Una volta che l'immagine dannosa è nel registro, gli aggressori possono utilizzarla per distribuire un pod dannoso all'interno del cluster, con l'obiettivo di rubare dati sensibili o eseguire altre azioni dannose.

Per evitare questo, limiti l'accesso al registro dei container. Implementare le liste di controllo degli accessi (ACL) e applicare i meccanismi di autenticazione e autorizzazione, limitando l'accesso agli utenti autorizzati e riducendo il rischio di iniezione di codice non autorizzato.

Come possiamo aiutarla?

Ecco, questi sono 10 risultati che vediamo spesso nel nostro lavoro. Naturalmente, abbiamo molti altri potenziali risultati nel nostro arsenale, che controlliamo durante le nostre valutazioni di sicurezza. Insieme, possiamo lavorare per rafforzare la sicurezza delle sue applicazioni e dei suoi sistemi, rafforzando ulteriormente lo status di eroe IT!

Rimanga sintonizzato per altri articoli su Kubernetes e se ha delle domande, non esiti a contattarci. Siamo felici di aiutarla!