Containerteknik blir allt mer självklar för utveckling och, framför allt, drift av applikationer. Det är framför allt containerplattformen Docker som kommer från Linuxvärlden som är populär. Men sättet att jobba sprider sig åt alla håll, inte minst på Windows.
Containrar ses dels som ett smidigt lättviktsalternativ till virtuella servrar, dels som ett helt nytt sätt att få till arkitektur. Det senare är ofta kopplat till att strukturera applikationer i form av mikrotjänster och hänger ihop med trender som devops och kontinuerliga leveranser.
Men hur är det med säkerheten?
Det dök upp en hel del farhågor när containertekniken slog igenom för några år sedan. De flesta av dessa har stillats, men nya har dykt upp.
Docker är egentligen inte ny teknik, men Dockermjukvaran är ett tämligen nytt gränssnitt mot gammal teknik. Och när ny mjukvara tas i drift visar det sig att det finns sårbara punkter som man inte tänkt på i förväg, inte minst vad gäller processer som inbegriper människor.
Läs också: Containrar för snabba ryck i Microsofts moln
Att det finns ett reellt behov av att säkra containrar visas bland annat av att det startas företag som är specialiserade på det. Ett exempel är israeliska Aqua Security Software som grundades 2015, som bland annat Microsoft investerat i. Andra startups som kan nämnas är Stackrox och Twistlock, som båda har uppbackning från stora företag.
Här berättar svenska experter om säkerhetsproblem med containrar som inte är uppenbara, men som måste åtgärdas för att få till säker it-drift.
– Man måste vara väldigt noggrann när man skapar containrar. Man ska aldrig låta dem ha rotåtkomst på de servrar som de körs på, om det inte är tvunget. Det slarvar många med, säger Magnus Bengtsson, plattformsingenjör på Expressen.
Om en container har rotåtkomst, alltså bred åtkomst till resurser på en server, kan skadlig kod som körs i den göra maximal skada, om den lyckas bryta sig ut ur containern. Det går att förhindra det med en enkel inställning, men det glöms ofta bort.
– En annan fara är att alla containrar på en dator kan kommunicera med varandra som standard, fortsätter Magnus Bengtsson.
Den möjligheten öppnar fler vägar för skadlig kod och åtkomst till tjänster som inte ska kunna nås. Det är återigen frågan om en relativt enkel inställning som ofta glöms bort.
På ett psykologiskt plan kan man spekulera i om sådana här missar beror på att det är så enkelt att handskas med containrar, jämfört med virtuella maskiner och fysiska servrar. Det kanske gör att man inte lägger så mycket tid på att kontrollera hur de skapas och körs, till exempel se till att de följer de säkerhetsregler som gäller för de applikationer och tjänster som körs i dem?
Det finns fler exempel på problem som beror på nya arbetssätt:
– Man glömmer ibland bort att containrarna körs på en server som också behöver patchas, berättar Johan Öbrink, digital strateg på konsultföretaget Iteam.
Ett annat problem är hur patchningen av alla komponenter i en container går till:
– Så länge man utvecklar en applikation och bygger nya versioner så kollas det automatiskt efter nya versioner av de komponenter som ingår i en container, vilket gör att man får patchning på köpet. När man går i produktion sker inte det, då måste man ha koll själv, förklarar Johan Öbrink.
Läs också: 9 trender som styr utveckling i höst
Ytterligare ett problem är att byggsystem laddar ner en ”grundcontainer” från något bibliotek när en ny version av en applikation byggs. Om grundcontainern är infekterad med skadlig kod ligger man risigt till.
Det finns möjliga lösningar på det här problemet, till exempel att utgå ifrån bibliotek med kontrollerade ”mallar” för containrar, vilket bland annat företaget Docker erbjuder. Man kan även administrera egna bibliotek, om full koll är ett krav.
Patchning är problematisk på flera sätt. Daniel Marell som är utvecklare och arkitekt på konsultföretaget CAG beskriver det så här:
– Om vi till exempel upptäcker ett hål i kryptoalgoritmen i Java så hjälper det inte att patcha Java på servrarna, utan vi behöver bygga och produktionssätta en ny version av alla containrar 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 containrar i produktion, utan vi måste ha ett flöde för kontinuerlig leverans hela vägen ut i produktion, säger Daniel Marell.
Man kan alltså inte välja att enbart använda containrar som ett enklare alternativ till virtuella maskiner och fysiska servrar. De ställer också krav på nya processer och arbetssätt.
Läs också: 5 skäl för utvecklare att älska containrar
Daniel Marell påtalar också att den ursprungliga tveksamheten kring containrar vad gäller säkerhet kvarstår: Alla containrar som körs på en fysisk server delar på samma operativsystemskärna. Det kan potentiellt underlätta attacker. Men han tycker att den säkerhetsbristen bör vägas mot de säkerhetsmässiga fördelar som ett automatiserat leveransflöde med containrar ger.
Det finns några olika slutsatser att dra av beskrivningarna ovan. Den första är att slarv är slarv, oberoende av teknisk plattform. Att det är enkelt att starta containrar innebär inte att man kan tänka mindre på att säkra inställningar för dem än för till exempel virtuella maskiner.
Den andra slutsatsen är att man måste se över processer för patchning av mjukvara när containrar används, eftersom komponenter hanteras på annorlunda sätt än för andra leveransmodeller för applikationer.
