Som en selvidentificeret filmelsker holder nogle filmlinjer på en eller anden måde fast i mig gennem årene. En af dem er fra Ridley Scott's Gladiator (2000), når en romersk senator siger: "Roms bankende hjerte er ikke senatets marmor, det er Colosseums sand."
Den linje dukkede op i mit hoved, da jeg gik rundt i hallerne på KubeCon/CloudNativeCon ("KubeCon"), festen for Cloud Native Computing Foundation (CNCF). For mig er det bankende hjerte i cloud-native sikkerhed helt sikkert KubeCon.
Dette års nordamerikanske udgave af begivenheden fandt sted i sidste uge i Detroit, og samlede tusindvis af deltagere på stedet plus mange andre eksternt. Ud over den vigtigste tre-dages begivenhed, har den voksende interesse for specifikke projekter fået Cloud Native Computing Foundation til at oprette forskellige "samlokaliserede begivenheder" forud for hovedkonferencen.
Til begivenheden i 2022 var der ikke kun en specifik CloudNativeSecurityCon to-dages begivenhed, men også masser af sikkerhedsindhold på tværs af andre begivenheder, herunder Application Networking Day, EnvoyCon, Policy Day with OPA, ServiceMeshCon og mere, hvilket afspejler den brede interesse for cloud- indfødte sikkerhedsemner. Interessant nok er CloudNativeSecurityCon-begivenheden selv nu "graderet" til en uafhængig begivenhed, der skal afholdes separat i februar.
Cloud-native sikkerhed: Udvikling vs. Operations
Så hvor er den aktuelle tilstand af cloud-native sikkerhedssamtaler? For Omdia er der en stærk bifurkation: udviklingscentrerede bekymringer og driftscentrerede bekymringer. Det er ikke så nyttigt at kalde disse "Dev" og "Ops", fordi teamstrukturen er i forandring i mange organisationer: nogle kan have site reliability engineering (SRE) teams, nogle kan kalde dem operationer, platform teams og mere.
På udviklingssiden af hovedbogen er tre emner af interesse herkomst, støj og eksponering.
Herkomst stiller det grundlæggende spørgsmål: Kan vi stole på integriteten af den eksterne komponent, vi inkorporerer i vores softwarepipeline? Selvom der findes mange eksempler, var SolarWinds-angrebet i 2020 et vendepunkt for interessen for softwareforsyningskædens integritet. Hos KubeCon var der et håndgribeligt momentum bag ideen om at signere softwarebilleder: The sigstore Projektet blev annonceret som generel tilgængelighed og bliver brugt af Kubernetes og andre nøgleprojekter.
Støj refererer til at reducere antallet af sårbarheder, der findes i miljøet, begyndende med at slanke de containerbasebilleder, der bliver brugt. Dette kan omfatte brug af billedbaser såsom Alpine eller Debian Slim eller overvejelse af "distroløse" alternativer, der er endnu mindre. Fordelen er, at disse mindre billeder har minimalt fodaftryk og derfor reduceret chancen for, at sårbarheder dukker op.
Eksponering: For en given sårbarhed, hvor eksponeret er vi som organisation? Der er ikke noget bedre eksempel på dette i nyere industrihistorie end Log4j, selvfølgelig. Dette er området for diskussioner om softwarestyklister (SBOM'er), da det vedrører at vide, hvor komponenter kan bruges enten som billeder, der sidder i et register et eller andet sted eller kører i produktion. Interessant nok, mens dette essay bliver skrevet, er der forudgående varsel om, at oplysninger om kritiske sårbarheder i OpenSSL 3.x vil blive afsløret omgående, hvilket sandsynligvis vil være en anden god brugssag for SBOM'er - hvor bruges OpenSSL 3.x i vores organisation? I betragtning af at SBOM-dækningen stadig ikke er udbredt, forventer Omdia desværre minimal brug af SBOM denne gang.
Driftsteams er naturligvis fokuseret på at levere og drive en stadig mere kompleks underliggende platform og gøre det sikkert. Ordet "platform" er særligt relevant her: Der var bemærkelsesværdig interesse for at organisere Kubernetes og mange af den voksende liste af CNCF-projekter (140, når dette skrives, mellem de forskellige stadier af projektinkubation: sandkasse, inkubation, gradueret) til lettere- at forbruge platforme. Af specifik interesse for sikkerhedspublikum, projekter såsom Cilium (ved hjælp af den underliggende eBPF-funktionalitet) til netværk og observerbarhed, SPIFFE/SPIRE (til etablering af identiteter), Falco (til runtime-sikkerhed), Open Policy Agent (til policy-as-code) , Cloud Custodian (til styring) og andre er værd at se nærmere på. Forventningen er, at disse projekter i stigende grad vil samarbejde med "observations"-aspekter af cloud-native og også vil blive implementeret ved hjælp af praksisser som GitOps.
Årsager til optimisme med hensyn til cloud-native sikkerhed
Hvor går vi hen herfra? Det var helt klart, at det cloud-native fællesskab bekymrer sig dybt om sikkerhed og bevæger sig fremad i fuld hastighed med at tackle de mange emner omkring det. Vejledningen til sikkerhedsteams er hurtigt at komme op på, hvordan disse forskellige projekter og initiativer bliver implementeret. Det er vigtigt at bemærke, at for mange organisationer vil dette ikke komme i form af eksplicit brug af fællesskabsprojektet (selvom nogle vil), men snarere som en del af en pakket platform fra leverandører som Red Hat, SUSE, Canonical og andre, eller direkte fra cloud-udbyderne såsom AWS, Google Cloud, Azure, Oracle og andre.
Vær opmærksom på, at der i forbindelse med open source-brug ikke er noget, der hedder virkelig "gratis" - selvom man vælger at bruge vanilla upstream-versionen af projekter, er der iboende omkostninger ved at vedligeholde disse pakker og deltage i samfundsudviklingen.
