Container security: Snyk, Trivy och Falco för runtime-säkerhet i K8s

Containrar gjorde det enkelt att paketera och köra applikationer, men de flyttade också säkerheten. En containeravbildning bär med sig allt den byggts av - operativsystemslager, bibliotek, beroenden - och varje del kan ha sårbarheter. Säkerhet i Kubernetes handlar därför om att täcka hela livscykeln: från att skanna avbildningar i bygget till att upptäcka misstänkt beteende i körande poddar. Här går jag igenom hur jag lägger det med Snyk, Trivy och Falco.

Ett vanligt missförstånd är att containersäkerhet är en enda sak man slår på. Det är det inte. Det är en kedja av kontroller som griper in i olika skeden, och kedjan är bara så stark som sin svagaste länk. En perfekt skannad avbildning hjälper inte om den körande podden har för breda privilegier, och världens hårdaste klusterhärdning hjälper inte om avbildningen är full av kända sårbarheter. Poängen med att tänka i livscykel är just att ingen enskild åtgärd räcker - de förstärker varandra, och det är helheten som ger skyddet.

Skift vänster: skanna i bygget

Den billigaste sårbarheten att åtgärda är den som fångas innan den når produktion. Därför börjar containersäkerhet i pipelinen. Trivy är ett utmärkt öppet verktyg för att skanna avbildningar efter kända sårbarheter i operativsystemslager och beroenden, och det är snabbt nog att köra på varje bygge. Snyk går djupare in i applikationens egna beroenden och kopplar fynd till hur de åtgärdas. Tillsammans ger de en grind där en avbildning med allvarliga, åtgärdbara brister stoppas innan den driftsätts.

• Trivy för snabb skanning av avbildningens lager och OS-paket.
• Snyk för djupare analys av applikationsberoenden och åtgärdsförslag.
• En grind i pipelinen som stoppar avbildningar med allvarliga fynd.

Bygg minimala avbildningar

Den bästa sårbarheten är den som aldrig finns med. Genom att bygga på minimala basavbildningar - distroless eller liknande - minskar du antalet komponenter som kan vara sårbara dramatiskt. En avbildning utan ett helt operativsystem har helt enkelt mycket mindre angreppsyta. Det är en av de mest effektiva åtgärderna och kostar bara lite disciplin i hur avbildningarna byggs.

En extra vinst med minimala avbildningar är att de gör skanningen mer meningsfull. En avbildning byggd på en full Linux-distribution genererar ofta en lång lista av sårbarheter i paket som applikationen aldrig ens använder, och den listan blir så brusig att den verkligt viktiga signalen drunknar. Med en distroless-bild blir varje fynd som faktiskt dyker upp relevant och värt att agera på. Du går från att ignorera en oöverskådlig lista till att åtgärda en kort, vilket i sig höjer säkerheten.

Runtime: när avbildningen redan kör

Skanning fångar kända sårbarheter, men inte allt. En angripare som tar sig in utnyttjar något ingen skannade efter, och då behöver du se vad som faktiskt händer i den körande podden. Det är här Falco kommer in. Falco övervakar systemanrop i realtid och larmar på misstänkt beteende - ett skal som startas i en container som aldrig borde köra ett, en process som läser känsliga filer, oväntad utgående nätverkstrafik. Det är skillnaden mellan att skydda dörren och att märka när någon ändå tagit sig in.

Styrkan i runtime-övervakning är att den utgår från beteende i stället för från en lista över kända brister. En container som kör en webbtjänst har ett ganska förutsägbart beteende, och allt som avviker från det - plötsligt ett interaktivt skal, läsning av filer den aldrig rört, anrop mot en okänd adress - är ett tecken på att något är fel, även om den underliggande sårbarheten var helt okänd. Det är så du fångar nolldagar och felkonfigurationer som ingen skanning kunde ha förutsett. Falco ersätter inte skanningen, men det täcker just den lucka skanningen lämnar.

Härda själva klustret

Verktygen kompletteras av att Kubernetes-miljön i sig är hårdnad. Poddar ska köra utan onödiga privilegier, helst som icke-root. Nätverkspolicyer ska begränsa vilka poddar som får prata med varandra. Och behörigheter via RBAC ska följa least privilege så att en komprometterad podd inte kan göra mer än den måste. Verktygen och härdningen förstärker varandra - inget av dem räcker ensamt.

Nätverkspolicyer förtjänar särskild uppmärksamhet, för i ett standardkluster får alla poddar prata med alla andra. Det betyder att en angripare som tar sig in i en podd fritt kan röra sig vidare i klustret. Genom att som standard neka all trafik och bara tillåta de flöden som faktiskt behövs begränsar du hur långt ett intrång kan spridas. Det är samma segmenteringsprincip som på nätverksnivå, applicerad inuti klustret, och den höjer säkerheten avsevärt för en relativt liten insats.

Hela kedjan i korthet

• Skanna avbildningar i bygget med Trivy och Snyk.
• Bygg på minimala basavbildningar för mindre angreppsyta.
• Övervaka körande poddar med Falco för avvikande beteende.
• Härda klustret: icke-root, nätverkspolicyer, least privilege.

Vill du ha hjälp att lägga säkerheten genom hela kedjan kan du läsa om min molninfrastruktur.

Relaterat

• Azure Landing Zone vs AWS Control Tower vs GCP Org Setup
• Terraform-moduler vi använder för varje kundsetup (open source)
• GCP för dataintensiva svenska bolag: BigQuery + Vertex + Looker

Vill du ta det vidare?

Vill ni säkra era containrar från bygge till runtime hjälper jag er att lägga hela kedjan. Läs om min molninfrastruktur, se exempel i casebook, eller boka ett samtal.