Aus Kubernetes wird Container as a Service
DevOps-Kultur muss gelebt werden
Vor allem im DevOps-Bereich ist die Sicherheit von Containern ein Thema: Das Operations-Teams hat die Aufgabe, Sicherheitslücken in Produktivumgebungen zu finden. In der Praxis ist es 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 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 Firmen auf fertige Lösungen zurückgreifen.» GitHub werde etwa automatisch auf Sicherheitslücken in solchen Abhängigkeiten gescannt und der Anwender benachrichtigt.
Hohe Flexibilität und Skalierbarkeit: Das sind für Unternehmen die wichtigsten Vorteile beim Einsatz von Containern.
Quelle: Techconsult/Cronon - Mehrfachnennungen, Unternehmen in Deutschland
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 Workloads 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 womöglich angebracht, entweder einen Anwendungskatalog mit signierten Basis-Images zu verwenden oder auch Container-Images in regelmässigen Abständen neu zu erstellen. Weitere wichtige Aspekte für einen sicheren Betrieb von Container-Workloads sind das Netzwerk-Design sowie der Einsatz von Monitoring- und Logging-Systemen.
Patchen im Auge behalten
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 sich oft auch nicht vorweg quantifizieren lässt», berichtet Ionos-Produktmanager 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.
