Container-Sicherheit - Was sind Container?

Die meisten Unternehmen verwenden heutzutage Container. Sie sind eine Lösung für das Problem, wie eine Anwendung in jeder Umgebung zuverlässig ausgeführt werden kann, wenn sie bereitgestellt wird. Dabei kann es sich um die Entwicklung, die Produktion oder die Testumgebung handeln (Paul Rubens, 2017, ref.2). Sie erleichtern den Lebenszyklus der kontinuierlichen Entwicklung und Bereitstellung. Für die Sicherheit sind sie äußerst hilfreich, wenn es darum geht, das deterministische Verhalten von Anwendungen zu bewahren, wenn sie richtig eingesetzt werden. Lassen Sie uns deshalb mit den Grundlagen beginnen.

Container vs. Virtuelle Maschinen

Bevor Container erfunden wurden, wurden die meisten Anwendungen auf VMs gehostet. Eine VM ist die Virtualisierung/Emulation eines physischen Computers mit Betriebssystem, CPU, Speicher, Storage und Netzwerkschnittstelle, die virtuell bereitgestellt werden. Die Hypervisor-Software trennt die Ressourcen der virtuellen Maschine von der Host-Hardware. Mit ihr können mehrere VMs auf demselben Host laufen. Mit VMs ist es möglich geworden, dieselbe Anwendung in mehreren Umgebungen (VMs) auf demselben Host oder auf verschiedenen Hosts auszuführen. Das spart Kosten im Vergleich zu früher, als eine Anwendung auf einem einzigen Server ausgeführt wurde.

Im Vergleich zu Containern sind VMs langsamer beim Hochfahren und weniger portabel. Außerdem benötigen sie mehr Ressourcen, da sie ein vollständiges Gastbetriebssystem benötigen.

Containerisierung

Die Containerisierung ist eine Technologie, die es ermöglicht, den Anwendungscode, seine Abhängigkeiten und Konfigurationen in ein Container-Image zu packen. Ein laufendes Image ist ein Container. Der Ausgangspunkt für die Erstellung eines benutzerdefinierten Images ist ein Basis-Image (wie Alpine Linux), das in der Regel von Anbietern oder Communities erstellt und in eine Image-Registry hochgeladen wird (ein Repository, das Container-Images speichert, z.B. Docker Hub ).

Container-Laufzeiten

Container laufen mit einer Container-Laufzeitumgebung . Es handelt sich um eine Softwarekomponente, die Container auf einem Host-Betriebssystem ausführen kann. Einige Container-Laufzeiten sind mit Linux und Windows kompatibel, wodurch die Container plattformübergreifend sind. Container isolieren die Software von der Umgebung und sorgen dafür, dass sie trotz der Unterschiede in der Umgebung, z.B. Staging und Produktion, identisch ausgeführt wird.

Die beliebteste Container-Technologie ist Docker. Sie wurde für die meisten Menschen zum Synonym für Container. Das Ziel der Container-Laufzeit ist die Virtualisierung von Systemressourcen wie dem Dateisystem oder dem Netzwerk. Dies geschieht über Linux-Namensräume und die Begrenzung von Ressourcen wie CPU und Speicher erfolgt über cgroups (Ian Lewis, 2017, ref.1).

Es gibt zwei Arten von Container-Laufzeiten, Low-Level und High-Level. Die Low-Level-Container-Laufzeit ist für die Ausführung des Containers verantwortlich. Sie richtet die Namespaces und cgroups für die Container ein. Die High-Level-Laufzeitumgebung ist für die Verwaltung der Container zuständig. Sie erstellt das Container-Image, holt es aus einer Registrierung und übergibt es an die Low-Level-Laufzeitumgebung.

Die Docker-Engine ist eine leichtgewichtige Open-Source-Containerisierungstechnologie, die High-Level- und Low-Level-Laufzeiten implementiert. Sie ist mit einem Workflow für die Erstellung und Containerisierung von Anwendungen kombiniert. Sie kann auf einer Vielzahl von Systemen installiert werden . Betriebssysteme .

Container Geschichte

Die Container-Technologie wurde vor über zehn Jahren für Linux in Form von LXC entwickelt. Andere Anbieter bieten ihre Systemvirtualisierung an, z.B. Solaris Containers, FreeBSD Jails und AIX Workload Partitions (Paul Rubens, 2017, ref.2).

Im Jahr 2015 hat ein Unternehmen namens CoreOS seine Version von Containern, die möglicherweise die Container-Industrie fragmentieren könnte. Sie waren der Konkurrent von Docker. Aber das Laufzeitprojekt rocket (rkt) von CoreOS wurde im Februar 2020 eingestellt. Die rkt-Laufzeitumgebung bleibt ein wichtiger Teil der Geschichte der Containertechnologie (Iucab, 2018, Ref. 3).

Im selben Jahr, 2015, wurde ein Projekt der Linux Foundation namens Open Container Project, später umbenannt in Open Container Initiative (OCI), ins Leben gerufen, um Industriestandards für das Containerformat und die Container-Laufzeitsoftware für jede Plattform zu definieren. Dieses Projekt wird von Unternehmen wie VMware, AWS, Google, Microsoft, Red Hat, Oracle, IBM, HP, Twitter, Docker und CoreOS unterstützt. Das macht es zu einer beachtlichen Autorität bei der Definition von Standards für die Container-Technologie (Paul Rubens, 2017, ref.2).

