Hoe je het ook wendt of keert, een Docker-omgeving voegt een extra laag toe aan je infrastructuur en dus ook aan je security. Hoe de beveiligingsmaatregelen eruit moeten zien, hangt af van wie je vraagt om dit in te richten. Vergelijk het met de beveiliging van je huis. Als je de brandweer uitnodigt, gaan ze je vertellen rookmelders op te hangen en alle ramen en deuren vrij te houden om snel het pand te kunnen verlaten. De volgende dag heb je de politie op bezoek en zij adviseren je om extra sloten aan te brengen en desnoods tralies. Daar zijn de spuitgasten dan vervolgens weer niet blij mee.
In mijn ogen hoeft de beveiliging van een container niet heel complex te worden. Een goed patchbeleid voor de processen die in je container draaien in combinatie met een solide beveiliging van je onderlaag, of dat nu een vps is of bare metal, brengen je een heel eind. Daarnaast vind ik deze tips heel nuttig (met dank aan Amir Jerbi):
- Gebruik de meest recente versie van het image;
- Gebruik waar mogelijk ‘trusted’ images;
- Scan de images op kwestbaarheden;
- Draai de containers binnen een vm als je twijfels hebt over de isolatie van de resources;
- Draai Docker Bench om je ervan te verzekeren dat je voldoet aan de security best practices voor de host.
Afweging
Het is geen geheim dat een container een veelzijdig ecosysteem biedt waarmee portabiliteit een nieuwe fase ingaat, hetgeen opweegt tegen eventueel aanvullende beveiligingsmaatregelen. De brede adoptie van het fenomeen blijkt uit het feit dat onze hosting-klanten al volledige otap-straten hebben ingericht met containers. Dat gebeurt overigens vaak in combinatie met virtual private servers (vps), wat de flexibiliteit en de beschikbaarheid van de toepassing verder verhoogt.
Dat Microsoft eerder dit jaar Docker wilde kopen (volgens anonieme bronnen op sdx Central) en het de containers nu aanbiedt binnen Windows Server 2016, vormt ook een teken aan de wand. Binnen Amazon Cloud Services is het sinds kort mogelijk om Docker Container Images te downloaden om in de eigen private cloud nieuwe AWS-diensten te ontwikkelen. En deze dan weer te uploaden voor gebruik in de publieke cloud, uiteraard.
Tegen het licht van microservices en DevOps bieden containers ook duidelijk een toegevoegde waarde. De accumulatie van service oriented architecture, virtualisatie, cloud computing en DevOps maakten al eerder de weg vrij om af te stappen van monolithisch applicatieontwerp. Containers vormen de ontbrekende schakel voor realisatie van microservices.
De huidige discussies over de veiligheid van containers zullen het dan ook niet winnen van het gemak en de voordelen van de technologie. Tien jaar geleden hadden we dezelfde gesprekken over virtualisatie en cloud. En we weten allemaal hoe dat afgelopen is...
Reacties
Van monolitische landschappen naar straten vol containers. Dockers die beveiliging bieden, maar zelf zelf weer kunnen draaien binnen untrusted images die steeds wijzigen, ergens gedownload, die je continu moet scannen op kwetsbaarheden..
Begin maar want veiligheidsdiscussies verliezen het altijd van het "gemak en de voordelen van de technologie". Bovendien ... Microsoft wilde het kopen.
Nu zijn we overtuigd.
Dit advies betekent vrij duidelijk dat "docker" geen complete "containerisatie"-oplossing is, zijn werk dus maar half doet: Je moet de container containeriseren wil'ie bruikbaar worden.
Datzelfde beeld zie je terug als je dieper de materie induikt en ziet dat docker zelf de mogelijkheid biedt om vanuit de container op de host administratieve dingen te doen en dat als feature ziet, of dat de docker software niet heel compatible met andere versies van zichzelf is, of dat de software aanneemt dat de docker images stateless zijn en dat je dus niet moet proberen er databases in te draaien, en zo verder.
Dat maakt de techniek toch een stuk beperkter dan wat je zou denken als je de terminologie zo bekijkt. Het is dan ook een erg leuk speeltje voor webdevs, maar toch wat minder nuttig voor algemeen productiegebruik. Ondanks dat het onderliggende idee niet onaardig is. Deze implementatie is gewoon niet af.
Eigenlijk wordt in de 2 reacties gelijk al de FUD aangetoond waar het stukje over begint.
@Dino: Je gooit een hoop terminologie door elkaar zonder je kennelijk te hebben ingelezen. In dit geval kan ik zeggen dat je incognito naam hier goed gekozen is. Volgens mij is ondertussen je token van je ring afgevallen en zou ik hem ergens op de grond gaan zoeken. :)
@Koos Werkeloos: Vms != Containers en Containers != Vms. In jouw geval denk ik dat beeldspraak en analogieën de klaarblijkelijke verwarring veroorzaakt hebben. Er is een container tov het besturingssysteem, maar er is geen container tov de buitenwereld.
Je kan ook geen Windows docker image op een Linux docker server draaien en vice versa ook niet.
@Dimitri: Ik denk dat veiligheid in discussies over de toepassingen van containers meer een dwaalspoor zijn. Netwerk en veiligheid moeten op orde zijn, voordat men überhaupt Docker achtige oplossingen wil overwegen.
Technicus, het maakt nauwlijks uit wat jij en ik ervan vinden. Het zijn de mensen die de beslissingen nemen om het al dan niet in te zetten waar het om gaat. En die gaan al te vaak op dat soort beeldspraak af. Je kan dat dus niet wegwimpelen, het heeft invloed.
Ik hoef niet eens gedetailleerde technische kennis van docker te hebben om dit te zien. Je kan zelfs niet eerlijk zeggen dat dit opmerken "FUD" betreft want het beslisproces, FWIW, werkt al te vaak echt zo. Dat betekent dat wil een technologie robuust zijn, dan moet de geassocieerde beeldspraak ook kloppen voor de uiteindelijke gebruikers. En dat is gewoon een zwak punt voor docker.
Dit nog naast dat docker wat zwakke punten kent ook binnen het model waarin het zichzelf definieert. Wat dus niet hetzelfde model is als het model dat de buitenwereld denkt dat docker naleeft.
Wat betreft beslissingen worden er inderdaad genoeg slechte genomen. Vaak wordt er te veel met 'hypes' meegelopen. Zo las ik laatst nog een leuk stuk over "Manie gedreven ontwikkelaars":
https://blog.daftcode.pl/hype-driven-development-3469fc2e9b22#.43j854k5f
Maar ook wordt er roofbouw gepleegd op de kennis van werknemers; geen budget voor opleiding, geen budget voor opleiding, geen budget voor opleiding, je kennis is te achterhaald; opzouten. En daar sta je dan, maar goed, je bent er zelf ook bij om dat eventueel nog te kunnen bijsturen zolang dat mogelijk is.
prachtig, "het maakt nauwelijks uit wat jij en ik er van vinden".
en "ik hoef niet eens gedailleerde technische kennis te hebben om dit te zien"
Op zichzelf al mooi maar samen briljant. Ongekende mogelijkheden.
Ja, nostalgie. Vroeger was alles zo mooi. Sitting on the dock of the bay.. Otis Redding.
"Het is geen geheim dat een container een veelzijdig ecosysteem biedt waarmee portabiliteit een nieuwe fase ingaat, hetgeen opweegt tegen eventueel aanvullende beveiligingsmaatregelen"
Ik moet toegeven. Die is ook fijn.
Allereerst iedereen bedankt voor de input. De dockerisatie-FUD roept veel herinneringen op aan servervirtualisatie. De discussie ging toen ook over de gevaren van virtualisatie, maar het gemak en het gezond verstand hebben uiteindelijk gewonnen.
Het is zeker waar dat het verminderen van administratieve handelingen en gebruikersgemak te vaak winnen van beveiliging. Natuurlijk zijn er dingen zoals Role-based access control om de beveiliging te verbeteren en te verfijnen, maar in een kleine organisatie is de applicatie-beheerder ook de OS-beheerder en de database-beheerder. Wanneer deze de veiligheid in zijn gemakshandelingen meeneemt levert dat alweer één winnaar meer op.
Overigens kan ik voor het gebruik van untrusted Docker images maar één ding zeggen... Eigen schuld dikke bult. Die verantwoordelijkheid ligt toch echt bij de beheerder die een illegale versie van ...zelf invullen... gebruikt. Geef niet direct de applicatielaag de beschuldigende vinger.
Tot slot zegt Technicus een waar woord als hij stelt: "Netwerk en veiligheid moeten op orde zijn, voordat men überhaupt Dockerachtige oplossingen wil overwegen."