Für das Deployment einer Applikation in der Cloud werden Tools wie Kubernetes verwendet. Kubernetes (Vielleicht auch interessant: Kubernetes in einem Klick einrichten ist ein von Google entwickeltes Open-Source-System zur Verwaltung von Container-Anwendungen. Ein Container ist in diesem Kontext eine Laufzeitinstanz eines (Docker-)Images.
Docker-Images bestehen aus diversen Komponenten, die benötigt werden, um den eigentlichen Service, den das Docker-Image adressiert, auszuführen. Docker-Images müssen stetig aktualisiert werden, um Sicherheitslücken zu schließen und eine hohe Servicequalität gewährleisten zu können. Der Vorteil bei der Automatisierung des Prozesses besteht in der Verringerung der Reaktionszeit von der Feststellung einer Sicherheitslücke bis hin zu deren Behebung. Der Prozess läuft vollkommen automatisch ab, weshalb diese Art von Prozess auch Zero oder No Touch Operation genannt wird.
Im Folgenden ist ein Prozess beschrieben, der es ermöglicht, in einem gewissen Rahmen automatisch zu erkennen, ob ein Image Sicherheitslücken beherbergt, und der bei Bedarf oder nach Möglichkeit Images neu baut.
Docker-Tags werden verwendet, um die Version des Service zu tracken. Ist ein Image einmal gebaut und in einer Registry hinterlegt, altert dieses. Auch wenn Sicherheitslücken im eigentlichen Service-Artefakt vorhanden sein könnten, sind die Sicherheitslücken in den Komponenten um einiges schwerwiegender. Diese Komponenten-Sicherheitslücken werden zum Beispiel in Common Vulnerabilities and Exposures (CVE) Datenbanken gesammelt und öffentlich zur Verfügung gestellt. Diese Datenbanken sind von großem Wert, um Sicherheitslücken in den eigenen benutzten Bibliotheken zu finden und zu beheben. Angreifer benutzen solche Datenbanken auch, um die gelisteten Sicherheitslücken auszunutzen. Die Komponenten sind teilweise viele Millionen Mal installiert und bieten sich somit als Ziel an. Wer die Sicherheitslücken nicht schnell schließt, wird Opfer von automatisierten Angriffen. Komponenten müssen deshalb kontinuierlich aktualisiert werden.
Ein einmal erstelltes Docker-Image darf nicht mehr nach einem halben Jahr in einer produktiven Umgebung eingesetzt werden. Ein Service-Image, welches in der Version gleichbleibt, muss immer wieder neu erzeugt werden, um die Komponenten in aktuellen Versionen zu verwenden.
Was für Server-Infrastruktur gilt, muss auch bei Docker-Images gelten. Patches müssen kontinuierlich installiert werden. Für Docker-Images heißt es, dass diese stetig neu gebaut werden müssen.
Herausforderungen beim Patchen von Docker-Images
Ein Frontend-Image hat in der Regel eine Kernel-/OS-, eine Middleware- und eine Applikations-Schicht. Zumeist werden Patches aus unterschiedlichen Quellen angeboten. Was bedeutet, die installierten Komponenten müssen nach Quellen sortiert werden. Eine Quelle für die OS-Schicht könnte zum Beispiel der Yellowdog Updater, modified (yum) sein. Wenn Komponenten während des Build-Prozesses über yum installiert werden, können diese auch über yum aktualisiert werden. Paketmanagement-Systeme wie yum erleichtern das automatisierte Updaten von Komponenten erheblich, da diese die Versionierung und die Aktualisierung automatisch übernehmen können.
Gerade die Middleware wird zum Teilen nicht immer über einen Paketmanager angeboten oder soll abweichend von der Installationsart via Paketmanager installiert werden. Damit die Middleware automatisch installiert werden kann, wird ein Wrapper-Tool benötigt, welches in der Lage ist, die installierte Middleware mit Version zu ermitteln und zu prüfen, ob neue Versionen dazu veröffentlicht worden sind.
Bewertungsprozess
Bevor ein Image bewertet werden kann, wird beim Erzeugen des Images eine Liste von allen installierten Komponenten in der installierten Version gespeichert. Diese Listen können nun mit CVE-Datenbanken abgeglichen werden und ein Health-Score eines Images berechnet werden. Tools wie Trivy können diese Aufgabe sehr gut unterstützen oder diese gar ganz übernehmen. Je nachdem, wie der vorliegende Workflow designt ist.
Die Bewertung einer Komponente kann vier mögliche Ausgänge haben. Ein Paket gilt als Outdated, wenn eine neue Version veröffentlicht wurde.
Wenn keine Sicherheitslücken bei einem Scan gefunden werden (Zustand 3 und 4), besteht kein Handlungsbedarf, da die neue Version höchstens Feature-Updates bringt. Wenn eine Komponente Sicherheitslücken aufweist, aber bisher noch kein Patch zu diesem Packet verfügbar ist (Zustand 1), sollte zuständiges Personal für eine individuelle Einschätzung informiert werden. Im zweiten Zustand besteht akuter Handlungsbedarf.
Sobald eine Komponente eines Images dem zweiten Zustand zugeordnet wird, bekommt das gesamte Image diesen Zustand.
Sollte ein Image diesen Zustand zugeordnet sein, wird ein neues Patch-Release mit den aktualisierten Komponenten gebaut.
Fazit
Mit einem solchen System kann eine „No Touch Operation“ bis zu einem gewissen Grad realisiert werden. Im Wesentlichen müssen für eine komplette Autonomie zwei Problemstellungen gelöst werden. Einmal muss der Wrapper, der die Komponenten prüft, stetig an die verwendeten Komponenten angepasst werden und zum anderen werden Komponenten mit der Zeit auch nicht mehr gepatcht, sondern es muss auf ein neues Major-Release umgestiegen werden. Dieses kann unter Umständen „Breaking Changes“ beinhaltet, welche die Funktion des im Docker-Image eigentlich enthalten Services stark einschränken können.
Es ist ein „Wann“ und kein „Ob“, dass eine Komponentenversion nicht mehr gepatcht wird, sondern auf das nächste Major-Release migriert werden muss. Für diesen Fall ist es schwer, eine automatische Lösung zu finden.
Gerade automatisierte Tests helfen in diesem Szenario, schnell auf eine funktionsunfähige Komponente aufmerksam zu werden.
Für das automatisierte Deployment im operativen Bereich von neugebauten Images können Tools wie ArgoCD verwendet werden.
Sie haben Fragen oder Anmerkungen? Dann hinterlassen Sie uns gerne einen Kommentar.