Introduzione
Strumenti di orchestrazione come Kubernetes hanno introdotto livelli senza precedenti di resilienza e versatilità nell'implementazione e nella gestione del software. Hanno anche acceso i riflettori sulle inadeguatezze dell'attuale panorama della sicurezza.
L'architettura dispersa di Kubernetes ci fornisce diversi livelli aggiuntivi. Possiamo usarli per migliorare e sfruttare le impostazioni di sicurezza esistenti. Se configuri correttamente questi livelli, possono isolare qualsiasi minaccia alla sicurezza prima che esploda dal punto di origine.
Questo articolo si concentra sulle misure che puoi adottare per migliorare la sicurezza generale del tuo cluster Kubernetes.
1. Abilita il controllo degli accessi in base al ruolo (RBAC)
La complessità di un sistema in esecuzione su più dispositivi, con molti microservizi interconnessi gestiti da centinaia di persone e utility è un incubo logistico.
Esercita un controllo rigoroso sulle autorizzazioni concesse agli utenti. Kubernetes è un sostenitore del controllo di accesso basato sui ruoli (RBAC) metodo. Il metodo di controllo dell'accesso basato sui ruoli significa che nessun utente ha più autorizzazioni di quelle necessarie per svolgere i propri compiti in modo efficace. Kubernetes è incentrato sull'automazione e RBAC utilizza un gruppo API per guidare le decisioni di autorizzazione tramite l'API Kubernetes.
A partire dalla versione 1.8 di Kubernetes, la modalità RBAC è stabile e supportata dall'API rbac.authorization.k8s.io/v1. Abilita RBAC avviando il server API con il seguente comando:
--authorization-mode=RBACKubernetes ha una serie di ruoli predefiniti sia per gli utenti umani che per i componenti, come app, controller e nodi. Questi ruoli predefiniti sono numerosi e offrono un livello predefinito ragionevole di ruoli separati per le attività più comuni.
2. Mantieni segreti i tuoi segreti
In Kubernetes, un segreto è un piccolo oggetto che contiene dati sensibili, come una password o un token.
Anche se un pod non è in grado di accedere ai segreti di un altro pod, è fondamentale mantenere il segreto separato da un'immagine o da un pod. Altrimenti, chiunque abbia accesso all'immagine avrebbe accesso anche al segreto. Le applicazioni complesse che gestiscono più processi e hanno accesso pubblico sono particolarmente vulnerabili a questo riguardo.
Assegna processi a contenitori diversi
Ogni contenitore in un pod deve richiedere il volume segreto nel suo volume. Riduci il rischio che i segreti vengano svelati dividendo i processi in contenitori separati. Utilizza un contenitore front-end che interagisce con gli utenti ma non è in grado di visualizzare la chiave privata.
Completa quel contenitore con un contenitore del firmatario in grado di vedere la chiave privata e rispondere a semplici richieste di firma dal front-end. Questo approccio partizionato costringe un utente malintenzionato a eseguire una serie di azioni complesse nel tentativo di violare le tue misure di sicurezza.
3. Limita il traffico da pod a pod con un criterio di rete Kubernetes
Si tratta di una best practice Kubernetes Security per imporre il protocollo di sicurezza TLS a ogni livello della pipeline di distribuzione dell'applicazione. Tuttavia, è anche fondamentale proteggere i singoli elementi che compongono il cluster e gli elementi che controllano l'accesso al cluster.
I pod accettano il traffico da qualsiasi fonte per impostazione predefinita. Quando definisci le Norme di rete , imposti regole specifiche su come i pod comunicano all'interno di un cluster e con risorse esterne.
Le politiche di rete non sono in conflitto ma sono invece additivi. Definire una politica di rete in uno spazio dei nomi significa che il pod rifiuterà qualsiasi connessione non consentita da tale politica, isolando di fatto il pod. Il pod è limitato a ciò che è approvato dalla combinazione di più criteri di rete.
4. Migliora la sicurezza del pod
Protezione del kernel con AppArmor o SELinux
I container condividono lo stesso kernel, rendendo necessario l'uso di strumenti aggiuntivi per migliorare l'isolamento dei container. Moduli di sicurezza, come AppArmor e sistemi che applicano politiche di controllo degli accessi come SELinux , limitare i programmi utente e i servizi di sistema. Vengono anche utilizzati per negare l'accesso ai file e limitare le risorse di rete.
AppArmor limita l'insieme di risorse disponibili per un contenitore all'interno del sistema. Ciascun profilo può essere eseguito in enforcement modalità, che blocca l'accesso alle risorse non consentite o reclamo modalità che segnala solo le violazioni. Un rapporto tempestivo di potenziali problemi migliora notevolmente le capacità di registrazione e controllo dei tuoi sistemi.
SELinux gestisce l'allocazione delle risorse indipendentemente dall'ACM (Access Control Mechanism) generale di Linux. Non riconosce un superutente (root) e non dipende dai binari setuid/setgid.
La protezione di un sistema senza SELinux si basa sulla corretta configurazione delle applicazioni privilegiate e del kernel stesso. Un'errata configurazione in queste aree può compromettere l'intero sistema. La sicurezza di un sistema basato su un kernel SELinux dipende dalla correttezza del kernel e dalla sua configurazione della politica di sicurezza.
Gli attacchi rappresentano ancora una minaccia significativa. Tuttavia, con SELinux, i singoli programmi utente e i demoni di sistema non devono necessariamente mettere in pericolo la sicurezza dell'intero sistema.
Macchie e tolleranze
Kubernetes offre la possibilità di creare regole predefinite quando il sistema assegna nuovi pod ai nodi.
Come strumento di orchestrazione, Kubernetes tende ad avviare i pod nella posizione più efficiente del cluster, ovvero la posizione con il carico di lavoro più piccolo. È possibile modificare il posizionamento dei pod definendo contaminazioni e tolleranze.
I contaminanti consentono ai nodi di "rifiutare" un pod o un insieme di pod in base alle regole predefinite. D'altra parte, le tolleranze vengono applicate a livello di pod e consentono ai pod di pianificare su nodi con contaminazioni corrispondenti (le chiavi e gli effetti sono gli stessi).
I contaminanti e le tolleranze dovrebbero essere usati in tandem per assicurarsi che i pod non vengano programmati su nodi inappropriati.
Spazi dei nomi
Kubernetes non dispone di un meccanismo che fornisce sicurezza tra gli spazi dei nomi. Limitare l'uso degli spazi dei nomi, come funzionalità di sicurezza, all'interno di domini attendibili e per scopi interni. Non utilizzare i namespace quando desideri negare a un utente del cluster Kubernetes l'accesso a una qualsiasi delle risorse degli altri namespace.
L'watch e list le richieste consentono ai client di ispezionare i valori di tutti i segreti che si trovano in quello spazio dei nomi. Solo i componenti più privilegiati a livello di sistema dovrebbero disporre dell'autorizzazione per implementare queste richieste.
5. Aggiornamenti continui di Kubernetes
È diventato impossibile tracciare tutti i potenziali vettori di attacco. Questo fatto è sfortunato in quanto non c'è niente di più vitale che essere consapevoli e in cima alle potenziali minacce. La migliore difesa è assicurarsi di eseguire l'ultima versione disponibile di Kubernetes.
Esistono diverse tecniche come gli aggiornamenti in sequenza e le migrazioni del pool di nodi che consentono di completare un aggiornamento con interruzioni e tempi di inattività minimi.
6. Definire le politiche di audit
La registrazione di controllo registra la sequenza temporale degli eventi che si verificano in un cluster Kubernetes. Tenendo traccia delle azioni intraprese dagli utenti e dall'API Kubernetes, gli amministratori possono analizzare la catena di eventi che ha portato a un potenziale problema.
Kubernetes ti consente di perfezionare le politiche di controllo definendo la frequenza con cui gli eventi vengono registrati, se devono essere emessi avvisi e la procedura per terminare i pod interessati.
Utilizza regolarmente la registrazione di controllo per assicurarti che il tuo sistema sia aggiornato e che le minacce siano tenute sotto controllo. Una distribuzione basata su container aggiunge un'altra dimensione al processo di audit. Un confronto tra l'immagine originale e l'immagine in esecuzione nel contenitore può essere utilizzato in modo efficace per vedere se eventuali discrepanze possono causare problemi di sicurezza. Assicurati che le versioni del tuo software contengano sempre le ultime patch di sicurezza.