
Caccia alle debolezze di sicurezza nei cluster Kubernetes
kube-hunter non è più in sviluppo attivo. Se sei interessato a scansionare cluster Kubernetes per vulnerabilità note, ti consigliamo di utilizzare Trivy. In particolare, la scansione di configurazioni errate di Kubernetes e la scansione delle vulnerabilità KBOM di Trivy. Scopri di più nella Documentazione di Trivy.
kube-hunter caccia punti deboli di sicurezza nei cluster Kubernetes. Lo strumento è stato sviluppato per aumentare la consapevolezza e la visibilità dei problemi di sicurezza negli ambienti Kubernetes. Non dovresti eseguire kube-hunter su un cluster Kubernetes che non possiedi!
Esegui kube-hunter: kube-hunter è disponibile come container (aquasec/kube-hunter) e offriamo anche un sito web a kube-hunter.aquasec.com dove puoi registrarti online per ricevere un token che ti permette di visualizzare e condividere i risultati online. Puoi anche eseguire il codice Python da solo come descritto di seguito.
Esplora vulnerabilità: La knowledge base di kube-hunter include articoli su vulnerabilità e problemi rilevabili. Quando kube-hunter segnala un problema, mostra il suo VID (ID di vulnerabilità) in modo da poterlo cercare nella KB all'indirizzo https://aquasecurity.github.io/kube-hunter/
Se sei interessato all'integrazione di kube-hunter con la matrice ATT&CK di Kubernetes Continua a leggere
kube-hunter ora supporta il nuovo formato della matrice ATT&CK di Kubernetes. Mentre le vulnerabilità di kube-hunter sono una raccolta di tecniche creative progettate per imitare un attaccante nel cluster (o all'esterno) La ATT&CK di Mitre definisce categorie più generali e standardizzate di tecniche per farlo.
Puoi pensare alle vulnerabilità di kube-hunter come piccoli passi per un attaccante, che seguono il percorso di una tecnica più generale che lui mirerebbe a raggiungere. La maggior parte dei cacciatori e delle vulnerabilità di kube-hunter possono essere ricondotti a queste tecniche, ecco perché siamo passati a seguire lo standard della matrice.
Alcune vulnerabilità di kube-hunter che non siamo riusciti a mappare su tecniche Mitre sono precedute dalla parola chiave General

Ci sono tre modi diversi per eseguire kube-hunter, ciascuno offre un approccio diverso per rilevare punti deboli nel tuo cluster:
Esegui kube-hunter su qualsiasi macchina (incluso il tuo laptop), seleziona la scansione remota e fornisci l'indirizzo IP o il nome di dominio del tuo cluster Kubernetes. Questo ti darà una visione del tuo setup Kubernetes dal punto di vista di un attaccante.
Puoi eseguire kube-hunter direttamente su una macchina nel cluster e selezionare l'opzione per sondare tutte le interfacce di rete locali.
Puoi anche eseguire kube-hunter in un pod all'interno del cluster. Questo indica quanto sarebbe esposto il tuo cluster se uno dei tuoi pod applicativi venisse compromesso (ad esempio attraverso una vulnerabilità software). (flag --pod)
Prima verifica questi prerequisiti.
Per impostazione predefinita, kube-hunter avvierà una sessione interattiva in cui potrai selezionare una delle seguenti opzioni di scansione. Puoi anche specificare l'opzione di scansione manualmente dalla riga di comando. Queste sono le tue opzioni:
Per specificare macchine remote per la caccia, seleziona l'opzione 1 o usa l'opzione --remote. Esempio:
kube-hunter --remote some.node.com
Per specificare la scansione delle interfacce, puoi usare l'opzione --interface (questo scannerà tutte le interfacce di rete della macchina). Esempio:
kube-hunter --interface
Per specificare un CIDR specifico da scansionare, usa l'opzione --cidr. Esempio:
kube-hunter --cidr 192.168.0.0/24
Imposta il flag --k8s-auto-discover-nodes per interrogare Kubernetes per tutti i nodi nel cluster e poi tentare di scansionarli tutti. Per impostazione predefinita, utilizzerà la configurazione in-cluster per connettersi all'API Kubernetes. Se desideri utilizzare un file kubeconfig esplicito, imposta --kubeconfig /posizione/del/file/kubeconfig.
Nota anche che questo viene sempre fatto quando si utilizza la modalità --pod.
Per imitare un attaccante nelle sue fasi iniziali, kube-hunter non richiede autenticazione per la caccia.
Impersona - Puoi fornire a kube-hunter un token di service account specifico da utilizzare durante la caccia, passando manualmente il token JWT Bearer del segreto del service account con il flag --service-account-token.
Esempio:
$ kube-hunter --active --service-account-token eyJhbGciOiJSUzI1Ni...
Quando esegui con il flag --pod, kube-hunter utilizza il token del service account montato all'interno del pod per autenticarsi ai servizi che trova durante la caccia.
--service-account-token ha priorità quando si esegue come podLa caccia attiva è un'opzione in cui kube-hunter sfrutta le vulnerabilità che trova per esplorare ulteriori vulnerabilità. La differenza principale tra caccia normale e attiva è che una caccia normale non cambierà mai lo stato del cluster, mentre la caccia attiva può potenzialmente eseguire operazioni che modificano lo stato del cluster, che potrebbero essere dannose.
Per impostazione predefinita, kube-hunter non esegue la caccia attiva. Per eseguire una caccia attiva su un cluster, usa il flag --active. Esempio:
kube-hunter --remote some.domain.com --active
Puoi vedere l'elenco dei test con l'opzione --list. Esempio:
kube-hunter --list
Per vedere anche i test di caccia attiva oltre a quelli passivi:
kube-hunter --list --active
Per vedere solo una mappatura della rete dei tuoi nodi, esegui con l'opzione --mapping. Esempio:
kube-hunter --cidr 192.168.0.0/24 --mapping
Questo produrrà tutti i nodi Kubernetes che kube-hunter ha trovato.
Per controllare la registrazione, puoi specificare un livello di log, usando l'opzione --log. Esempio:
kube-hunter --active --log WARNING
I livelli di log disponibili sono:
Per impostazione predefinita, il report viene spedito a stdout, ma puoi specificare metodi diversi usando l'opzione --dispatch. Esempio:
kube-hunter --report json --dispatch http
I metodi di spedizione disponibili sono:
Quando eseguito come Pod in un ambiente Azure o AWS, kube-hunter recupera le sottoreti dal servizio di metadati delle istanze. Naturalmente ciò rende il processo di scoperta più lungo.
Per limitare forzatamente la scansione della sottorete a un CIDR /24, usa l'opzione --quick.
La caccia personalizzata consente agli utenti avanzati di avere il controllo su quali cacciatori vengono registrati all'inizio di una caccia. Se sai cosa stai facendo, questo può aiutare se desideri regolare il processo di caccia e scoperta di kube-hunter per le tue esigenze.
Esempio:
kube-hunter --custom <NomeCacciatore1> <NomeCacciatore2>
Abilitare la caccia personalizzata rimuove tutti i cacciatori dal processo di caccia, tranne quelli inseriti nella whitelist.
Il flag --custom legge un elenco di nomi di classi dei cacciatori; per visualizzare tutti i nomi delle classi di kube-hunter, puoi combinare il flag --raw-hunter-names con il flag --list.
Esempio:
kube-hunter --active --list --raw-hunter-names
Nota: A causa del design architetturale di kube-hunter, i seguenti "Cacciatori/Classi principali" verranno sempre registrati (anche quando si utilizza la caccia personalizzata):
Ci sono tre metodi per distribuire kube-hunter:
Puoi eseguire kube-hunter direttamente sulla tua macchina.
Dovrai avere installato:
Installa:
pip install kube-hunter
Esegui:
kube-hunter
Clona il repository:
git clone https://github.com/aquasecurity/kube-hunter.git
Installa le dipendenze del modulo. (Potresti preferire farlo all'interno di un Ambiente Virtuale)
cd ./kube-hunter
pip install -r requirements.txt
Esegui:
python3 kube_hunter
Se vuoi usare pyinstaller/py2exe devi prima eseguire lo script install_imports.py.
Aqua Security mantiene una versione containerizzata di kube-hunter presso aquasec/kube-hunter:aqua. Questo container include il codice sorgente, più un plugin di reporting aggiuntivo (a sorgente chiuso) per caricare i risultati in un report che può essere visualizzato a kube-hunter.aquasec.com. Nota bene: eseguire il container aquasec/kube-hunter e caricare i dati dei report sono soggetti a termini e condizioni aggiuntivi.
Il Dockerfile in questo repository ti consente di creare una versione containerizzata senza il plugin di reporting.
Se esegui il container kube-hunter con la rete dell'host, sarà in grado di sondare tutte le interfacce dell'host:
docker run -it --rm --network host aquasec/kube-hunter
Nota per Docker per Mac/Windows: Tieni presente che "host" per Docker per Mac o Windows è la VM in cui Docker esegue i container. Quindi specificare --network host consente a kube-hunter di accedere alle interfacce di rete di quella VM, piuttosto che a quelle della tua macchina.
Per impostazione predefinita, kube-hunter viene eseguito in modalità interattiva. Puoi anche specificare l'opzione di scansione con i parametri descritti sopra, ad esempio
docker run --rm aquasec/kube-hunter --cidr 192.168.0.0/24
Questa opzione ti permette di scoprire cosa può fare/scoprire l'esecuzione di un container malevolo sul tuo cluster. Questo dà una prospettiva su cosa potrebbe fare un attaccante se riuscisse a compromettere un pod, magari attraverso una vulnerabilità software. Potrebbe rivelare significativamente più vulnerabilità.
Il file di esempio job.yaml definisce un Job che esegue kube-hunter in un pod, utilizzando le impostazioni di accesso predefinite del pod Kubernetes. (Potresti voler modificare questa definizione, ad esempio per eseguire come utente non root, o per eseguire in un namespace diverso.)
kubectl create -f ./job.yamlkubectl describe job kube-hunterkubectl logs <nome pod>Per leggere le linee guida per i contributi, Clicca qui
Questo repository è disponibile sotto la Licenza Apache 2.0.