Vantaggi della sicurezza Kubernetes native

La sicurezza dei container prevede due approcci principali, il primo incentrato sui container e il secondo sul modello Kubernetes native. 

Le piattaforme incentrate sui container operano a livello del container, occupandosi di proteggere le immagini e i runtime dei container. Questi strumenti garantiscono i controlli a livello del container stesso tramite tecniche come i proxy inline o gli shim, ad esempio per controllare le comunicazioni tra i container.

La sicurezza Kubernetes native agisce a livello di Kubernetes, da cui ottiene il contesto e a cui invia i criteri che Kubernetes stesso deve applicare.

Sfruttando la perfetta integrazione con Kubernetes, la sicurezza Kubernetes native è in grado di importare il contesto e utilizzare i controlli nativi di Kubernetes. Questa architettura incrementa la sicurezza in due modi: fornendo il contesto e informazioni dettagliate e rilevando le minacce indirizzate specificamente a Kubernetes.

La sicurezza Kubernetes native parte dal presupposto che la protezione si implementa più efficacemente quando è in linea con il sistema che gestisce le applicazioni containerizzate. 

Per essere considerata Kubernetes native, una piattaforma di sicurezza deve presentare le seguenti caratteristiche:

• Deve integrarsi direttamente con il server API Kubernetes per ottenere visibilità sui carichi di lavoro e sull'infrastruttura
• Deve valutare le vulnerabilità nel software Kubernetes
• Le sue funzionalità di sicurezza, inclusa la gestione dei criteri, devono essere basate sulle risorse disponibili all'interno del modello di oggetti Kubernetes, che include spazi dei nomi, deployment, servizi, pod e altro
• Deve analizzare i dati dichiarativi delle configurazioni e degli artefatti specifici di Kubernetes, come i manifest dei carichi di lavoro
• Dove possibile, deve utilizzare le funzionalità di sicurezza integrate in Kubernetes in modo da aumentare i livelli di automazione, scalabilità e affidabilità
• Deve essere distribuita ed eseguita come un'applicazione Kubernetes, incluse le integrazioni e il supporto degli strumenti comuni nelle toolchain cloud native

La sicurezza Kubernetes native offre visibilità non solo alla configurazione dei container ma anche dei deployment dello stesso Kubernetes. 

È inoltre importante per comprendere se e come i carichi di lavoro sono isolati. Per impostazione predefinita, Kubernetes permette la comunicazione tra tutti i deployment, all'interno e all'esterno dei rispettivi spazi dei nomi. La dettagliata visibilità sulle impostazioni dei criteri di rete, preferibilmente in un formato grafico che evita la lettura di un file di testo YAML, facilita l'identificazione dei carichi di lavoro che non sono isolati.

Per stabilire il livello di sicurezza complessivo necessario, occorre verificare che le configurazioni Kubernetes come le autorizzazioni dei ruoli, l'accesso ai segreti, il traffico di rete consentito e le impostazioni dei componenti del piano di controllo siano bloccate, seguano le procedure consigliate e dispongano esclusivamente dei privilegi necessari all'esecuzione delle applicazioni.

Scopri come proteggere i container dalla creazione al deployment fino all'esecuzione

Proprio come per altre risorse di elaborazione, molte aziende scelgono di eseguire Kubernetes nel cloud. Per l'esecuzione nel cloud sono disponibili diverse opzioni:

• Kubernetes autogestito
• Distribuzione commerciale di Kubernetes
• Servizio Kubernetes gestito

Qualunque sia l'opzione scelta, condividerai con il provider cloud la responsabilità di proteggere il deployment. Sebbene a Kubernetes si applichi il modello tipico di responsabilità condivisa, soprattutto con i servizi Kubernetes gestiti, non sempre è chiaro su chi ricada effettivamente la responsabilità della sicurezza.

Nel caso dei servizi Kubernetes gestiti, il provider cloud gestisce il piano di controllo Kubernetes, che include i componenti di Kubernetes che controllano il cluster e i dati relativi alla condizione e alla configurazione del cluster.

I servizi includono in genere l'impostazione del piano di controllo e l'attivazione della ridondanza su tali nodi, inclusa la loro esecuzione su aree geografiche differenti per evitare interruzioni in caso di guasto di una parte dell'infrastruttura del provider cloud.

In genere, i provider cloud si occupano di:

• Mantenere Kubernetes aggiornato
• Applicare le correzioni necessarie al piano di controllo
• Fornire le correzioni al sistema operativo del nodo, un aspetto che può dipendere dalla tua scelta del sistema operativo
• Applicare ai nodi le immagini del sistema operativo ottimizzate per container
• Fornire eventualmente gli strumenti di scansione delle vulnerabilità, ma in questi casi dovrai creare i criteri, ad esempio i controller di ammissione necessari a consentire o a negare le autorizzazioni in base ai risultati della scansione

Il cliente ha sempre la responsabilità di proteggere il carico di lavoro Kubernetes, inclusa la gestione dei seguenti aspetti della sicurezza:

