Containers och säkerhet

Förarbetena till artikeln om Containers och säkerhet i Techworld resulterade i en längre text än som i slutänden rymdes i artikeln. Vårt bidrag i sin helhet följer här:

Containers och virtualiserade system ställer olika krav på arbetsprocessen och sättet att säkerhetspatcha. När vi har containrar och t.ex. upptäcker ett hål i crypto-algoritmen i java, så hjälper det inte att patcha java på servrarna/hostarna, utan vi behöver bygga och produktionssätta en ny release av alla containers som innehåller java.

Det här innebär att våra gamla rutiner för säkerhetspatchning, med separata flöden och rutiner för utveckling och drift, inte fungerar för containers i produktion, utan vi måste ha implementerat ett continuous delivery-flöde hela vägen ut i produktion.

En annan aspekt att ta hänsyn till är att kerneln är gemensam mellan olika container-instanser körande på samma server vilket kan underlätta attacker där man med hjälp av ett säkerhetshål i en container något lättare kan nå eller förändra information i en annan container, jämfört med om de var olika virtuella maskiner. Det är visserligen varken lätt hänt eller vanligt att det händer, men det kan hända. En säkerhetshöjande åtgärd är att separera de olika miljöerna från varandra, produktion, staging, test och utveckling, till exempel i olika kluster eller i olika grupper av klusternoder.

Man ska också undvika att blanda miljöer där man bygger containrar med annat, dvs pipelines ska köras på egna kluster, dels eftersom det är resurskrävande att bygga images och dels för att minska risken att en säkerhetsläcka i någon pipeline-container förgiftar alla images. Byggnoderna kan dessutom köras på transienta noder/kluster som skapas vid behov och som destrueras när de inte körs, till exempel på nätter helger eller kanske till och redan efter en liten stunds uppehåll.

Körmiljöer som Kubernetes, som har ett antal likformiga och anonyma noder, förenklar arbetet med att hålla själva körmiljöerna för containers uppdaterade eftersom det i princip bara består i att hålla master och slavnoder up-to-date, som är en smal och väldefinierat process, jämfört med bredden att patcha upp olika runtimes och bibliotek som varje individuellt produktionssystem beror av.

Att gå vidare från Containers till serverless och FaaS blir i detta sammanhang ett litet steg som dessutom går att ta i många ännu mindre steg, per applikation eller mikrotjänst, där tekniken passar in och löser reella problem, jämfört med det mycket stora steget att gå från virtualiserade system och separata drifts- och utvecklingsprocesser och organisationer till Continuous Delivery, containers och devops.

Det kommer förmodligen att ta mycket lång tid innan den sista Container-baserade applikationen ersatts av serverless, och containerbaserade lokala databaser och meddelandeservrar ersatts av motsvarande cloud-tjänster. Fram till dess måste man hålla containermiljön uppdaterad och vid liv, vilket innebär att den dominerande drivkraften mot serverless från Containers inte i första hand är minskad kostnad för administration av produktionsmiljön för containers, utan snarare att man vill uppnå modellen för uppskalning och debitering som serverless ger, tillsammans med arkitekturella aspekter som standardisering.

Säkerhetsmässigt ändras en hel del när man går över till serverless, både positiva och negativa saker. Det är svårt att just nu förutse vilken del, om någon, som kommer att dominera framöver.

Mikael Sennerholm
Daniel Marell
C.A.G Edge

IT Consultant at CAG Edge. Cloud and Continuous Delivery specialist, software developer and architect, Node.js, Java.

Publicerad i Cloud Computing, Continuous Delivery, DevOps, DOcker

Kategorier

LinkedIn Auto Publish Powered By : XYZScripts.com