Essential Guide

Linux-Container: Grundlagen, Risiken und Anwendungsfälle der Container-Virtualisierung

Eine umfassende Auswahl von Artikeln, Videos und mehr, die von unseren Redakteuren gewählt wurden.

Red Hat: Sicherheitsbedenken sind kein Grund für den Docker-Verzicht

Im Zusammenhang mit Docker wird oft die mangelnde Sicherheit kritisiert. Für Lars Herrmann von Red Hat ist dies aber kein Grund für den Verzicht.

Die Container-Virtualisierung, vor allem mit Docker, gehört zu den großen IT-Trends des Jahres 2015. Wie andere...

große Softwareanbieter baut daher auch Red Hat sein Container- und Docker-Portfolio kontinuierlich weiter aus. Im Interview erklärt Lars Herrmann, Senior Director of Product and Business Strategy bei Red Hat, wie sein Unternehmen den großen Sicherheitsbedenken im Umgang mit Docker-Containern begegnet.

Herr Herrmann, lassen Sie uns bei einer grundlegenden Frage beginnen: Docker wird oft wegen der mangelnden Sicherheit kritisiert. Würden sie vom Einsatz in Produktivumgebungen abraten?

Lars Herrmann: Ich würde diese Frage zunächst einmal diplomatisch so beantworten: Die Sicherheit eines Systems liegt in den Händen des Betreibers. Man kann eine Container-Infrastruktur ähnlich sicher machen wie eine traditionelle Infrastruktur. Man kann aber natürlich auch jede Menge Fehler machen – wie in jeder traditionellen Umgebung auch.

Die Absicherung einer Container-Infrastruktur muss auf die richtige Art und Weise erfolgen, deswegen hat Red Hat in die Container-Zertifizierung Red Hat Container Registry sowie in verschiedene Plattform-Tools investiert, um dies einfacher möglich zu machen. Ich denke also nicht, dass Sicherheitsbedenken derzeit einen Grund darstellen, Linux- bzw. Docker-Container nicht einzusetzen.

Woran liegt es eigentlich, dass bei Docker-Containern sofort die Sicherheitsfrage aufkommt?

Herrmann: Tatsächlich ist die Sicherheit von Docker-Umgebungen eine der häufigsten Fragen im Gespräch mit Kunden. Die Sensibilität im Markt ist also definitiv größer, als noch vor ein paar Jahren. Gleichzeitig gibt es aber oft auch ein falsches Bild davon, was Container eigentlich sind. Es ist etwas irreführend zu denken, das Betriebssystem liege dabei unterhalb des Containers – das ist nur die halbe Wahrheit.

Lars Herrmann,
Senior Director of Product
and Business Strategy,
Red Hat

Treffender beschreibt es die Aussage, dass das Betriebssystem in einer Container-Architektur an zwei Stellen lebt. Einmal aber durchaus unterhalb des Containers als Infrastruktur, die den Container hostet. Hier ist das Thema Sicherheit tatsächlich äußerst imminent und wichtig, weil Container per Definition ja in einer Multi-Tenant-Umgebung laufen. Es laufen also mehrere Container zusammen auf einer Maschine, was in der Tat eine Reihe von Sicherheitsfragen aufwirft, etwa in wie weit zum Beispiel jeder Container auf der Plattformebene voneinander isoliert ist und wie leicht schädliche Container die gesamte Plattform kompromittieren könnten.

Die Antwort auf diese Sicherheitsbedenken haben wir im Grunde bereits 2014 mit der allgemeinen Verfügbarkeit von RHEL 7 gegeben, indem SELinux in den Container Host Support integriert wurde. Das schafft im Betriebssystem eine sogenannte Hardware Mandatory Access Policy Enforcement Engine, mit der tatsächlich jeder Container über ein hartes Policy-Enforcement von anderen Containern, aber auch vom Host selbst, isoliert ist.

Im März 2015 haben wir jetzt die neuen Super Privileged Container vorgestellt, mit denen nun auch Systemdienste als Container betrieben werden können. Durch die graduelle Öffnung der Sicherheitsrichtlinien erhalten Container so Zugriffsrechte auf den darunterliegenden Host, den der Container durch das Policy-Enforcement normalerweise ja nicht hat. So wird es möglich, auch Systemdienste wie ein Backup oder einen Monitoring-Agent als Container auszuführen, der einen privilegierten Zugang zum Host hat.

Nun hört die Sicherheit bei der Plattform aber ja nicht auf, oder?

Herrmann: Das ist richtig und für die Enterprise-IT ist die Anwendungsebene wahrscheinlich auch viel entscheidender. Die Sicherheit einer Applikation definiert sich über den Container selbst. Die Frage muss hier also lauten: Was genau befindet sich im Container? Im Container ist ja nicht nur die Applikation, sondern auch das Betriebssystem minus Kernel und die Laufzeitumgebung der Applikation. Im Falle einer PHP-Webanwendung beispielsweise Apache, PHP, diverse Security-Libraries wie OpenSSL – und alle diese Dinge leben innerhalb des Containers.

