Scritto da: Yu Pengfei , Mah Chia Hui

introduzione

La crescita esplosiva dell'utilizzo di Kubernetes nell'ultimo decennio è stata uno spettacolo enorme. Tuttavia, Roma non è stata costruita in un giorno e, proprio come ogni altro importante stack tecnologico in uso oggi, ci sono voluti diversi decenni perché la tecnologia di containerizzazione maturasse prima che Kubernetes si presentasse come la migliore articolazione nella sua fase attuale.

Man mano che più applicazioni vengono containerizzate, i motori di orchestrazione come Kubernetes sono diventati estremamente popolari. Come motore di orchestrazione, Kubernetes aiuta a gestire, ridimensionare e distribuire applicazioni containerizzate. Detto questo, ci sono tantissimi motori di orchestrazione diversi (come Docker Swarm), quindi perché Kubernetes rimane così popolare? Una risposta rapida risiede nel fatto che Kubernetes è ricco di funzionalità, ricco di funzionalità come l'auto-riparazione e il ridimensionamento automatico. Inoltre, Kubernetes è implementato come servizio gestito dalla maggior parte dei provider di servizi cloud (CSP). Ciò consolida la sua posizione di "Gold standard" per i motori di orchestrazione. L'adozione di Kubernetes è ancora in crescita, con il 96% delle organizzazioni che utilizza o valuta Kubernetes. (https://thenewstack.io/is-kubernetes-adoption-slowing/)

Mo' Tesoro Mo' Problemi

Con l'uso diffuso di Kubernetes, non sorprende che sia anche una preziosa superficie di attacco che gli aggressori stanno attivamente cercando di fiutare e sfruttare. Con la sua nuova ascesa, gli sviluppatori commettono anche errori nella sua implementazione, configurazione o distribuzione.

Questo articolo è il primo della nostra serie sulla sicurezza di Kubernetes. Fornirà una panoramica di alcuni attacchi comuni e best practice di sicurezza di base per Kubernetes. Gli articoli successivi approfondiranno gli attacchi più complessi, come il montaggio di HostPath, i pod/nodi del trampolino, ecc. e le relative soluzioni.

Per comprendere gli attacchi, dobbiamo prima capire l'architettura Kubernetes, il diagramma di alto livello qui sotto è un buon punto di partenza. Sentiti libero di saltare a "Metodologia di attacco" se hai già familiarità con l'architettura Kubernetes e i suoi fondamenti.

Diagramma dell'architettura di Kubernetes

Baccelli

Kubernetes comprende molte parti mobili e la sua unità di lavoro più bassa è nota come POD . Un pod può ospitare più contenitori e volumi di archiviazione diversi. Ogni pod ha anche il suo indirizzo IP univoco. È anche estremamente scalabile in quanto si basa su progetti di distribuzione (file yaml).

Nodi

Per semplificare le cose per tutti, suddivideremo semplicemente il tipo di nodi in:

● Nodi di lavoro

● Nodo principale

Un insieme di nodi forma un cluster.

Nodi di lavoro:

I pod risiedono su questi nodi di lavoro che possono essere macchine virtuali o fisiche. Puoi pensarli come macchine host per i pod.

Nodo principale:

Un Master Node è l'amministratore finale dell'intero cluster. Controlla e gestisce tutti i nodi di lavoro, che includono i seguenti componenti: Kube-API server, Kube-Controller-Manager, Kube Scheduler, ecc.

Spazio dei nomi

Uno spazio dei nomi Kubernetes è un meccanismo di isolamento che isola le risorse all'interno di un cluster, generalmente utilizzato quando diversi team lavorano sullo stesso cluster. Nel contesto della sicurezza informatica, ogni oggetto/risorsa dello spazio dei nomi è unico per lo spazio dei nomi. L'invocazione di oggetto/risorsa tra spazi dei nomi è impossibile poiché questi oggetti/risorse sono isolati all'interno dei loro spazi dei nomi.

Ora, con tutte queste nuove conoscenze, dovresti avere una comprensione fondamentale dell'ambiente Kubernetes. Passiamo al lato più succoso delle cose, come si attacca Kubernetes?

Metodologia di attacco

La metodologia di un aggressore sofisticato può essere suddivisa in tre fasi.

Fase 1: Punto d'appoggio iniziale

Il modo principale per ottenere un punto d'appoggio iniziale è compromettere un'applicazione Web o un microservizio ospitato nel cluster. L'obiettivo dell'aggressore è ottenere l'esecuzione di codice in modalità remota sull'applicazione enumerando l'applicazione e identificando le vulnerabilità sfruttabili (ad es. log4shell, apache struts).

Fase 2: escalation dei privilegi

Dopo aver preso piede nel cluster Kubernetes, un utente malintenzionato si troverebbe all'interno di un pod, che, come spiegato, è semplicemente un contenitore docker. Un utente malintenzionato potrebbe annusare il contenitore per i dati sensibili, ma è limitato a ciò che è disponibile. . Pertanto, l'attaccante cercherà di passare a un pod con più privilegi o a un nodo.

Di seguito sono riportate alcune tecniche comuni che un utente malintenzionato impiegherebbe:

• File sensibili

Bonifica:

Oltre alla pratica standard di non lasciare credenziali sensibili non crittografate in un pod, un amministratore Kubernetes deve aderire ai principi del privilegio minimo quando fornisce privilegi al token dell'account di servizio.

• Applicazioni raggiungibili

Bonifica:

Per gestire quali pod, spazi dei nomi o persino server esterni possono raggiungere una particolare risorsa Kubernetes, un amministratore Kubernetes può utilizzare la risorsa dei criteri di rete Kubernetes .

• Servizi di metadati cloud

Bonifica:

L'amministratore di Kubernetes può utilizzare la suddetta risorsa dei criteri di rete di Kubernetes per impedire a un utente malintenzionato di raggiungere l'API dei metadati del cloud e altre applicazioni ospitate all'interno del cluster non necessarie per le funzioni aziendali principali.

• Scoppio del baccello

Bonifica:

L'amministratore Kubernetes può utilizzare la risorsa del controller di ammissione, una risorsa Kubernetes che convalida ogni risorsa creata nel cluster Kubernetes da un set di regole definito. Una risorsa che non è conforme al set di regole definito non verrebbe creata, generando un errore.

Fase 3: ottenere i gioielli della corona

Nell'ecosistema Kubernetes, i gioielli della corona fanno riferimento al nodo principale. Un utente malintenzionato che ha ottenuto l'accesso completo al nodo master avrebbe essenzialmente il controllo completo del cluster Kubernetes. L'attaccante ripeterebbe le tecniche dettagliate nelle fasi 1 e 2, per spostarsi lateralmente da un pod infetto al nodo sottostante e infine al nodo principale. Per evitare che si verifichi questo scenario peggiore, un amministratore Kubernetes deve assicurarsi che il cluster sia configurato in modo sicuro con alcune delle correzioni menzionate sopra.

È tutto?

Per una visione più completa del livello di sicurezza Kubernetes della tua organizzazione, ti consigliamo di utilizzare la matrice di attacco Kubernetes di Microsoft. La matrice comprende le principali tattiche rilevanti per la sicurezza di Kubernetes. Ognuno di essi contiene diverse tecniche che gli aggressori possono utilizzare per raggiungere obiettivi diversi.

Conclusione

Man mano che sempre più organizzazioni adottano Kubernetes come strumento de facto per la gestione dell'orchestrazione dei container, dati più sensibili finiranno nei cluster Kubernetes. C'è una necessità ancora maggiore per gli amministratori di sistema che cercano di impostare il proprio cluster per farlo configurare in modo sicuro. Un utente malintenzionato con accesso completo al nodo master di un cluster Kubernetes è l'ultima cosa che un CISO vorrebbe vedere.

Fai attenzione ai nostri prossimi articoli, in cui condivideremo attacchi più approfonditi e specifici che comunemente vediamo oggi sul campo.

Abbi cura di te e prenditi sul FLIPPETY-FLIP.