Som en självidentifierad filmfantast har vissa filmrader på något sätt hängt med mig genom åren. En av dem är från Ridley Scott's Gladiator (2000), när en romersk senator säger, "Roms bankande hjärta är inte senatens marmor, det är Colosseums sand."
Den raden dök upp i mitt huvud när jag gick runt i hallarna på KubeCon/CloudNativeCon ("KubeCon"), tältevenemanget för Cloud Native Computing Foundation (CNCF). För mig är det bultande hjärtat av molnbaserad säkerhet absolut KubeCon.
Årets nordamerikanska upplaga av evenemanget ägde rum förra veckan i Detroit, och samlade tusentals deltagare på plats plus många andra på distans. Utöver det huvudsakliga tredagarsevenemanget har det växande intresset för specifika projekt lett till att Cloud Native Computing Foundation har arrangerat olika "samlokaliserade evenemang" inför huvudkonferensen.
För evenemanget 2022 fanns det inte bara ett specifikt CloudNativeSecurityCon tvådagarsevenemang utan också massor av säkerhetsinnehåll över andra evenemang, inklusive Application Networking Day, EnvoyCon, Policy Day with OPA, ServiceMeshCon och mer, vilket speglar det breda intresset för moln- inbyggda säkerhetsämnen. Intressant nog har CloudNativeSecurityCon-eventet självt nu "graderat" till ett oberoende event som ska hållas separat i februari.
Cloud-native säkerhet: utveckling kontra drift
Så, var är det nuvarande tillståndet för molnbaserade säkerhetskonversationer? För Omdia finns det en stark bifurkation: utvecklingscentrerade bekymmer och verksamhetscentrerade bekymmer. Det är inte lika bra att kalla dessa "Dev" och "Ops" eftersom teamstrukturen är i förändring i många organisationer: vissa kan ha SRE-team (site reliability engineering), vissa kan kalla dem operationer, plattformsteam och mer.
På utvecklingssidan av reskontran är tre ämnen av intresse härkomst, buller och exponering.
Härkomst ställer den grundläggande frågan: Kan vi lita på integriteten hos den externa komponenten vi införlivar i vår mjukvarupipeline? Även om det finns många exempel, var SolarWinds-attacken 2020 en vändpunkt för intresset för integriteten i mjukvaruförsörjningskedjan. På KubeCon fanns det en påtaglig fart bakom idén att signera mjukvarubilder: The sigstore Projektet tillkännagavs som allmänt tillgängligt och används av Kubernetes och andra nyckelprojekt.
Brus syftar på att minska antalet sårbarheter som finns i miljön, till att börja med att banta ner de behållarbasbilder som används. Detta kan innefatta att använda bildbaser som Alpine eller Debian Slim eller överväga "distroless" alternativ som är ännu mindre. Fördelen är att dessa mindre bilder har minimalt fotavtryck och därför minskar risken för att sårbarheter dyker upp.
Exponering: Hur utsatta är vi som organisation för en given sårbarhet? Det finns inget bättre exempel på detta i nyare branschhistoria än Log4j, förstås. Detta är området för diskussioner om mjukvaruförteckningar (SBOMs) eftersom det handlar om att veta var komponenter kan användas antingen som bilder som sitter i ett register någonstans eller körs i produktion. Intressant nog, när den här uppsatsen skrivs, finns det förhandsmeddelande om att information om kritiska sårbarheter i OpenSSL 3.x kommer att avslöjas omedelbart, vilket sannolikt kommer att vara ett annat bra användningsfall för SBOMs - precis var används OpenSSL 3.x i vår organisation? Med tanke på att SBOM-täckningen fortfarande inte är utbredd, förväntar sig Omdia minimal SBOM-användning denna gång, tyvärr.
Operationsteam är naturligtvis fokuserade på att tillhandahålla och driva en allt mer komplex underliggande plattform och att göra det på ett säkert sätt. Ordet "plattform" är särskilt relevant här: Det fanns ett anmärkningsvärt intresse för att organisera Kubernetes och många av den växande listan av CNCF-projekt (140 när detta skrivs, mellan de olika stadierna av projektinkubation: sandlåda, inkubation, graderad) till enklare- att konsumera plattformar. Av specifikt intresse för säkerhetsmålgrupper, projekt som Cilium (med den underliggande eBPF-funktionaliteten) för nätverk och observerbarhet, SPIFFE/SPIRE (för att etablera identiteter), Falco (för körtidssäkerhet), Open Policy Agent (för policy-som-kod) , Cloud Custodian (för styrning) och andra är värda att titta närmare på. Förväntningen är att dessa projekt i allt högre grad kommer att samarbeta med "observerbarhet" aspekter av moln-native och kommer också att distribueras med metoder som GitOps.
Anledningar till optimism om molnbaserad säkerhet
Vart går vi härifrån? Det var alldeles tydligt att det molnbaserade samhället bryr sig mycket om säkerhet och går framåt i full fart med att ta itu med de många ämnen som finns runt det. Vägledningen till säkerhetsteam är att snabbt få reda på hur dessa olika projekt och initiativ genomförs. Det är viktigt att notera att för många organisationer kommer detta inte att komma i form av att explicit använda communityprojektet (även om vissa kommer), utan snarare som en del av en paketerad plattform från leverantörer som Red Hat, SUSE, Canonical och andra, eller direkt från molnleverantörerna som AWS, Google Cloud, Azure, Oracle och andra.
Var medveten om att i sammanhanget med användning av öppen källkod finns det inget som verkligen är "gratis" - även om man väljer att använda vanilj uppströmsversionen av projekt, finns det inneboende kostnader för att underhålla dessa paket och delta i communityutvecklingen.
