Aus Kubernetes wird Container as a Service

Knackpunkt Sicherheit

von - 08.01.2021
Trotz aller Vorteile - Unternehmen treibt beim Einsatz von Containern vor allem das Thema Sicherheit um. Laut der eingangs erwähnten Studie gaben 38 Prozent der IT-Verantwortlichen an, dass Sicherheitsbedenken ein Grund dafür sind, keine Container im Unternehmen einzusetzen. Und die Bedenken haben auch ihre Berechtigung: Der sichere Betrieb von Container-Workloads ist nicht trivial.
In den Anfangszeiten der Containerisierung liefen diese oft mit Root-Rechten. Dadurch konnte ein Angreifer, der die Sicherheitsmechanismen des Host-Betriebssystems überwand und Zugriff auf die Hardware hatte, gegebenenfalls auch auf die Container zugreifen. Heutzutage liegen laut Marc Kleff von NetApp die Hürden hingegen deutlich höher, da viele Lösungen auf den Root-Zugriff verzichten - „System und Container bleiben getrennt, obwohl diese Trennung nicht so weit wie bei einer Server-Virtualisierung reicht.“ Im Allgemeinen gilt, so Kleff: „Wo aus Sicherheitsgründen eine dedizierte Hardware-Trennung eingeführt wurde, wird man diese jetzt nicht durch einen Mischbetrieb mehrerer Container auf einem Host ersetzen.“
Dass die Sicherheit ein großes Thema ist, das noch längst nicht gelöst ist, betont auch Wolfgang Kurz von Indevis. Ein gängiges Problem sei etwa der Übergriff in Speicherbereiche des Nachbarn. Das gelte unter anderem auch für Teile des Betriebs­systems. „Durch den Einsatz von Containern wird es also keinesfalls sicherer, zumal viele Technologien zum Schutz von Containern noch in den Kinderschuhen stecken.“ Auch wenn alle etablierten Firmen Angebote zum Schutz von Container-Lösungen im Angebot hätten, so seien das oft aus der Virtual-Machine-Welt übertragene Ansätze, die nur teilweise funktionierten. Daher seine Warnung: „Viele Online-Repositories, von denen viele Anwender ihre Container beziehen, sind veraltet und haben eklatante bekannte Sicherheitslücken. Hier muss man im Grunde täglich die Container neu bauen. Solch eine Build Pipeline hat aber nicht jeder im Einsatz, auch wenn sie notwendig wäre.“ 
Marc Kleff
Marc Kleff
Director Solutions Engineering bei NetApp
www.netapp.com/de
Foto: NetApp
„Kubernetes hat sich erfolgreich etabliert. Die Lösung ist komplex, bietet aber auch einen sehr großen Mehrwert und eine hohe Entwicklungsgeschwindigkeit. Da viele Alternativen nicht mithalten konnten, wurden sie bereits von Kubernetes verdrängt.“
Vor allem im DevOps-Bereich ist die Sicherheit von Containern ein Thema: Das Operations-Teams hat die Aufgabe, Sicherheitslücken in Produktivumgebungen zu finden. Dabei ist es in der Praxis aber häufig schon schwierig, Komponenten und Abhängigkeiten in Container-Images zu überblicken. 
„Der Überblick über Komponenten und Abhängigkeiten in Container-Images gelingt dort, wo die enge Verbindung von Dev und Ops in einer DevOps-Kultur gelebt wird“, ­betont Marc Kleff. Die Operations-Teams dürften nicht nur auf das Resultat blicken, „sondern müssen bereits im Code-­Repository und beim Quellcode ansetzen. Hier werden die Abhängigkeiten und Komponenten definiert. Dafür können Unternehmen auf fertige Lösungen zurückgreifen.“ GitHub werde beispielsweise automatisch auf Sicherheitslücken in solchen Abhängigkeiten gescannt und der Anwender benachrichtigt.
Von der Cloud Native Computing Foundation - einem ­Projekt der Linux Foundation, um Cloud-Computing, Microservices und Containervirtualisierung zu fördern - gibt es ­eine Reihe von empfohlenen Vorgehensweisen, an denen sich Unternehmen orientieren können. Sinnvoll ist es zum Beispiel, jeweils aktuelle Software-Stände der Container-­Engine und des Orchestrierungssystems einzusetzen oder sensible Work-loads voneinander zu separieren. Das lässt sich umsetzen, indem man etwa Applikationen in getrennten Clustern betreibt.
Bei der Verwendung von Container-Basis-Images sollte man darauf achten, aus welcher Quelle diese stammen. Hier ist es unter Umständen angebracht, entweder einen Anwendungskatalog mit signierten Basis-Images zu verwenden oder auch Container-Images in regelmäßigen Abständen neu zu erstellen. Weitere wichtige Aspekte für einen sicheren Betrieb von Container-Workloads sind das Netzwerk-Design und der Einsatz von Monitoring- und Logging-Systemen.

Patchen

Container haben auch Auswirkungen auf den Patch-Prozess. So sind Container  typischerweise „immutable“. Das bedeutet: Sie werden nicht kontinuierlich gepflegt, sondern einfach durch neue Container ersetzt. Das erfordert in vielen Fällen neue Software-Build- und -Release-Routinen. „Das bringt bei komplexen Systemen - insbesondere in monolithischen Strukturen - viel Aufwand mit sich, dessen Nutzen sich erst später einstellt und häufig auch nicht vorweg quantifizieren lässt“, ­berichtet Ionos-Produktmanager Felix Grundmann. Bei Containern patcht man also keine Live-Container, sondern die Images in ihrer Container-Registry. „Auf diese Weise kann das vollständig gepatchte Container-Image als eine Einheit ­ausgerollt oder zurückgerollt werden, sodass der Patch-Rollout-Prozess mit seinem - offensichtlich sehr häufigen - Code-Rollout-Prozess identisch wird, komplett mit Überwachung, Canarying und Tests“, erklärt Stefan Schäfer, Head of Global Product Marketing beim ­Hosting-Spezialisten OVHcloud. So werde ein Patch unter Verwendung des normalen ­Prozesses auf vorhersehbare Weise ausgerollt. Eine Alternative  - wenn auch weniger vorteilhaft, da sie nach einem unvorhersehbaren Zeitplan eintritt - sei es, den Rollout ad hoc erfolgen zu lassen. „Wenn ein Container dann das nächste Mal stirbt, dreht Kubernetes einen weiteren Container auf, um dies auszugleichen, und alle Patches, die man angewendet hat, werden auf die Infrastruktur ausgerollt.“ Abhängig von der Lebensdauer der Container sollten diese innerhalb weniger Tage vollständig gepatcht sein.
Verwandte Themen