Der Ausgangspunkt für die OCI-Standards war Docker, das 5 Prozent seiner Codebasis zur Verfügung stellte, um dieses Projekt zu starten. Dieses Projekt veranlasste die Unternehmen, sich auf die Entwicklung von Container-Orchestrierungs-Tools für die bestehende Container-Technologie zu konzentrieren, anstatt konkurrierende Container-Technologien zu entwickeln. Derzeit konkurrieren mehrere Unternehmen bei der Entwicklung von Orchestrierungs-Tools miteinander. Sie respektieren jedoch die OCI-Standards, was bedeutet, dass ein Container auf jedem Orchestrierungswerkzeug identisch läuft (Paul Rubens, 2017, ref.2).

Container Vorteile

• Plattformübergreifende Kompatibilität;
• Verwenden Sie im Vergleich zu VMs weniger Ressourcen (z.B. Speicher, Rechenleistung);
• Booten Sie schneller mit der Anwendung als mit VMs;
• Sie können schnell vernichtet werden, wodurch Ressourcen für ihren Wirt frei werden;
• Sie ermöglichen die Modularität. Anstatt eine gesamte Anwendung in einem Container auszuführen, kann sie in mehrere Container aufgeteilt werden. Eine Webanwendung kann in einen Datenbank-, Front-End- und Back-End-Container aufgeteilt werden. Die Anwendung wird in Microservices aufgeteilt. Es ist einfacher, die Anwendung zu ändern, da nur die aktualisierte Komponente neu erstellt werden muss.

Container Nachteile

• Wenn der Host-Kernel verwundbar ist, dann sind alle Container verwundbar;
• Manche Legacy-Software lässt sich nicht in Containern ausführen. Sie kann nur auf VMs ausgeführt werden;
• Container bieten im Vergleich zu VMs weniger Isolation, da sie den Host-Kernel gemeinsam nutzen.

Container Orchestrator

Container werden normalerweise in einer Container-Orchestrierungsumgebung ausgeführt. Ihr Ziel ist es, die Bereitstellung, Skalierbarkeit, Überwachung und Verwaltung von Containern zu automatisieren. Orchestrierung ist für Einzelpersonen und Unternehmen, die mehrere Container gleichzeitig betreiben, unverzichtbar, da es fast unmöglich ist, diese manuell zu verwalten. Es gibt viele Anbieter von Tools für die Container-Orchestrierung, aber das beliebteste ist Kubernetes. Es handelt sich um ein Open-Source-Tool, das ursprünglich von Google für die Verwaltung seiner Infrastruktur entwickelt wurde. Jetzt wird es von der Stiftung für Cloud Native Computing .

In der Abbildung unten sehen Sie eine detailliertere Architektur eines Kubernetes-Clusters und wie die einzelnen Komponenten miteinander kommunizieren:

Quelle: redmondmag.com

Ein Kubernetes-Cluster besteht aus einem Master-Knoten und mehreren Worker-Knoten, auf denen alle Workloads gehostet werden. Der Masterknoten dient als Verwaltungsknoten. Er kann auch Workloads hosten, aber das gilt als schlechte Praxis. Wenn die Arbeitslast auf dem Master-Knoten kompromittiert wird, ist wahrscheinlich der gesamte Cluster kompromittiert.

Kubernetes Komponenten

• Kubectl ist ein Bash-Tool, das für die Kommunikation mit dem API-Server von Kubernetes und die Verwaltung des Clusters verwendet wird;

• API Server ist ein RESTful Webserver, der die Verwaltung des gesamten Clusters übernimmt. Außerdem sammelt er die Anfragen vom Client, die authentifiziert, autorisiert, verarbeitet und dann im ETCD zur weiteren Verarbeitung und Nutzung gespeichert werden;

• Etcd ist ein Key-Value-Speicher, der die sensibelsten Daten innerhalb des Clusters speichert. Der Zugriff darauf sollte nur auf so wenige Benutzer wie möglich beschränkt werden. Voller Zugriff auf ETCD gilt als Root-Zugriff auf den Cluster;

• Controller Manager ist ein Daemon, der auf bestimmte Aktualisierungen im API Server hört und Controller innerhalb des Clusters ausführt, die ihren Zustand konsistent halten;

• Der Scheduler ist eine Komponente, die auf Anfragen zur Pod-Erstellung auf dem API-Server "hört", die Knotenliste auf mögliche Ressourcenzuweisung überprüft und die Anfrage an Kubelet sendet;

• Kubelet ist eine Arbeitskomponente, die die Pod-Erstellung, die Protokollierung und den Status verwaltet. Sie ist auch der Endpunkt, den der API-Server aufruft, um den Status und die Protokolle der Pods abzurufen;

• Kube-proxy ist eine Komponente, die zusammen mit dem Container Networking Interface (CNI) dafür sorgt, dass alle Container, Pods und Knoten miteinander kommunizieren können, als ob sie sich in einem einzigen Netzwerk befänden;

• Docker wird in den obigen Abschnitten erklärt;

• Ein Pod ist eine Gruppe von einem oder mehreren Containern, die sich denselben Speicher und dasselbe Netzwerk teilen;

• Der Container wird in den obigen Abschnitten erklärt.

Referenzen

1. Ian Lewis (06.12.2017), "Container-Laufzeiten Teil 1: Eine Einführung in Container-Laufzeiten",

   Container-Laufzeiten Teil 1: Eine Einführung in Container-Laufzeiten - Ian Lewis

2. Paul Rubens (27.06.2017), "Was sind Container und warum brauchen Sie sie?",

   Was sind Container und warum brauchen Sie sie?

3. lucab (16.04.2018), "Releases rkt",

   Veröffentlichungen - rkt/rkt