Che cos'è la sicurezza di Kubernetes?

L'importanza della sicurezza di Kubernetes

Come principale piattaforma per orchestrare Applicazione containerizzata sia in ambienti pubblici che privati di cloud , Kubernetes è diventata un obiettivo importante per i cybercriminali. Kubernetes è al centro dei flussi di lavoro moderni DevOps , permettendo ai team di automatizzare e scalare Applicazione Implementazione senza preoccuparsi dell'infrastruttura sottostante o delle complessità della gestione delle risorse. 

Tuttavia, Kubernetescomplessità rende anche facile introdurre e trascurare vulnerabilità o configurazioni errate che potrebbero esporre Applicationazione critica per il business. Se Kubernetes non è adeguatamente protetto, gli attaccanti possono compromettere carichi di lavoro critici, espellere dati sensibili o persino compromettere servizi essenziali.

Pertanto, le organizzazioni hanno bisogno di pratiche di sicurezza Kubernetes che tutelino la piattaforma e i suoi componenti fondamentali:

• Cluster: L'ambiente generale che contiene tutti i componenti di Kubernetes. È costituito da un piano di controllo che gestisce il cluster e da un set di nodi worker in cui Applicazione viene effettivamente eseguita.
• Nodes: Macchine, virtuali o fisiche, che eseguono carichi di lavoro containerizzati. Ogni nodo include un kubelet che comunica con il piano di controllo, un kube-proxy che gestisce le regole di rete e un runtime del contenitore.
• Capsule: I nodi eseguono i carichi di lavoro impacchettati nei pod, la più piccola unità distribuibile in Kubernetes che incapsula uno o più container che condividono storage, namespace di rete e configurazione.
• Componenti del piano di controllo: Gestisce lo stato e le operazioni del cluster. I suoi componenti chiave includono il server API e uno scheduler che assegna i pod ai nodi.

Noto anche come k8s Security, la sicurezza di Kubernetes comprende un'ampia gamma di misure di sicurezza progettate per proteggere questi componenti. Per raggiungere questo obiettivo, le organizzazioni devono adottare una strategia di sicurezza proattiva e multilivello per monitorare costantemente le minacce Kubernetes , mitigare gli attacchi e garantire la conformità agli standard normativi. Poiché Kubernetes sta diventando la base della maggior parte delle infrastrutture cloud, garantirne la sicurezza è una necessità per la continuità e il successo aziendale.

Sicurezza Kubernetes per ogni fase del ciclo di vita dell'applicazione

Per garantire una sicurezza robusta di k8s, è fondamentale affrontare le preoccupazioni di sicurezza in ogni fase del ciclo di vita di Applicazione. La sicurezza non è solo una considerazione post-Implementazione; Deve essere integrato in ogni fase del processo di sviluppo. 

Di seguito, suddividiamo le misure di sicurezza essenziali per ogni fase:

#1. Fase di sviluppo

La fase di sviluppo e progettazione rappresenta la prima linea di difesa nella sicurezza di Kubernetes. In questa fase, gli sviluppatori devono concentrarsi sulla creazione di Applicazioni e architettura sicure in grado di resistere a potenziali attacchi. Questo comporta la protezione dell'integrità dell'ambiente di sviluppo, la progettazione di Applicazione con la sicurezza in considerazione fin dall'inizio e l'implementazione di pratiche di codifica sicura. 

Le principali misure di sicurezza da considerare includono:

• Adottare un'architettura zero trust per convalidare ogni richiesta di accesso.
• Sviluppare un processo di revisione del codice e assicurarsi che il codice Applicazione sia privo di vulnerabilità.
• Applicare processi di gestione dei segreti sicuri per gestire correttamente i dati sensibili (password, chiavi API, token OAuth, ecc.).

#2. Fase di distribuzione

Durante la fase di distribuzione, è necessario rivedere la catena di approvvigionamento di Applicazione, assicurandovi che le immagini e gli altri componenti siano sicuri e aggiornati, privi di vulnerabilità note. 

To achieve this, you should:

