Container Security in der Cloud

Tom Jan. 16, 2019
Container Security in der Cloud

Die Sicherheit von Daten und Infrastruktur ist zum grossen Teil handlungsabhängig, auch in der Cloud. Da Container ein anderes Sicherheitsmodell als traditionelle VMs benötigen, schauen wir uns hier einige Schlüsselbereiche an, welche die Sicherheit in der Systemarchitektur beeinflussen.

 

Betriebssysteme

Da Container die Laufzeit-Anforderungen einer Anwendung beinhalten, bleibt das Betriebssystem der Container-Plattform extrem schlank. Sogenannte Atomic Linux-Distributionen wenden dieses Prinzip an und nutzen ein Read-only Dateisystem, Transaktions-Updates und ein “git”-ähnliches OS-Tree-Modell, um Sicherheit und Skalierbarkeit bei möglichst wenig Angriffsfläche zu bieten. Das Modell des unveränderlichen OS-Tree-Filesystems ermöglicht es auch, wenn nötig direkt auf eine vorherige System-Version zurückzugehen. Dadurch sind Atomic-Systeme sehr gut für die Anwendung in grossformatigen Kubernetes-Distributionen geeignet, um das Gleichgewicht zwischen Nodes zu sichern. Google selbst hat für Container-Betriebssysteme einen anderen Ansatz: Ihr “Container Optimised OS” basiert auf Chromium, aber viele der Kernmerkmale sind gleich wie bei Atomic-Distributionen.

 

Container-Runtimes

Docker ist derzeit die meistgenutzte Anwendung der Container-Technologie, hat aber einen grossen Nachteil: Ein Daemon muss laufen, um die Container zu betreiben. Negativ ist dabei, dass alle Container zusammen mit dem Daemon gestoppt werden. Aber es gibt auch weniger offensichtliche Nachteile: So kann man Container nicht starten, bevor der Daemon-Prozess läuft. INIT-Container sind somit unmöglich. Da die Docker-Engine – und nicht die Docker-CLI – die Container startet, werden der Docker-CLI zugeordnete Cgroups nicht vom Container übernommen. Die Parent-PID der Container ist der Daemon, nicht die CLI.


Gut ist, dass jede Kubernetes-basierte Container Orchestration Plattform die Container Runtime Interface-Abstraktion enthält, sodass unterschiedliche Container-Laufzeiten möglich sind. Eine der bekanntesten Runtimes ist Googles Gvisor, das Sicherheit in ähnlicher Weise wie User Mode Linux behandelt. Gvisor agiert als Gast-Kernel und fängt Systemaufrufe ab und blockiert diese entweder, oder führt eine Userspace-Anwendung aus. Auch nennenswert: Frakti - es erlaubt die Nutzung von Kata-Containern, da es eine schlanke, vom darunterliegenden System ganz unabhängige VM um den Pod errichtet; und Virtlet - es ermöglicht das Einrichten ganzer VMs auf Kubernetes-Nodes. Natürlich gibt es bei jeder Lösung Abstriche bei Geschwindigkeit oder Benutzerkomfort, die man im Einzelfall betrachten muss.

 

Kubernetes API-Objekte

Wenn man Kubernetes für die Container-Orchestrierung nutzt, hat man die Option, sowohl Role Based Access Control (RBAC) als auch ResourceQuota und LimitRange API-Objekte  zu verwenden, um Sicherheit und Stabilität zu wahren.

Mit RBAC kann man definieren, welche Vorgänge (Verben) unterschiedliche Subjekte (Benutzer/Gruppen) auf Ressourcen (API-Objekten) im Cluster ausführen dürfen. Auch ist der Einsatz individueller Admission-Webhooks möglich, um so entweder zusätzliche Zugangsüberwachung zu bieten oder ankommende API-Anfragen zu mutieren. Durch ResourceQuotas und LimitRanges kann man die Menge an CPU und RAM definieren, die ein Namespace/Pod/Container benötigt oder verbrauchen darf, sodass man sicherstellt, dass alle Container die benötigten Ressourcen erhalten, ohne sie anderen wegzunehmen.

 

Fazit

Auch wenn die Fragen beim Container-Betrieb andere sind als bei traditionellen Servern, kann man in jeder Architekturebene sinnvolle Varianten wählen, um Sicherheit zu gewährleisten - unabhängig davon, ob man Container vor Ort oder in der Cloud betreibt. Und natürlich hängt die Sicherheit am stärksten vom Aufbau der Anwendung ab.

 

Möchten Sie mehr von uns lesen? 

Jetzt Updates vom Engineering Logbook abonnieren

 

Dieser Artikel erschien im  Netzwoche-Special «Cloud & Managed Services 2019»