Fattori di minaccia di Kubernetes gestiti
In un ambiente Kubernetes gestito, la gestione della sicurezza implica la comprensione e la mitigazione delle minacce in varie istanze. Di seguito è riportata un'analisi dettagliata dei fattori di minaccia in istanze specifiche:
Account compromesso
- Fattore di minaccia: un utente malintenzionato ottiene l'accesso a un cluster Kubernetes tramite credenziali, token API o chiavi rubate. Ciò può causare accessi non autorizzati, furti di dati e distribuzioni dannose.
- Mitigazione: implementare meccanismi di autenticazione forti, autenticazione a più fattori (MFA), rotazione regolare delle credenziali e principi di accesso con privilegio minimo.
Immagini vulnerabili o configurate in modo errato
- Fattore di minaccia: dopo la distribuzione, le immagini del contenitore con vulnerabilità o configurazioni errate possono essere sfruttate dagli utenti malintenzionati. Queste vulnerabilità potrebbero includere software obsoleto, impostazioni predefinite non sicure o segreti incorporati.
- Mitigazione: usare gli strumenti di analisi delle immagini per rilevare le vulnerabilità prima della distribuzione, applicare i criteri di provenienza delle immagini e adottare un processo di firma dell'immagine del contenitore.
Configurazione errata dell'ambiente
- Fattore di minaccia: configurazioni errate nelle impostazioni Kubernetes o nei descrittori di distribuzione possono esporre i cluster ad attacchi. I problemi comuni includono interfacce dashboard esposte, impostazioni del controllo degli accessi in base al ruolo (RBAC) eccessivamente permissive ed endpoint non protetti.
- Mitigazione: seguire le procedure consigliate per la configurazione sicura, controllare regolarmente le configurazioni con strumenti automatizzati e usare i controller di ammissione per applicare la conformità ai criteri.
Livello di attacco dell'applicazione
- Fattore di minaccia: le applicazioni in esecuzione nei contenitori potrebbero essere vulnerabili ai vettori di attacco Web tradizionali, ad esempio SQL injection o scripting intersito (XSS), che possono compromettere il contenitore o causare un ulteriore sfruttamento del cluster.
- Mitigazione: usare le procedure consigliate per la sicurezza delle applicazioni, ad esempio la convalida dell'input e la codifica dell'output e usare i Web Application Firewall (WAF). Implementare la sicurezza nella pipeline diIntegrazione continua (CI)/Recapito continuo e/o distribuzione ( CD), inclusi gli strumenti di analisi statica e dinamica.
Attacco a livello di nodo
- Fattore di minaccia: se un utente malintenzionato ottiene l'accesso a un nodo Kubernetes, può potenzialmente aumentare i privilegi per controllare l'intero cluster. Le vulnerabilità potrebbero derivare da sistemi operativi obsoleti o componenti Kubernetes.
- Mitigazione: mantenere aggiornati i nodi con le patch di sicurezza più recenti, limitare l'accesso ai nodi usando criteri di rete e firewall e usare sistemi di rilevamento delle intrusioni basati su host (HIDS).
Traffico non autorizzato
- Fattore di minaccia: l’accesso non autorizzato al cluster o proveniente da esso può verificarsi se i criteri di rete non sono configurati correttamente, consentendo in tal modo agli utenti malintenzionati di esfiltrare i dati, distribuire malware o sfruttare i servizi esposti.
- Mitigazione: implementare criteri di rete rigorosi per controllare il traffico in ingresso e in uscita, separare i carichi di lavoro sensibili usando gli spazi dei nomi e monitorare il traffico per individuare modelli anomali.
La gestione di queste minacce in un ambiente Kubernetes gestito richiede un approccio di sicurezza a più livelli che includa sia le pratiche specifiche di Kubernetes che le misure di sicurezza tradizionali. Il monitoraggio continuo, i controlli regolari e l'adesione al principio del minimo privilegio in tutti gli aspetti del cluster sono componenti essenziali di una solida strategia di sicurezza Kubernetes.
Tecniche di attacco comuni
- Sfruttare immagini vulnerabili: un'applicazione vulnerabile rivolta al pubblico in un cluster che consente l'accesso iniziale al cluster. Casi tristemente noti: SolarWinds, Log4j
- Accedere alle applicazioni esposte: un'interfaccia sensibile esposta a Internet rappresenta un rischio per la sicurezza. Alcuni framework popolari non sono stati progettati per essere esposti a Internet e pertanto non richiedono l'autenticazione per impostazione predefinita. Di conseguenza, l'esposizione a Internet consente l'accesso non autenticato a un'interfaccia sensibile che potrebbe consentire l'esecuzione di codice o la distribuzione di contenitori nel cluster da parte di un attore malintenzionato. Esempi di tali interfacce che sono state sfruttate includono Apache NiFi, Kubeflow, Argo Workflows, Weave Scope e il dashboard Kubernetes.
- Distribuire contenitori backdoor: gli utenti malintenzionati eseguono il codice dannoso in un contenitore nel cluster. Tramite i controller di Kubernetes, ad esempio DaemonSets o Distribuzioni, gli utenti malintenzionati si sono assicurati che un numero costante di contenitori venisse eseguito in uno, o in tutti, i nodi del cluster.
- Abuso nei confronti dei ruoli permissivi Software Assurance (SA): l'account del servizio (SA) rappresenta un'identità dell'applicazione in Kubernetes. Per impostazione predefinita, una Software Assurance viene montata in ogni pod creato nel cluster. Tramite la Software Assurance, i contenitori nel pod possono inviare richieste al server API Kubernetes. Gli utenti malintenzionati che ottengono l'accesso a un pod accedono al token di Software Assurance ed eseguono azioni nel cluster, in base alle autorizzazioni di SA. Se il controllo degli accessi in base al ruolo (RBAC) non è abilitato, Software Assurance dispone di autorizzazioni illimitate nel cluster. Se il controllo degli accessi in base al ruolo (RBAC) è abilitato, le relative autorizzazioni vengono determinate dai ruoli RoleBindings e ClusterRoleBindings associati.
- Escape verso l'host: il volume hostPath monta una directory o un file dall'host al contenitore. Gli utenti malintenzionati che dispongono delle autorizzazioni per creare un nuovo contenitore nel cluster possono crearne uno con un volume hostPath scrivibile e ottenere la persistenza nell'host sottostante. Ad esempio, quest'ultimo può essere ottenuto creando un processo cron nell'host.