• Immagini container: sorgenti, contenuto e vulnerabilità
• Deployment: servizi di rete, storage e privilegi
• Gestione della configurazione: ruoli, gruppi, associazioni ai ruoli e account di servizio
• Applicazione: gestione dei segreti, etichette e annotazioni
• Segmentazione della rete: criteri di rete nel cluster
• Runtime: rilevamento delle minacce e risposta agli incidenti

Cosa sono SPIFFE e SPIRE?

Le piattaforme di sicurezza Kubernetes native offrono numerosi e importanti vantaggi. 

Maggiore protezione 

La sicurezza Kubernetes native fornisce informazioni più dettagliate, collegando i dati dichiarativi di Kubernetes in modo da individuare le vulnerabilità sia in Kubernetes che nei container. 

Incremento dell'efficienza operativa 

L'utilizzo dello stesso framework per la gestione dell'infrastruttura e la sicurezza riduce la curva di apprendimento di Kubernetes, mentre il contesto di Kubernetes accelera il rilevamento delle minacce e le valutazioni dei rischi prioritarie.

Riduzione del rischio operativo 

L'utilizzo dei controlli nativi di Kubernetes garantisce una sicurezza che ha lo stesso ritmo e la stessa scalabilità di Kubernetes. La disponibilità di criteri incorporati in Kubernetes evita i conflitti tra i controlli esterni e l'agente di orchestrazione.

La sicurezza Kubernetes native contribuisce a ridurre i problemi operativi dovuti a configurazioni incoerenti, mancanza di coordinazione ed errori degli utenti.

Considerata la curva di apprendimento di Kubernetes della maggior parte degli utenti, esiste un elevato rischio di errore, incluso quello di concedere privilegi elevati tramite il controllo degli accessi basato sui ruoli (RBAC) di Kubernetes, come l'assegnazione di autorizzazioni amministrative complete per il cluster a un account utente o di servizio, oppure l'inutile esposizione di segreti di Kubernetes permettendo ai deployment di eseguire il pull dei segreti anche quando non è necessario.

Le piattaforme di sicurezza Kubernetes native riescono a identificare in modo automatico e continuo questi errori di configurazione.

Incorporando i controlli di sicurezza direttamente in Kubernetes si evita anche il rischio associato all'utilizzo di un software di controllo separato che, in caso di errore, potrebbe rimanere erroneamente aperto, consentendo il passaggio di tutto il traffico senza applicare alcuna protezione, o erroneamente chiuso, bloccando tutto il traffico applicativo.

Poiché i controlli dei criteri vengono applicati dall'agente di orchestrazione Kubernetes, la sicurezza ottiene immediatamente la stessa scalabilità di Kubernetes e l'accesso alla gamma completa di opzioni per l'applicazione dei criteri. 

Per contro, l'utilizzo di proxy inline o di shim per l'applicazione dei criteri può generare potenziali punti di errore, ostacolare la scalabilità e limitare le prestazioni.

Con Kubernetes è possibile ad esempio applicare i criteri di rete per segmentare il traffico, utilizzare i controller di ammissione per applicare i criteri alle richieste inviate al server API Kubernetes, utilizzare i segreti per memorizzare le credenziali sensibili e applicare il controllo degli accessi basato sui ruoli (RBAC) per autorizzare funzionalità specifiche a determinati account utente e di servizio.

Insieme alla piattaforma di sicurezza Kubernetes native puoi anche avvalerti di strumenti standardizzati aggiuntivi, come i plugin di rete integrati nella Container Network Interface (CNI) e modificarli quando e come necessario.

Fornendo una singola piattaforma unificata per i servizi di provisioning e infrastruttura operativa, Kubernetes snellisce e aggrega i flussi di lavoro dei team operativi e di sviluppo applicativo. 

Questo approccio consolidato, in cui tutti utilizzano la stessa infrastruttura e fanno riferimento a una fonte di attendibilità comune, può essere esteso anche alla sicurezza eseguendo il deployment di una piattaforma di sicurezza Kubernetes native. 

Riducendo la curva di apprendimento e accelerando le attività di analisi e correzione, questo approccio permette di risparmiare tempo e denaro.

Se i team DevOps e di sicurezza utilizzano strumenti diversi, sarà diverso anche il modo in cui questi vengono configurati, il che può generare conflitti. 

Il team DevOps, ad esempio, potrebbe specificare un criterio di rete che consente il traffico tra due nodi, mentre il team di sicurezza potrebbe introdurre un controllo che lo blocca, utilizzando un software di controllo separato.

Analizzando le impostazioni in Kubernetes il team DevOps vede che l'applicazione consente il flusso del traffico, e potrebbe non avere idea del perché non avendo alcuna visibilità sui controlli esercitati dal software di controllo separato.

Se i team DevOps e della sicurezza utilizzano gli stessi costrutti per realizzare, distribuire e proteggere le applicazioni containerizzate, dovranno imparare a utilizzare un minor numero di interfacce, strumenti e modelli. 

