Das Bild im Titel habt ihr bestimmt schon mal in dieser oder ähnlicher Form gesehen. Gefühlt bei 90% aller Artikel, in denen es um Container Plattformen geht. Obwohl diese Art Bild bereits «overused» ist, möchte ich es trotzdem auch hier verwenden. In diesem Artikel geht es um Containerized Platforms, genauer um Docker, Kubernetes und Openshift.

Beim Begriff «Container» denke ich zwar immer als allererstes an die alten, rostigen, schweren Eisenklötze die auf riesigen Schiffen über die Weltmeere transportiert werden. Aber diese haben – abgesehen vom Begriff – nicht viel mit der heutigen Thematik der Container Technologie in der IT zu tun. Viele Container passen auf ein Schiff, aber wie unterschiedet sich das jetzt von einer anderen Virtualisierungsplattform wie beispielsweise VMWare ESX? Auch da passen mehrere VMs auf einen ESX, wofür dann Container?


Woher der Hype kommt

Das Wort «Agile» (Sprich: áʤɑjl) dürfte euch bekannt vorkommen. Dahinter verbergen sich einige agile Softwareentwicklungsmethoden, welche alle als eher Jung bezeichnet werden dürfen. Der Wikipedia Artikel zu agiler Softwareentwicklung geht zwar bis 2005 zurück, so wirklich Bekanntheit erlangt, hat dies jedoch erst nach 2010, ich würde es auch wagen zu sagen erst nach 2015 ist dieses Thema in den Schweizer Grossfirmen (Banken, Versicherungen etc.)  richtig bekannt geworden und hat mit dem Release von Docker die Runde gemacht. Dadurch entstand dann auch ein Hype – durch das «Die haben das, dann wollen wir es auch haben». Sobald mal einer damit angefangen hat, kam das relativ schnell bei vielen Unternehmen zum Einsatz. Ich war in dieser Zeit des Hypes selbst im Bankensektor tätig und man hat den Hype deutlich wahrgenommen. Jeder wollte Container haben und agil sein, weil die anderen das auch machen. Alle wollten zum Tisch mit den coolen Kids sitzen.

So hat Docker als Markführer relativ schnell den Weg in die Unternehmen gefunden.

Was man von agilen Methoden hält, sei jedem selbst überlassen. Viele sind begeistert davon, ich habe in der Vergangenheit aber auch schon einiges an Kritik vernehmen können, wenn sich nicht genau an die Methoden gehalten wird, kann das Entwickeln von Software chaotisch werden indem jeder einfach mal macht. Denn «wir sind ja agil». Aber agil sein heisst nicht im Freestyle die Software zu entwickeln.

Die negativen Meinung sind auch zurückzuführen auf den Hype rund um die Begrifflichkeit des «agil seins». Selber habe ich zu wenig damit gearbeitet, um mir ein abschliessendes Urteil erlauben zu wollen.


Entwicklung der Container

Es ist indes nicht besonders überraschend wo das Konzept der Containerisierung auf Linux entwickelt wurde. Bei der Firma mit den 6 farbigen Buchstaben, mit Hauptsitz im sonnigen Kalifornien, wurde schon so einiges für die IT entwickelt. Gemeint ist Google.

Google braucht mit all Ihren Services die sie anbieten, eine ordentliche Menge an Ressourcen. Früher wurde alles klassisch virtualisiert wie wir es kennen: Host, virtuelle Maschine und darauf ein Betriebssystem mit der Applikation. Dies braucht jedoch für jede Applikation die Ressourcen eines ganzen Betriebssystemes, da selten mehrere Applikationen auf einem System laufen und sich so die Ressourcenteilung sehr schwierig gestaltet.

Paul Menage und Rohit Seth von Google haben sich diesem Problem angenommen und unter dem Projektnamen «process containers» bei Google ab 2006 begonnen die heutige Grundlage für Container auf Linux zu entwickeln. Ihre Arbeit war der Beginn eines Linux Kernel Features namens Control Groups oder cgroups. Mit cgroup lassen sich die Ressourcen wie CPU, RAM oder I/O auf einzelne Prozesse oder Gruppen von Prozessen binden. Dies sollte die Grundlage der Cloud-Computing-Revolution legen: die Containerisierung.


Funktion

Container sind eine Abstraktion auf dem App-Layer, die Code und Abhängigkeiten zusammenfassen. Mehrere Container können auf derselben Maschine laufen und den Betriebssystem-Kernel mit anderen Containern teilen, die jeweils als isolierte Prozesse in deren Namespaces ausgeführt werden. Da Container kein vollwertiges Betriebssystem haben, haben sie weniger Overhead und benötigen weniger Platz als VMs.

Dabei ist die Grundidee des Containers nichts Neues, vielleicht mag sich ja noch der eine oder andere an die alten Solaris Kisten erinnern? Diese stabil gebauten Teile aus Alu? Auch da kannte man schon Container und Nodes, so fortgeschritten wie heute war das damals aber noch nicht.

Im Gegensatz zu virtuellen Maschinen auf einer Host Plattform, setzt Docker eine Ebene höher an. Es gibt nur ein Host OS, auf dessen Kernel die Applikationen im Container zugreifen. Dies macht das Deployment der Container extrem schnell und einfach.


Container in der Softwareentwicklung

Die Softwareentwicklung profitiert von der effizienten Arbeit mit Containern. Ein Container wird innerhalb sekundenschnelle deployed, kann kurz getestet werden und danach wieder entfernt. Darauf folgend wird der Code der Applikation angepasst und der Container erneut deployed und getestet. So ist stets eine Versionierung vorhanden. Hat ein Container mal mit allen Komponenten zuverlässig funktioniert, kann dieser als funktionstüchtig abgelegt werden und bleibt damit als Backup unveränderbar stehen. Dieser Container kann immer wieder als Basis benutzt werden.