• Esegui la scansione di tutte le immagini dei container per individuare eventuali vulnerabilità.
• Limitare l'accesso alle immagini dei container per prevenire accessi e manipolazioni non autorizzate.
• Aggiornare tutte le dipendenze e sviluppare processi di gestione delle patch per ottenere nuovi aggiornamenti il più rapidamente possibile.

#3. Fase di Implementazione

La fase Implementazione è quando l'Applicazione viene introdotta nel cluster Kubernetes . Garantire la sicurezza in questa fase comporta la configurazione dell'ambiente Kubernetes in modo sicuro e la gestione del processo Implementazione per minimizzare il rischio di esposizione delle vulnerabilità. 

Le pratiche di Implementazione sicura da considerare includono:

• Limitare Applicazione Implementazione a utenti e ambienti specifici.
• Scansionare immagini container per verificare l'identità crittografica e verificare che la firma sia valida, proveniente da un publisher affidabile e che l'artefatto non sia stato alterato.
• Distribuisci Applicazione e cluster in namespace separati.

#4. Fase di esecuzione

Sicurezza del runtime Kubernetes si concentra sulla fase operativa, in cui l'Applicazione è in esecuzione all'interno del cluster. La fase di runtime richiede un monitoraggio continuo e capacità di risposta agli incidenti per limitare l'impatto degli incidenti di sicurezza, nonché aggiornamenti continui per mantenere l'ambiente sicuro. 

Può essere suddiviso in tre aree principali:

• Accesso: Proteggere l'API Kubernetes con un controllo degli accessi robusti, processi di autenticazione e crittografia di tutto il traffico API.
• Calcola: Scegli un runtime del contenitore che fornisca un elevato livello di sicurezza e trovi un equilibrio tra l'isolamento di Applicazione e l'esecuzione sullo stesso host.
• Magazzinaggio: Cripta cluster e oggetti API a riposo, autentica le connessioni tra cluster e storage e utilizza backup in modo da poterli ripristinare se necessario.

Le 4C della sicurezza di Kubernetes

Per proteggere efficacemente Kubernetes dalle minacce, è necessario affrontare la sicurezza adottando il modello delle 4C. Il modello delle 4C è costituito da codice, contenitore, cluster e sicurezza cloud e rappresenta una roadmap per affrontare i problemi di sicurezza nell'architettura Kubernetes.

Codice di sicurezza

Il codice si riferisce all'Applicazione eseguita dai contenitori. Il codice rappresenta una superficie di attacco significativa negli ambienti Kubernetes, non solo a causa dell'introduzione involontaria di bug che comportano vulnerabilità, ma anche a causa di librerie di terze parti potenzialmente vulnerabili.

Per proteggere il codice in esecuzione sulla piattaforma Kubernetes, è necessario iniziare impedendo l'accesso non autorizzato al codice con controlli di accesso e sicurezza di rete di base come prima linea di difesa. Implementare pratiche di codifica sicure, eseguire scansioni e test regolari con strumenti dedicati e aderire alle linee guida di codifica OWASP .

Container Security

I contenitori contengono immagini, che a loro volta comprendono l'immagine base, il sistema operativo, la configurazione del container, le dipendenze e il runtime necessario per eseguire il codice Applicate.

I container in esecuzione nei pod devono utilizzare immagini di base e ambienti di runtime affidabili, ognuno dei quali potrebbe essere preso di mira da malintenzionati. Verificare che il repository delle immagini di origine sia sicuro, ridurre al minimo la base di codice per limitare il numero di librerie di terze parti in uso, analizzare le immagini dei container alla ricerca di vulnerabilità e proteggere i pod con controlli di accesso e policy di rete per limitare la comunicazione tra i pod.

Sicurezza del cluster

L'architettura Kubernetes è organizzata in cluster. I cluster Kubernetes sono costituiti da pod, e ogni pod contiene uno o più container che operano sulla stessa rete locale. La progettazione della sicurezza del cluster si basa su un'attenta progettazione delle politiche di accesso e delle configurazioni di sicurezza.

La sicurezza del cluster prevede la sicurezza di contenitori e applicazioni che funzionano all'interno, del piano di controllo (il API, lo scheduler, il datastore e i controller) e la rete più ampia in cui il cluster gira.