Per definire le risorse necessarie a una determinata applicazione, DevOps utilizza i file manifest di Kubernetes. Utilizzando le stesse risorse per ottenere il contesto di sicurezza e applicare i criteri, i team possono ridurre la complessità e migliorare il livello di protezione. 

La sicurezza Kubernetes native considera Kubernetes come l'unica fonte di attendibilità per i criteri di sicurezza, e può essere utilizzata da tutti i team che si occupano di sicurezza, operazioni, DevOps e site reliability engineering (SRE). 

Inoltre, i problemi di sicurezza vengono associati direttamente agli oggetti e alle risorse Kubernetes con cui i team operano quotidianamente, semplificando ulteriormente le operazioni.

Evita il rischio operativo derivante dall'implementazione di un software di sicurezza separato applicando i criteri di sicurezza con l'approccio Kubernetes native.

Una serie di fattori correlati ai container complicano la sicurezza delle applicazioni cloud native, tra cui il fatto che gli incidenti possono essere frammentati e che i container generano elevati volumi di dati e sono temporanei, il che rende obsolete le tradizionali tecniche di risposta agli incidenti.

La sicurezza Kubernetes native permette di rilevare le minacce indirizzate ai container con maggiore precisione e riduce il tempo e l'impegno necessari per ottenere una sicurezza efficiente dell'intero ambiente.

Il contesto di Kubernetes permette di anticipare con chiarezza il comportamento previsto. Pertanto, la sicurezza Kubernetes native è in grado di anticipare le anomalie con maggiore attendibilità, permettendoti di scegliere le opzioni di applicazione (come l'arresto di un pod) con più precisione.

L'utilizzo del contesto di Kubernetes riduce anche i falsi positivi e la desensibilizzazione agli avvisi,

oltre a fornire la possibilità di adottare un approccio basato sul rischio alle attività di sicurezza. 

È possibile che i tuoi deployment contengano una serie di violazioni dei criteri, e anche in questo caso il contesto di Kubernetes è di aiuto. 

Combinando i diversi aspetti dei metadati Kubernetes, come il fatto che un cluster si trovi in un ambiente di sviluppo o di produzione, che sia o meno esposto a Internet, la criticità dell'applicazione e ogni eventuale processo sospetto attualmente in esecuzione, la sicurezza Kubernetes native permette di capire esattamente dove va indirizzata l'attenzione dei team. 

Il rilevamento delle vulnerabilità specifiche di Kubernetes, soprattutto quelle che mettono a rischio i server API Kubernetes, è un'attività fondamentale per la prevenzione, l'identificazione e la correzione. Gli strumenti di sicurezza Kubernetes native sono in grado di identificare queste vulnerabilità in modo automatico.

L'integrazione con il server API Kubernetes consente di monitorare la sicurezza sia per i container eseguiti nei cluster Kubernetes, sia per le risorse di Kubernetes, come deployment, set di daemon, servizi, pod e altro.

Anche la natura completamente aperta dei deployment Kubernetes costituisce un vettore di minaccia. Essendo Kubernetes sostanzialmente una piattaforma per l'operatività dell'infrastruttura, per mantenere la semplicità delle operazioni non tutti i componenti sono sicuri per impostazione predefinita. 

L'utilizzo dei criteri di rete di Kubernetes al fine di limitare le comunicazioni è un altro aspetto critico della protezione dei deployment Kubernetes. Le piattaforme di sicurezza Kubernetes native possono fornire automaticamente i valori di riferimento dell'attività di rete, identificare i percorsi di comunicazione necessari al funzionamento dell'applicazione e generare il file YAML corretto per ridurre l'ambito di accesso alla rete.

Grazie alle impostazioni per la sicurezza automatica disponibili in una piattaforma Kubernetes native, è possibile identificare e bloccare in modo continuativo le minacce al livello Kubernetes.

La sicurezza Kubernetes native garantisce anche elevati livelli di elevata portabilità e riutilizzo. L'adozione di un approccio unico e standardizzato eseguibile ovunque sia eseguito Kubernetes garantisce l'applicazione coerente dei criteri a tutti gli ambienti. 

La sicurezza Kubernetes native consente agli utenti di specificare una singola configurazione, ad esempio un criterio di rete, da applicare a tutti i pod di un deployment, anziché dover configurare controlli a livello di sistema su ogni host di un cluster. 

Integrando i criteri nei sistemi CI/CD e nel framework del controller di ammissione Kubernetes, le organizzazioni possono applicare più facilmente i criteri di controllo nelle prime fasi del ciclo di vita dello sviluppo del software, prevenendo le esposizioni in fase di runtime. 

Infine, l'utilizzo dei costrutti Kubernetes, come il controller di ammissione, garantisce un'integrazione profonda della sicurezza nelle toolchain Kubernetes.

Prova Enteprise Kubernetes