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:
| Status Code | Count |
| 403 | 975,371 |
| 401 | 4,954 |
| 200 | 799 |
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?
Da sempre appassionato del mondo open-source e di Linux nel 2009 ho fondato il portale Mia Mamma Usa Linux! per condividere articoli, notizie ed in generale tutto quello che riguarda il mondo del pinguino, con particolare attenzione alle tematiche di interoperabilità, HA e cloud.
E, sì, mia mamma usa Linux dal 2009.
Se vuoi sostenerci, puoi farlo acquistando qualsiasi cosa dai diversi link di affiliazione che abbiamo nel nostro sito o partendo da qui oppure alcune di queste distribuzioni GNU/Linux che sono disponibili sul nostro negozio online, quelle mancanti possono essere comunque richieste, e su cui trovi anche PC, NAS e il ns ServerOne. Se ti senti generoso, puoi anche donarmi solo 1€ o più se vuoi con PayPal e aiutarmi a continuare a pubblicare più contenuti come questo. Grazie!
Hai dubbi o problemi? Ti aiutiamo noi!
Se vuoi rimanere sempre aggiornato, iscriviti al nostro canale Telegram.Se vuoi ricevere supporto per qualsiasi dubbio o problema, iscriviti alla nostra community Facebook o gruppo Telegram.
Cosa ne pensi? Fateci sapere i vostri pensieri nei commenti qui sotto.
Ti piace quello che leggi? Per favore condividilo con gli altri.