Cloud Security

Il livello cloud è il datacenter fisico o infrastruttura cloud che gestisce Kubernetes, comunemente piattaforme infrastructure as code (IaC) o servizi Kubernetes gestiti.

I provider cloud offrono linee guida e best practice di sicurezza per implementare controlli di accesso adeguati. Ridurre i rischi per l'infrastruttura cloud implementando procedure di minimo privilegio sulle risorse, scansionando vulnerabilità o configurazioni errate del cloud e controllando gli accessi per limitare quali utenti possono interagire con Kubernetes.

In generale, gli amministratori possono aspettarsi di implementare misure di sicurezza in tutte le fasi del ciclo di vita dell'Applicazione: dalla codifica e i test iniziali, all'Implementazione in produzione, fino alle operazioni continue all'interno del cluster.

Principi chiave per la sicurezza di Kubernetes

I seguenti principi e contromisure di sicurezza possono contribuire a garantire la resilienza dell'Applicazione containerizzata che funziona su Kubernetes:

Role-Based Access Control (RBAC)

In Kubernetes, RBAC controlla l'accesso alle risorse all'interno del cluster e definisce le azioni che un utente o un gruppo può o non può eseguire. RBAC viene utilizzato per isolare l'accesso del team, limitare le operazioni, controllare l'accesso dell'amministratore e gestire le autorizzazioni degli account di servizio.

I ruoli vengono utilizzati per concedere l'accesso alle risorse all'interno di un singolo namespace, mentre i ruoli del cluster hanno un ambito più ampio e definiscono l'accesso tra i namespace. Chiaramente, non tutti gli utenti dovrebbero avere accesso completo e illimitato a tutte le risorse. Nella valutazione dei ruoli e delle autorizzazioni di Kubernetes, fare riferimento al principio del privilegio minimo (PoLP) come linea guida generale.

Quando si utilizza RBAC, gli amministratori dovrebbero tendenzialmente preferire autorizzazioni specifiche per lo spazio dei nomi anziché autorizzazioni a livello di cluster, specificando i controlli di accesso per ogni oggetto e spazio dei nomi Kubernetes. Consenti l'accesso solo quando necessario per attività specifiche e nient'altro.

Applicazione delle politiche di rete

I container comunicano con servizi esterni e tra loro tramite la rete. Le applicazioni containerizzate spesso utilizzano ampiamente cluster rete. Per comprendere meglio come Applicazione interagisce con altri sistemi e identificare comunicazioni anomale, implementa il monitoraggio del traffico rete attivo e confrontalo con il traffico consentito dalla politica Kubernetes rete.

Per proteggere la connettività di rete, le organizzazioni devono applicare policy di rete che limitino la comunicazione ai servizi necessari, preferendo il minimo indispensabile per il corretto funzionamento dei carichi di lavoro. Questa raccomandazione si applica sia al traffico in entrata e in uscita verso il cluster, sia al traffico all'interno del cluster.

Cripta il traffico rete usando rete privato virtuale (VPN) e TLS. Per migliorare la sicurezza dei container, implementare Firewall all'interno dell'ambiente per aggiungere un ulteriore livello protettivo e implementare segmentazione rete e isolamento delle risorse per ridurre la superficie di attacco e contenere le violazioni.

Far rispettare l'ammissione di sicurezza dei Pod (PSA)

PSA, successore della Pod Security Policy (PSP), applica politiche di sicurezza, note come Pod Security Standards (PSS) all'interno di Kubernetes. Come funzione integrata, PSA elimina la necessità di strumenti di terze parti, semplificando la sicurezza definendo e rispettando un insieme di standard. Impone restrizioni alle configurazioni non sicure, riducendo la superficie di attacco.

Il PSS applicato da Pod Security Admission definisce tre profili di sicurezza per i carichi di lavoro. Il profilo Privilegiato non applica restrizioni e non dovrebbe essere utilizzato se non strettamente necessario. Il profilo Baseline fornisce un livello minimo di sicurezza per Applicationazione, mentre Restricted applica le migliori pratiche di sicurezza.

