Scharfer Wachhund
Fragt man Entwickler und Admins, was ihnen an Containern besonders gefällt, hört man regelmäßig dieselben Antworten: Flexibel seien Container, dynamisch, leichter zu verwalten – zumindest behaupten das Container-Fans. Tatsächlich verkörpern Container besonders gut die Ideen agiler Entwicklung, wofür symbolisch die Cloud-ready-Architektur mit ihren Mikrodiensten steht.
Was Entwickler und Admins in Sachen Flexibilität und Dynamik begeistert, treibt Compliance-Verantwortliche und CISOs jedoch regelmäßig Sorgenfalten auf die Stirn: Allzu groß ist bei manchem Entwickler oder Administrator die Versuchung, ein fertiges Image für Container aus dem Internet zu verwenden, es auf der eigenen Infrastruktur auszurollen und „works for me“ zu postulieren, ohne die Sicherheits- und Compliance-Implikationen des Vorgangs in Betracht zu ziehen. Wir sind bereits in der Vergangenheit auf diese Problematik eingegangen, doch es schadet nicht, zumindest einen weiteren kurzen Blick auf das Thema Container-Compliance zu werfen.
Compliance
Die Relevanz von Sicherheit und Compliance im Container-Kontext ist kaum zu überschätzen. Zwar laufen Container heute regelmäßig nicht mehr mit den Rechten des Systemadministrators Root – obwohl sie könnten, wenn es der Admin so will; auch das ist ein Compliance-Thema. Dennoch vermag ein ContainerAbbild aus dubioser Quelle mit eingebautem Bitcoin-Miner bereits die Stabilität eines Setups im Hinblick auf Netzwerk und Storage zu gefährden.
Als mindestens ebenso groß erweisen sich die Gefahren, die von Bastel-Images eigener Produktion ausgehen. „Works on my Macbook Air in VMware“ hat sich zum geflügelten Wort für Einfaltspinsel entwickelt, die ein Image lokal zusammenbasteln und es danach in der Welt verteilen, ohne die Quellen oder eine nachvollziehbare Liste der Arbeitsschritte mitzugeben. Dem Administrator, der ein solches Abbild nutzt, fliegt es spätestens beim ersten Security-Check um die Ohren: Findet sich
