Piccole regole per fare sì che il vostro cluster Kubernetes non sia esposto e vulnerabile

È uno studio interessante quello pubblicato da Cyble nel quale viene descritto l’esito di uno scan di istanze Kubernetes esposte su internet che parla di numeri particolarmente rilevanti. Sono infatti novecentomila le istanze di Kubernetes rilevate “in qualche modo” raggiungibili.

Già perché la modalità con cui queste istanze sono esposte è particolare. Lo scan è stato condotto andando ad interrogare questi elementi che sono tipicamente parte di un cluster k8s:

• KubernetesDashboard
• Kubernetes-master
• Kubernetes
• Kube
• K8
• Favicon:2130463260, -1203021870

In base alle risposte ricevute poi è stato possibile raggruppare dei novecentomila cluster la modalità con cui questi risultavano esposti, ed il risultato è stato questo:

Ora, il dato è interessante perché nel caso del 403 di fatto si tratta di una “porta in faccia” (cioè forbidden), nel caso del 401 unauthorized mentre nel caso del 200… Ci si trova davanti alla dashboard del cluster.

Siano ambienti di test o altro è presto detto: c’è poco da stare sereni. Se infatti quello di Cyble è uno scan da White Hat non tutta internet è popolata da morigerati e puri di cuore, perciò facciamo nostri i consigli dati in coda all’articolo e li riportiamo in toto:

• Mantenere Kubernetes aggiornato.
• Rimuovere gli strumenti di debug dai container di produzione.
• Controllare le persone con accesso all’API Kubernetes e quali autorizzazioni hanno con il controllo degli accessi basato sui ruoli (RBAC).
• Limitare l’esposizione di risorse e porte critiche, assicurandosi che la propria rete limiti l’accesso alle porte relative a kubelet, come 10255 e 10250 e magari limitare l’accesso al server API Kubernetes solo a reti affidabili.potrebbe valer la pena tenerla l
• Separare i carichi di lavoro “importanti”, che dovrebbero essere eseguiti su un gruppo separato di workstation. Questo metodo riduce la possibilità di accesso a un’applicazione sensibile tramite un’applicazione meno sicura che condivide un runtime o un host del contenitore.
• Seguire le best practice per la configurazione di Kubernetes.
• Creare e definire policy di rete e policy di sicurezza del pod a livello di cluster
• Basarsi sul CIS Kubernetes Benchmark come prima cosa per la sicurezza Kubernetes.
• Assicurarsi che gli audit log siano abilitati e monitorati per richieste API insolite, in particolare per eventuali errori di autorizzazione.
• Ridurre al minimo l’accesso amministrativo ai nodi Kubernetes.

Una bella e importante lista, forse lunga, ma da tenere sempre al proprio fianco quando si parla di Kubernetes e sicurezza. A proposito, aggiungereste qualcosa?