Irrglaube bei Containern

vPierre Automation, Cloud, Cloud Computing, DevOps, DevSecOps, Docker Leave a Comment

Es ist kein Geheimnis, dass Container schnell einer der heißesten neuen Trends der Computerbranche geworden sind. Aber genau wie Cloud Computing und zuvor die traditionelle Virtualisierung, beispielsweise durch VMware  werden Container dem Hype nicht in jeder Hinsicht gerecht. Zur effektiven Ausnutzung der Container Technologie wie bei Docker müssen Organisationen die Geschichte hinter den Container sowie ihre Grenzen verstehen und wo sie in die Landschaft eines Rechenzentrums neben virtuellen Maschinen hineinpassen.

shutterstock_239182291_Container

Irrglaube #1: Container sind Neu

Container Kapselung, wie wir sie heute verwenden, ist neu (aufgezeigt durch das Docker/OCI Abbildformat) genau wie das Konzept der Container Orchestrierung wie Kubernetes zur Skalierung von Arbeitslasten über Host Cluster. Aber die Idee, eine Instanz des Betriebssystems bei der Isolierung unterschiedlicher Teile eine Anwendung zu nutzen, ist es nicht. Von Unix Chroot über FreeBSD Jail bis zu Solaris Zones von Sun Microsystems, jetzt Oracle gab es seit einiger Zeit schon Lösungen zur Aufteilung und Zuordnung von Systemressourcen.

Ebenfalls wichtig ist der Hinweis, dass viele der Linux Containern innewohnenden Technologien (namespaces, cgroups, usw.) die Grundlage für viele PaaS-Angebote der ersten Generation waren. Neu ist die Möglichkeit, die Container Fähigkeiten von Linux auszunutzen, um eine sehr breite Vielfalt von Anwendungen zu betreiben und zu steuern, wobei diese von Cloud eigenen Microservices bis zu bestehenden traditionellen Anwendungen reichen.

Irrglaube #2: Container sind vollständig abgeschlossene Einheiten

Trotz ihres Namens sind Container nicht vollständig abgeschlossen. Das „Gast“-System jedes Containers verwendet dasselbe Host-Betriebssystem und seine Dienste. Das verringert den Overhead und verbessert die Leistung, kann aber potenzielle Probleme für Sicherheit oder Interoperabilität verursachen.

Irrglaube #3: Container können virtuelle Maschinen ersetzen

Container werden virtuelle Maschinen nicht en gros ersetzen, weil sie nicht exakt genauso wie virtuelle Maschinen funktionieren. Alle haben ihren Platz im Unternehmen und die Firmen müssen herausfinden, was für welche Arbeitslasten und Situationen sinnvoll ist. Kurz gesagt, bietet Virtualisierung eine Flexibilität durch die Abstraktion von der Hardware, während Container durch ihre Isolierung und das leichte Application Packaging für mehr Geschwindigkeit und Agilität sorgen.

Anstatt nun Container als Ersatz für virtuelle Maschinen zu betrachten, sollten Unternehmen diese Container als eine Ergänzung zu virtuellen Maschinen sehen – wobei Anforderungen von Infrastruktur und Arbeitslasten bestimmen, was wann zu verwenden ist.

Irrglaube #4: Container sind universell portierbar

Container hängen für ihre Funktion vom Kernel und den Diensten des Host Betriebssystems ab, wobei „abhängen“ ein operativer Begriff ist. Container müssen ebenso physische Hardware, Hypervisor, private und öffentliche Clouds und mehr überqueren. Damit Container wirklich portierbar sind, müssen Entwickler eine integrierte Plattform zur Anwendungsbereitstellung unterhalten, die auf offenen Standards basiert.

Wie bei so vielen Dingen sind Standards der Schlüssel – für das gesamte Ökosystem.

Irrglaube #5: Container sind von sich aus sicher

Der Einsatz von Containern im Unternehmen bietet viele Vorteile, aber diese Vorteile müssen gegenüber dem Risiko jedesmal abgewogen werden, das beim Einsatz der Technologie entstehen kann. Stellen Sie sich zwei physische Maschinen vor – Sie können diese im Netz voneinander isolieren. Falls eine ausfällt und/oder mit einem Virus infiziert wird, kann die andere Maschine ziemlich einfach geschützt werden. In einer Umgebung mit Containern wird andererseits der Betriebssystem-Kernel des Host-Systems von allen Containern genutzt. Dieser Art der gemeinsamen Nutzung birgt ein inhärentes Risiko.

Das Maß der vom Linux Kernel gebotenen Isolierung kombiniert die Prozess Isolierung mit Namensräumen, was sehr gut funktioniert, aber konstruktionsbedingt nicht alle möglichen Pfade schließt, so dass Schadcode ausbrechen und Zugriff auf den Host oder andere Container gewinnen kann. Deshalb bieten Technologien wie SELinux die nötige zusätzliche Schutzebene für Richtlinien- und Zugangsbeschränkung.

Am wichtigsten ist aber, was im Container läuft. Bewährte Methoden wie der Einsatz vertrauenswürdiger Komponenten aus vertrauenswürdigen Quellen ergänzt um Prüfmöglichkeiten für Unternehmensanwendungen im Sinne von „Vertrauen ist gut, Kontrolle ist besser“ gelten für Container gleichermaßen. Die unveränderliche Natur von Containers schafft eine Möglichkeit, Änderungen am Abbild selbst zu verwalten und nicht an der laufenden Instanz. So wird die Container Verteilungsarchitektur selbst, oft als verbündete Registries implementiert, ein wichtiges Element für die Verwaltung der Sicherheit und das Patchen von Containern.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.