PSA verifica che i pod siano configurati in base a questi profili, garantendo la conformità. In generale, gli amministratori dovrebbero impostare il criterio Baseline o Restricted per i pod per garantire la sicurezza del cluster.

Fissa il piano di controllo

Il piano di controllo Kubernetes è responsabile del controllo del cluster. Gestisce lo stato del cluster, lo stato di salute e i dati di configurazione, assicurando che i container funzionino con tutte le risorse necessarie. A causa della sua importanza e complessità, il piano di controllo è considerato piuttosto difficile da configurare e di conseguenza è diventato un bersaglio principale per gli attaccanti.

Il piano di controllo è composto dai seguenti componenti:

• ecc.: Il database chiave-valore etcd memorizza informazioni di configurazione e dati sullo stato del cluster. Assicurati che etcd abbia abilitato Crittografia, che la comunicazione sia limitata al server API salvo assolutamente necessario, e che i client utilizzino l'autenticazione basata su certificati.
• kube-controller-manager: Il daemon Controller Manager gestisce cluster e ne controlla le funzioni. La sicurezza del Controller Manager comporta la limitazione dell'accesso alla rete, l'implementazione di TLS per tutto il traffico API, la limitazione dell'uso delle risorse nel cluster e la minimizzazione dei privilegi utilizzati dai container.
• kube-scheduler: lo Scheduler gestisce e fornisce nuovi container. Le misure di sicurezza includono la disattivazione della capacità di profilazione per ridurre la superficie di attacco e la verifica che l'indirizzo IP dello Scheduler non sia associato a un IP non sicuro.
• Kube-apiserver: L'API Server agisce come frontend, gestendo richieste interne ed esterne. In breve, mettere in sicurezza il server API limitando l'accesso tramite IPS esterni, applicando meccanismi di autenticazione forti e applicando TLS Crittografia. Consulta la sezione "Mettere in sicurezza l'API Kubernetes" qui sotto per maggiori dettagli.

Mettere in sicurezza il server API Kubernetes

Gli utenti esterni accedono al piano di controllo Kubernetes tramite l'API, quindi garantire la sua sicurezza e limitare l'accesso agli utenti non autorizzati è estremamente importante.

Per proteggere l'API di Kubernetes, inizia regolando le richieste destinate al server per assicurarti che le richieste API non autorizzate non riescano ad accedere correttamente al cluster. Si consiglia di utilizzare provider di autenticazione di terze parti, che abiliteranno l'autenticazione multifattore (MFA). Utilizzare connettori OAuth 2.0 o provider OpenID Connect (OIDC) per proteggere l'accesso al cluster.

Limitare l'accesso alla rete pubblica e implementare la crittografia Transport Layer Security (TLS) per i dati in transito tramite il server API . Verificare inoltre che il datastore Kubernetes, etcd, che comunica direttamente con il server API, sia a sua volta adeguatamente protetto.

Scansione di sicurezza delle immagini

Le immagini costituiscono la base di cluster e pod creati. Queste immagini devono essere scansionate regolarmente per vulnerabilità di sicurezza, assicurando che i contenitori creati a partire dalle immagini non ereditino le vulnerabilità di sicurezza dell'immagine.

Gli strumenti di scansione delle immagini possono essere utilizzati per identificare le vulnerabilità nell'immagine base su cui vengono costruiti i container, e Applicazione per le librerie incluse nelle immagini dei container. Questo avviene scansionando l'immagine base e tutti i pacchetti rispetto a un database di vulnerabilità.

Assicurarsi che l'accesso ai registri immagini sia limitato per prevenire manomissioni e scansionare tutte le immagini durante le fasi della pipeline di integrazione continua/Implementazione continua (CI/CD ). Aggiungere la scansione nella pipeline CI/CD aiuta a garantire che i container siano correttamente configurati, aggiornati e privi di malware.

Criptare i segreti e la comunicazione

I segreti sono una forma di informazione sensibile. In Kubernetes, i segreti più comuni sono in genere password, token OAuth, chiavi SSH o altre credenziali. I segreti archiviati in testo non crittografato, ovvero nei file di configurazione YAML, nelle immagini dei container o all'interno dei documenti sui container, rappresentano un rischio critico e mettono a repentaglio la sicurezza dell'intero cluster.

