La sicurezza cloud-native era nell'aria al KubeCon/CloudNativeCon 2022

Essendo un appassionato di cinema autoidentificato, alcune battute di film in qualche modo mi rimangono impresse nel corso degli anni. Uno di questi è di Ridley Scott Gladiatore (2000), quando un senatore romano afferma: “Il cuore pulsante di Roma non è il marmo del Senato, è la sabbia del Colosseo”.

Questa frase mi è venuta in mente mentre camminavo per i corridoi del KubeCon/CloudNativeCon (“KubeCon”), l’evento principale del Fondazione Cloud Native Computing (CNCF). Per me, il cuore pulsante della sicurezza nativa del cloud è sicuramente KubeCon.

L’edizione nordamericana dell’evento di quest’anno si è svolta la scorsa settimana a Detroit, riunendo migliaia di partecipanti sul posto e molti altri da remoto. Oltre all'evento principale di tre giorni, il crescente interesse per progetti specifici ha portato la Cloud Native Computing Foundation a organizzare diversi “eventi co-locati” prima della conferenza principale.

Per l'evento del 2022, non c'era solo uno specifico evento di due giorni CloudNativeSecurityCon, ma anche numerosi contenuti sulla sicurezza in altri eventi, tra cui Application Networking Day, EnvoyCon, Policy Day con OPA, ServiceMeshCon e altro, riflettendo il vasto interesse per il cloud- argomenti di sicurezza nativi. È interessante notare che l'evento CloudNativeSecurityCon si è ora "promosso" a evento indipendente da ospitare separatamente a febbraio.

Sicurezza cloud-native: sviluppo vs. operazioni

Allora, qual è lo stato attuale delle conversazioni sulla sicurezza cloud-native? Per Omdia esiste una forte biforcazione: preoccupazioni incentrate sullo sviluppo e preoccupazioni incentrate sulle operazioni. Non è altrettanto utile chiamarli "Dev" e "Ops" perché la struttura dei team è in continuo mutamento in molte organizzazioni: alcuni possono avere team di ingegneria dell'affidabilità del sito (SRE), altri li chiamano team operativi, team di piattaforma e altro ancora.

Per quanto riguarda lo sviluppo del libro mastro, tre argomenti di interesse sono la provenienza, il rumore e l'esposizione.

La provenienza pone la domanda fondamentale: possiamo fidarci dell'integrità del componente esterno che stiamo incorporando nella nostra pipeline software? Sebbene esistano molti esempi, l’attacco SolarWinds del 2020 ha rappresentato un punto di svolta per l’interesse per l’integrità della catena di fornitura del software. Al KubeCon c'era uno slancio palpabile dietro l'idea di firmare immagini software: The store Il progetto è stato annunciato come disponibilità generale ed è utilizzato da Kubernetes e altri progetti chiave.

Il disturbo si riferisce alla riduzione del numero di vulnerabilità esistenti nell'ambiente, a partire dalla riduzione delle immagini di base del contenitore utilizzate. Ciò potrebbe includere l’utilizzo di basi di immagini come Alpine o Debian Slim o la considerazione di alternative “senza distro” ancora più piccole. Il vantaggio è che queste immagini più piccole hanno un ingombro minimo e quindi riducono la possibilità che emergano vulnerabilità.

Esposizione: per ogni vulnerabilità, quanto siamo esposti come organizzazione? Ovviamente non c'è esempio migliore di Log4j nella storia recente del settore. Questo è l'ambito delle discussioni sulle distinte materiali del software (SBOM) in quanto riguarda la conoscenza di dove i componenti possono essere utilizzati come immagini conservate in un registro da qualche parte o in esecuzione in produzione. È interessante notare che, mentre questo saggio viene scritto, viene comunicato in anticipo che le informazioni sulle vulnerabilità critiche in OpenSSL 3.x verranno divulgate a breve, il che sarà probabilmente un altro buon caso d'uso per gli SBOM: dove viene utilizzato OpenSSL 3.x nella nostra organizzazione? Dato che la copertura SBOM non è ancora diffusa, purtroppo Omdia prevede un utilizzo minimo della SBOM questa volta.

I team operativi sono naturalmente concentrati nel fornire e gestire una piattaforma sottostante sempre più complessa e nel farlo in modo sicuro. La parola “piattaforma” è particolarmente rilevante in questo caso: c’è stato un notevole interesse nell’organizzare Kubernetes e molti dei crescenti elenchi di progetti CNCF (140 al momento della stesura di questo articolo, tra le varie fasi di incubazione del progetto: sandbox, incubazione, laureati) in modalità più semplici. piattaforme di consumo. Di specifico interesse per il pubblico della sicurezza, progetti come Cilium (utilizzando la funzionalità eBPF sottostante) per il networking e l'osservabilità, SPIFFE/SPIRE (per stabilire identità), Falco (per la sicurezza runtime), Open Policy Agent (per policy-as-code) , Cloud Custodian (per la governance) e altri che vale la pena esaminare. L’aspettativa è che questi progetti collaborino sempre più con gli aspetti di “osservabilità” del cloud-native e vengano implementati anche utilizzando pratiche come GitOps.

Ragioni per l'ottimismo sulla sicurezza nativa del cloud

Dove andiamo da qui? Era assolutamente chiaro che la comunità nativa del cloud ha a cuore la sicurezza e sta andando avanti a tutta velocità affrontando i numerosi argomenti che la circondano. La guida per i team di sicurezza è quella di aggiornarsi rapidamente su come vengono implementati questi diversi progetti e iniziative. È importante notare che per molte organizzazioni ciò non avverrà sotto forma di utilizzo esplicito del progetto della comunità (anche se alcune lo faranno), ma piuttosto come parte di una piattaforma pacchettizzata di fornitori come Red Hat, SUSE, Canonical e altri. o direttamente dai fornitori di servizi cloud come AWS, Google Cloud, Azure, Oracle e altri.

Tieni presente che, nel contesto dell'utilizzo dell'open source, non esiste nulla di veramente "gratuito": anche se si sceglie di utilizzare la versione originale dei progetti, ci sono costi intrinseci nel mantenimento di tali pacchetti e nella partecipazione allo sviluppo della comunità.