Michael Cade, Senior Global Technologist, Veeam, spiega perché una strategia zero-trust, il backup e il ripristino siano fondamentali quando si costruisce con Kubernetes.
Poiché le organizzazioni adottano sempre più un approccio cloud native per sviluppare e scalare le applicazioni, i container e Kubernetes svolgono un ruolo fondamentale nella gestione delle crescenti complessità e consentono di distribuire i carichi di lavoro in ambienti multi-cloud.
Tuttavia, un recente sondaggio condotto tra i professionisti DevOps ha rilevato che il 94% ha sperimentato almeno un incidente di sicurezza Kubernetes nell’ultimo anno e il 59% considera la sicurezza la sua principale preoccupazione quando si tratta di utilizzare Kubernetes e i container.
Mentre un numero sempre maggiore di team DevOps si rivolge a Kubernetes per soddisfare le esigenze di scalabilità della propria organizzazione, non si possono trascurare principi fondamentali come la sicurezza e la protezione dei dati.
Implementazione di Kubernetes
Agli sviluppatori viene chiesto di creare applicazioni sempre più grandi e scalabili in ambienti sempre più dinamici. Quindi, per il team operativo o di infrastruttura, può sembrare un lavoro a tempo pieno stare al passo con le pratiche di sviluppo del software in continua evoluzione. Kubernetes è solo la sfida più recente (e probabilmente più complessa), ma il loro obiettivo rimane lo stesso: come possiamo ridurre i rischi, minimizzare i costi e fornire un risultato aziendale complessivamente migliore?
I team di sviluppo sono i “pionieri”: esplorano nuovi terreni e costruiscono qualcosa dove prima non esisteva nulla. I team operativi e infrastrutturali, invece, sono i “coloni”: arrivano in una seconda ondata per consolidare i nuovi sviluppi e assicurarsi che sopravvivano a lungo termine. Questo è esattamente il caso di Kubernetes. Quando Kubernetes si trova nella fase di virtualizzazione o di adozione, di solito spetta ai team operativi, ai quali spetta la responsabilità dei risultati aziendali reali.
Ma è una richiesta eccessiva aspettarsi che questi team comprendano le complessità di Kubernetes e dei container. Anche con le nuove tecnologie, è necessario attenersi ai principi di base: sicurezza, backup e ripristino sono sempre necessari. Ma sono i requisiti tecnici unici che possono rappresentare una sfida.
Sicurezza in Kubernetes e zero-trust
In quanto programma Cloud Native, molte delle sfide di sicurezza per Kubernetes derivano dalla natura dispersiva dell’architettura cloud. I diversi carichi di lavoro possono essere eseguiti in diversi luoghi, tra cui più cloud e server off e on-premise. Questo non solo aumenta notevolmente il “panorama delle minacce” in cui può verificarsi un attacco o un errore, ma può anche comportare problemi di visibilità, rendendo più difficile il monitoraggio dei container e l’individuazione dei problemi.
Se da un lato Kubernetes è progettato per essere sicuro, rispondendo solo alle richieste che può autenticare e autorizzare, dall’altro offre agli sviluppatori opzioni di configurazione personalizzate, il che significa che è sicuro solo quanto le politiche RBAC (Role-based access control) che gli sviluppatori configurano. Kubernetes utilizza anche la cosiddetta “rete piatta” che consente a gruppi di container (o pod) di comunicare con altri container per impostazione predefinita. Questo solleva problemi di sicurezza, poiché in teoria gli aggressori che compromettono un pod possono accedere ad altre risorse nello stesso cluster.
Nonostante questa complessità, la soluzione per mitigare questo rischio è piuttosto semplice: una strategia zero-trust. Con una superficie di attacco così ampia, un design di rete piuttosto aperto e carichi di lavoro distribuiti in ambienti diversi, un’architettura zero-trust, che non si fida mai e verifica sempre, è fondamentale quando si costruisce con Kubernetes.
Il principio dell’architettura zero-trust consiste nello spostare l’attenzione sulla sicurezza dal perimetro di un’applicazione, applicando al contempo tali principi all’intero. Tutte le richieste interne sono considerate sospette e l’autenticazione è richiesta da cima a fondo. Questa strategia contribuisce a mitigare il rischio, partendo dal presupposto che le minacce siano sempre presenti sulla rete e quindi mantenendo costantemente procedure di sicurezza rigorose per ogni utente, dispositivo e connessione. Per l’architettura fluida e decentralizzata di Kubernetes, questo è un must.
Backup e ripristino
Un altro principio di base necessario per mitigare i rischi delle applicazioni Kubernetes è il backup e il ripristino. Si tratta di un concetto ben noto, ma il backup di Kubernetes e dei container richiede delle considerazioni particolari. Questi requisiti diversi per il backup dei dati sono dovuti al fatto che Kubernetes è fondamentalmente diverso da altre architetture, ad esempio non prevede la mappatura delle applicazioni su server o macchine virtuali.
I sistemi di backup Kubernetes devono essere incentrati sulle applicazioni piuttosto che sull’infrastruttura. Ciò è dovuto alla filosofia DevOps e ai principi di “spostamento a sinistra”, che significano essenzialmente che lo sviluppatore ha un maggiore controllo sull’infrastruttura e sulle distribuzioni. Altri requisiti unici per il backup di Kubernetes sono la scala dell’applicazione, le lacune di protezione e l’integrazione dell’ecosistema.
Quando si ripristinano gli ambienti Kubernetes, è necessario un piano di esecuzione dettagliato che identifichi le dipendenze del cluster, aggiorni le applicazioni per riflettere i nuovi componenti di storage e traduca il piano nelle interfacce di programmazione delle applicazioni (API) Kubernetes pertinenti. Sebbene il backup richieda una soluzione nativa Kubernetes più personalizzata, tali processi di ripristino rimangono fondamentali per la salute a lungo termine dell’azienda. Un ripristino e un disaster recovery efficienti non sono negoziabili nell’ambiente odierno, dove le interruzioni costano circa 1.459 euro al minuto.
Al di là di questo, tuttavia, il backup ha un enorme valore in termini di test e sviluppo e di mobilità delle applicazioni. Per mobilità delle applicazioni si intende la possibilità di migrare un’applicazione in un ambiente diverso, sia esso on-premise, cloud, cluster o distribuzioni Kubernetes. Questo aspetto è sempre più importante man mano che gli ambienti IT diventano più complessi e le aziende devono rispondere a nuovi requisiti aziendali, adottare nuove piattaforme tecnologiche o ottimizzare i costi.
Prepararsi al cambiamento
Nonostante Kubernetes presenti nuove sfide tecniche, in definitiva più le cose cambiano e più rimangono uguali. I team operativi e infrastrutturali sono ben abituati a incorporare nuovi strumenti in uno stack tecnologico in continua espansione e i principi fondamentali, come la mitigazione dei rischi attraverso una moderna protezione dei dati, sono ancora utili.
Una volta stabilite queste capacità, i team operativi possono iniziare a guardare oltre ed esplorare lo sfruttamento del valore dei loro dati attraverso attività come i test e l’ottimizzazione. Grazie a un backup robusto che supporta la mobilità delle app, i team possono anche fare molta strada per rendere le applicazioni a prova di futuro, assicurando che i servizi possano cavalcare più facilmente la prossima ondata di cambiamenti. Se Kubernetes è l’attuale strumento che sta cambiando il panorama degli sviluppatori, di certo non sarà l’ultimo.