Auf Applikationsebene begegnen wir Sicherheitsbedenken auf zwei Ebenen: Erstens stellen wir unsere Produkte selbst in Form von Containern bereit. Diese Base Images gibt es zum Beispiel von RHEL 6 oder RHEL 7 und wir arbeiten gerade daran, alle unsere Produkte von JBoss bis Storage als Container bereitzustellen. Diese können dann genutzt werden, um Applikationen zu containerisieren.

Zweitens ist für alle diese Produkte auch immer ein Security-Upgrade-Pfad verfügbar. Wenn also die nächste Sicherheitslücke im Stile eines Heartbleed oder Poodle gefunden wird, können die Container nach der Veröffentlichung eines Patches durch Red Hat einfach neu gebaut und aktualisiert werden.

Welche Rolle spielt die von Ihnen eingangs erwähnte Red Hat Container Registry bei all dem?

Herrmann: Die Container Registry antwortet im Grunde auf die Frage, wie Kunden von Softwareherstellern (Independent Software Vendor, ISV) Anwendungen in Form von Containern beziehen können, ohne sich damit Sicherheitsprobleme einzufangen. Die Container-Zertifizierung im Rahmen der Red Hat Container Registry bringt aus Kundensicht drei große Vorteile mit sich:

Sicherheits-bedenken stellen derzeit keinen Grund dar, Docker-Container nicht einzusetzen.

Erstens ist damit ein Support-Statement verbunden. Ein zertifizierter Container wird im Endkunden-Deployment von Red Hat als Plattformanbieter und vom ISV als Anwendungsanbieter unterstützt. 

Zweitens ist durch die Zertifizierung bekannt und definiert, was in dem Container drinsteckt. Hier wird also das Vertrauenslevel von RHEL aufrechterhalten: Wer heute RHEL als sicherem Betriebssystem vertraut, der kann auch diesen zertifizierten Containern vertrauen, weil hier das gleiche RHEL drin steckt.

Drittens schließlich handelt es sich dabei nicht um eine bloße Zertifizierung auf dem Papier, sondern um einen richtigen Zertifizierungsprozess mit harten Tests. ISVs lernen dabei, wie man mit einem Container Development Kit Container baut und reichen diese dann bei unserem Zertifizierungsservice ein, wo sie anschließend zum Beispiel auf die Verwendung von Best Practices getestet werden. Erst nach erfolgreichen Tests kann der Container dann über die Container Registry veröffentlicht werden. Alternativ kann der ISV den Container auch über eine eigene Instanz der Container Registry verfügbar machen, so dass er über einen Docker-Client beim Endkunden bezogen werden kann.

Vor allem der letzte Teil scheint Ähnlichkeiten zum Docker Hub zu haben. Wo sehen Sie zentrale Unterschiede?

Herrmann: Wir glauben nicht daran, dass es nur eine Bezugsquelle für Software geben sollte. Vor allem im Enterprise-Umfeld ist dies nicht praktikabel, hier muss es Wahlfreiheit geben. Diese Freiheit sollte zudem die Nutzung eigener On-Premise-Tools hinter der eigenen Firewall einschließen.

Gleichzeitig möchten aber auch die wenigsten ISVs von einer dritten Partei abhängig sein, wenn es darum geht, Kunden containerisierte Software bereitzustellen. Gerade große Unternehmen, das hat unser Early-Access-Programm gezeigt, wollen nicht vom Docker Hub abhängen, sondern lieber ihre eigene Infrastruktur aufbauen, um darauf aufbauende eigene Services zu integrieren.

Weitere Artikel zur Docker-Virtualisierung:

Trotz Hype: Manche Applikationen profitieren nicht von Docker

Ausblick auf den Markt für Container-Virtualisierung 2015

Container-Virtualisierung mit Docker, Kubernetes und GKE

Gleichzeitig sperren die meisten Enterprise-Umgebungen, die ein bisschen über die Sicherheit im Zusammenhang mit Docker nachdenken, den Docker Hub. Im Grunde kann hier nämlich jeder einen Account erstellen und ohne Kontrollinstanz Container einstellen. Wer im Docker Hub beispielsweise nach MongoDB sucht, der findet hunderte Images, da fällt es natürlich schwer herauszufinden, welches Image man nun braucht und was genau darin enthalten ist.

Docker bietet zwar auch gewissermaßen offizielle Images an und verlinkt von diesen aus auch auf GitHub, so dass man zumindest nachvollziehen kann, wie diese ursprünglich gebaut wurden. Aber was am Ende wirklich drinsteckt, wie sich der Container über die Zeit entwickelt haben und wer im Fall von Sicherheitslücken für Patches verantwortlich ist, das ist für die meisten Container im Docker Hub einfach undefiniert.

Für Enterprise-Umgebungen ist das nicht akzeptabel, hier braucht man einen kontrollierten Zugang mit einem gewissen Vertrauenslevel und vor allem garantiertem Support. Die Red Hat Container Registry soll ISVs genau so eine Plattform bieten.

Herr Herrmann, vielen Dank für das Gespräch.

Folgen Sie SearchDataCenter.de auch auf Twitter, Google+ und Facebook!

Artikel wurde zuletzt im Mai 2015 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Essential Guide

Linux-Container: Grundlagen, Risiken und Anwendungsfälle der Container-Virtualisierung

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchNetworking.de

SearchEnterpriseSoftware.de

Close