Wie stehts um die Sicherheit?

Die Sicherheit von der bekanntesten Container-Virtualisierung «Docker», wird häufig kritisiert. Aber hier gilt das gleiche wie auch in einer klassischen Installation, es hängt immer von er Sicherheit des Hostsystems ab. Passendes Beispiel ist SElinux, dies wird gerne deaktiviert da der Verwaltungsaufwand immens ist.

Obwohl die Sicherheit einer Container-Umgebung als vergleichbar mit deren einer klassischen Virtualisierung bezeichnet wird, ist auch dies zu hinterfragen. Gerade eben weil Docker eine Ebene höher ansetzt, sind die Ressourcen nicht so hart getrennt. Stichwort «Buffer overflow», mit dem ich in Bereiche gelange, in welche ich eigentlich nicht hingelangen dürfte. Bei einem klassischen Hypervisor setzt die Virtualisierung eine Ebene tiefer an, was diese Art von Exploit unmöglich macht.

Unter anderem deshalb gilt die Devise: Die Isolation, wenn mehrere Container auf einem gemeinsamen Host ausgeführt werden können, ist nur so gut wie die Fähigkeit des Kernels, eine mandantenfähige Isolierung zwischen Containern und dem zugrundeliegenden Host-Betriebssystem bereitzustellen.

Dazu gehören unter anderem die Namespaces des Linux Kernels, SELinux und weitere Security Features der gewählten Linux Distribution und die Sicherheit der Distribution selbst. Das bedeutet letztendlich, dass ein Container nur so sicher sein kann wie der Kernel des Hosts auf dem er läuft. Was im Umkehrschluss keineswegs heisst, dass der Container «immer» so sicher ist wie der Host darunter. Jeder Container muss bei einer Schwachstelle gepatched werden, ansonsten bleibt der Container für sich angreifbar. Durch Schwachstellen wie Spectre oder Meltdown kann sich dies im Worst Case auch auf das ganze System ausweiten.

Der grösste Punkt zu Sorge bereitet mir aktuell, dass wir immer nur mit einem Kernel unterwegs sind und wir lediglich durch die verschiedenen Namespaces von anderen Systemen getrennt sind. Hat der Kernel eine Lücke, so kann es passieren, dass dadurch auf das Hostsystem ausgebrochen werden kann und so Code auf dem Hostsystem ausgeführt werden kann.

Ein Risikopotential ergibt sich auch, wenn das Hostsystem nicht korrekt konfiguriert ist und – sagen wir mal rein hypothetisch – die Docker API öffentlich zugänglich ist. Wer würde denn sowas tun?

Da war mal was vor 2 Jahren.

Genau das!

Es war der Fall Mitte 2017, wo ein offener Port für die Docker API es einem Angreifer erlaubte ein Docker Image zu deployen. Dieses Image hatte einen Miner für die Kryptowährung Monero drin und schürfte damit die Währung mit der CPU Leistung anderer. Durch die Isolierung von Containern, war es jedoch nicht ohne weiteres möglich auf das Hostsystem zuzugreifen, weshalb es beim Mining von Monero blieb. Bis auf die erhöhte Stromrechnung entstand somit kein Schaden. Es weckt allerdings trotzdem ein ungutes Gefühl.

Der Angriff ist, falls Interesse besteht, unter diesem Link genauer beschrieben:

https://kromtech.com/blog/security-center/cryptojacking-invades-cloud-how-modern-containerization-trend-is-exploited-by-attackers


Container Orchestrierung mit Openshift

Sobald sich mehrere Container in einer Systemlandschaft angesammelt haben, müssen diese auch verwaltet werden. Die Zahl geht da schnell mal in den 3-stelligen Bereich, die Übersicht zu behalten wird da immer schwieriger. Kubernetes ist dazu ein geeignetes (Open Source!) Projekt. Openshift ist das passende – auf Kubernetes aufbauende – Produkt, entwickelt von RedHat, für die Verwaltung einer Containerlandschaft. Es bietet im Gegensatz zu Kubernetes bereits viele vollständig entwickelte Komponenten wie eine Continuous Integration/Continous Delivery oder Backup und Security Features. OpenShift wurde bereits mit dem Enterprise Gedanken entwickelt und ist daher standardmässig mehr eingeschränkt. So lassen sich darauf beispielsweise keine Container, die unter root laufen, deployen und es läuft nur unter RedHat/CentOS.


Fazit

Die ganze Geschichte mit den Containern ist also – abhängig von der Tätigkeit eines Unternehmens – bereits weit verbreitet. Wo bereits RedHat eingesetzt wird, ist mindestens schon ein POC für Docker & Openshift am Laufen. RedHat selbst hat die Verbreitung von Openshift schon selbst gespürt, die Kurse und Zertifizierungen dazu sind überdurchschnittlich gut besucht.

Obwohl es anfangs einen Hype um die Container und Docker gab und man in teils Sitzungen mit den Schlagwörtern rund um Container eine ganze Bullshit-Bingo Karte ausfüllen konnte, so sehe ich die Technologie als positive Entwicklung. Die Softwareentwicklung profitiert enorm von der gesteigerten Agilität und kann in Zusammenarbeit mit Methoden wie SCRUM die Effizienz deutlich steigern. Oder wie seht ihr das? Lasst mich wissen was ihr dazu denkt.

«Docker ist praktisch und kann viel unnötige Arbeit vermeiden, aber die Bequemlichkeit darf nicht zu leichtsinnigem Handeln führen.» – Tim Berghoff, G DATA Security Evangelist


Links

Bei AVANTEC beschäftigen wir uns im Rahmen von Cloud Security mit Container Security: www.avantec.ch/themen/cloud-security/