Kubernetes offre un oggetto integrato, il Kubernetes Secret, per memorizzare questi dati in modo sicuro. Utilizzando gli oggetti Secret, gli amministratori possono separare le informazioni riservate dal codice Applicazione.

Poiché Kubernetes Secrets gestisce informazioni riservate, è spesso preso di mira dagli hacker. I segreti devono essere crittografati quando sono inattivi e l'accesso ad essi deve essere limitato solo ai componenti e agli utenti che ne hanno bisogno. Implementare pratiche o sistemi di scansione segreta per identificare e porre rimedio all'esposizione accidentale di informazioni segrete.

Esposizione del nodo limite

I nodi Kubernetes si dividono in due tipi principali: nodi master e nodi work. I nodi master gestiscono i servizi base del cluster, inclusi il server API, lo scheduler, il controller e il datastore etcd. I nodi worker esegueno l'Applicazione all'interno del cluster.

Kubernetes cluster sono composti da nodi che eseguono sistemi operativi Linux o Windows (OS). Molte tecniche di indurimento che generalmente si applicano a questi sistemi operativi sono valide nel contesto di Kubernetes nodi:

• Installare solo l'Applicazione e le librerie necessarie per il corretto funzionamento del cluster, e nient'altro.
• Limita l'accesso agli account amministrativi / root, usandoli solo quando necessario.
• Implementare strumenti di monitoraggio in tempo reale per rilevare le violazioni di sicurezza in corso.
• I nodi Linux possono essere rafforzati con strumenti come SELinux o AppArmor.

Inoltre, il Center for Internet Security (CIS) fornisce una serie di benchmark di sicurezza sia per i nodi master che per quelli worker. Utilizzando uno strumento come Kube-bench, gli amministratori possono analizzare i propri cluster e valutarli in base ai benchmark CIS. Queste scansioni forniscono solitamente consigli per correggere le configurazioni che non rientrano nelle best practice CIS.

Abilita i Audit Log

I log di audit sono importanti per mantenere sia le operazioni che la sicurezza. Questi log offrono informazioni utili sull'attività del cluster e consentono una rapida rilevazione di attività anomale. Sebbene Kubernetes includa funzionalità di audit logging come funzione integrata, queste non sono abilitate di default. All'attivazione, tutte le azioni vengono registrate all'interno del cluster.

Gli amministratori del cluster devono configurare una policy di audit che definisca gli eventi da registrare e gli strumenti esterni per l'archiviazione, la gestione e l'analisi di tali registri. Ciò garantisce che i problemi di sicurezza vengano rilevati rapidamente, fornendo al contempo le informazioni necessarie ai team di risposta agli incidenti (IR) per indagare su eventuali violazioni.

Eseguire carichi di lavoro con privilegi minimi

I carichi di lavoro di Kubernetes possono essere complessi e difficili da proteggere adeguatamente. I carichi di lavoro sono dinamici e passano da ambienti on-premise a cloud, ognuno con i propri controlli di sicurezza di rete. Inoltre, i processi CI/CD automatizzati distribuiscono frequentemente nuovi servizi o nuove versioni sui nodi del cluster, intensificando la complessità.

In generale, gli amministratori non dovrebbero mai fidarsi dei carichi di lavoro. Applicare politiche di sicurezza dettagliate per limitare la comunicazione tra carichi di lavoro e Applicazione di terze parti. Ciò riduce la probabilità di spostamenti laterali delle minacce e aiuta a mantenere la conformità.

Le definizioni di sicurezza RETE dovrebbero essere integrate nei carichi di lavoro, assicurandone che siano portatili tra distribuzioni Kubernetes e Data Center. In questo modo, ovunque il carico di lavoro venga eseguito, porta con sé le definizioni di sicurezza.

Infine, configura strumenti di sicurezza perimetrale per monitorare continuamente gli indirizzi IP e le porte utilizzati dai carichi di lavoro, consentendo l'identificazione in tempo reale di comportamenti sospetti.