© Miguel Perfectti / 123rf.com

Manche Anwendungsentwickler versuchen, in Container verpackte Anwendungen so handzuhaben, als handele es sich um konventionelle Monolithen. Die Handhabung von Updates und Sicherheits-Patches in Containern funktioniert allerdings völlig anders.

Die erste Zeile in Kurt Tucholskys Gedicht “Das Ideal” lautet: “Ja, das möchste”, gefolgt von einer langen Aufzählung von verlockenden Annehmlichkeiten, die einander freilich teilweise ausschließen oder schlicht utopisch sind. Mancher Admin mag sich, wenn er die allzu vollmundigen Versprechen der Hersteller im Hinblick auf ihre Werkzeuge für Container hört, an Tucholskys Worte erinnert fühlen: Alles scheint es zu geben.

Praktisch aus dem Nichts tauchen Container mit beliebigen Anwendungen auf, die sie auch noch völlig automatisch und in der richtigen Konfiguration ausrollen. Des Entwicklers Apps integrieren sich im Stile von Mikroarchitekturanwendungen nahtlos in die PaaS-Umgebungen auf Basis von OpenShift, Rancher und Co. und funktionieren einfach, weil Mesh-Lösungen wie Istio die Kommunikation sicherstellen. Um Updates braucht der Admin sich auch nicht mehr zu kümmern, denn die vollautomatische CI/CD-Pipeline sorgt schon dafür, dass neue Versionen von Diensten wie von Zauberhand ihren Weg in das produktive Deployment eines Unternehmens finden.

Die Realität sieht selbstverständlich deutlich weniger rosig aus. Trotz aller Versprechen der Hersteller: Bis überhaupt einmal eine Anwendung nach dem PaaS-Modell im Rahmen von OpenShift, Rancher oder einer der zahllosen anderen Kubernetes-Distributionen wie gewünscht ihren Dienst verrichtet, ist einiger Aufwand nötig. Und wenn der Kram einmal läuft, heißt das noch lange nicht, dass das auch so bleibt: Die CI/CD-Build-Pipeline, aus der aktualisierte Images herausfallen, wenn jemand im Upstream beispielsweise eine neue Version einer genutzten Bibliothek freigibt, erfordert ein weiteres Stück großer Anstrengung.

Für Administratoren bedeutet das faktisch Stress – und zwar jedes Mal, wenn ein genutztes Upstream-Projekt mit Updates für eine verwendete Komponente herausrückt. Besonders prickelnd wird die Situation, wenn es nicht um ein funktionales Update geht, sondern um einen Security-Fix.

Von wegen ab Werk sicher

Dazu sind ein paar Erläuterungen nötig. Die Anbieter der Container-Orchestrierer suggerieren im Rahmen ihrer Angebote stets, dass Container implizit sicherer seien als konventionelle Umgebungen. Podman und Konsorten bräuchten mittlerweile schließlich nicht mehr die Rechte des Systemadministrators Root, und darüber hinaus sei jeder Container ja komplett isoliert und kommuniziere nur per Netz mit den anderen Containern.

Diese Betrachtung lässt ein paar relevante Fakten allerdings sträflich außer Acht. Dass ein erfolgreich in einen Container eingebrochener Angreifer dort eingesperrt bleibt und deshalb nicht auf dem Host per Hack Root-Rechte erlangen kann, ist gut – insofern es das Ziel der Attacke war, die gesamte Maschine missbräuchlich zu verwenden. Besteht das Ziel jedoch darin, die Anwendung auszuspionieren, hilft der Schutz vor Übergriffen auf das Host-System rein gar nichts.

Wie im Security-Kontext üblich, zeigt sich, dass die Aussage “X ist sicherer als Y” vorrangig vom Bedrohungsszenario abhängt, dem eine Installation sich gegenüber sieht. Das bedeutet auch, dass der Admin von einer erhöhten Sicherheit durch Container niemals ausgehen sollte. Wie ihre konventionellen Vorgänger auch bedürfen Container regelmäßiger Security-Fixes sowie etwaiger Audit-Verfahren. Das Handling von Sicherheitsaktualisierungen spielt daher auch im Container-Kontext eine bedeutende Rolle.

Dieser Artikel befasst sich im Detail mit der Frage, wie der Admin die Workloads in Containern sicher und aktuell hält. Dabei geht es einerseits um Prozesse: Die sollten in Container-basierten Umgebungen eng mit der Plattform per se verwoben sein. Wie nutzt der Admin optimal die Möglichkeiten, die Rancher und Konsorten bieten, um zu einer sicheren Plattform zu gelangen? Andererseits geht es auch um Werkzeuge – was bringen die gängigen PaaS-Stacks bereits mit, um dem Admin die Arbeit zu erleichtern? Worauf kann er sich verlassen?

So viel sei bereits verraten: So simpel, wie die Hersteller es glauben machen wollen, ist die Sache mit Sicherheit nicht.

Andere Updates

Es hilft, sich zu vergegenwärtigen, dass man es als Admin in einer Umgebung, die auf Container-Technologie und Container-Orchestrierung fußt, mit einem vollkommen anderen Deployment-Szenario zu tun hat als in konventionellen Umgebungen.

Wo Container keine Rolle spielen, bildet üblicherweise die Paketverwaltung den Dreh- und Angelpunkt der Softwareversorgung von Systemen. Die großen Distributoren sehen einen Teil ihres Business-Cases ja gerade darin, unzählige Komponenten freier (und zum Teil proprietärer) Software so zu einem Gesamtpaket zu formen, dass der Admin sie ohne weiteres Aufsehen verwenden kann.

Der Container-Use-Case stellt dieses Konzept allerdings auf den Kopf. Hier spielt die Abstimmung von Komponenten aus Admin-Sicht kaum mehr eine Rolle: Nahezu jede Anwendung bringt einfach das gesamte Userland, das sie benötigt, in ihrem eigenen Container mit. Festplatten und sogar flotte Flash-Laufwerke kosten heute nicht mehr die Welt. Der Overhead von ein paar Hundert Megabyte, der entsteht, wenn der Admin einen fertigen MariaDB-Container samt Abhängigkeiten installiert, fällt da kaum ins Gewicht. Und die meisten Admins sind gewillt, diesen finanziellen Mehraufwand zu leisten, wenn sie sich dafür nie wieder in der berühmten Abhängigkeitshölle der Paketsysteme wiederfinden.

Dass eine Applikation in Container-Umgebungen stets ein ganzes Userland dabei hat, wirkt sich allerdings auch auf die Art und Weise aus, wie Admins das Thema Updates in Container-basierten Umgebungen angehen müssen. Um das Sicherheitsproblem beiseite zu räumen, genügt es nicht mehr, auf allen Systemen der Installation ein bestimmtes Paket auf den Hosts auf den jeweils aktuellsten Stand zu bringen: In den Containern gibt es die Komponente möglicherweise auch, und in anderen Versionen als auf den Hosts. Je verbreiteter die Komponente, desto wahrscheinlicher ist das der Fall. So wäre ein Bug in der Bibliothek, die sich um TLS-Verbindungen kümmert, ein kapitaler Totalschaden, der vermutlich quer durch die gesamte Installation hindurch Updates erzwingen würde – sowohl auf der Hardware als auch in den Containern.

Keine simplen Updates

Was auf dem Blech noch einigermaßen sinnvoll klappt, weil dort zumeist der bekannte Paketmanager zur Verfügung steht, gestaltet sich in den Containern allerdings weniger trivial. Docker und Podman bieten immerhin die Möglichkeit, von der Shell aus beliebige Befehle in einem Container auszuführen – also auch eine Shell, die es in fast jedem Container gibt. Findige Admins kommen daher manchmal auf die Idee, einfach innerhalb des Containers das jeweilige Update zu installieren. Die meisten Container-Abbilder offizieller Art setzen ja auf irgendeine Distribution auf und haben durchaus eine eigene Paketverwaltung an Bord.

Die Idee, die Container einfach an Ort und Stelle zu aktualisieren, greift jedoch aus mehreren Gründen zu kurz. Der erste und offensichtlichste: Bei Containern ist üblicherweise der sogenannte Entry Point das eigentliche Programm, das der Container betreiben soll. Ein MariaDB-Container etwa nutzt als Entry-Point entweder MariaDB oder einen Wrapper, der die Datenbank irgendwie startet. Ersetzt der Admin mittels Update im Container eine Bibliothek, die die Datenbank benötigt, muss er diese anschließend neu starten, damit sie die neue Bibliothek nutzen kann. Das tötet jedoch den im Container laufenden Hauptprozess und mithin den Container selbst.

Hand in Hand mit dieser Herausforderung geht Problem 2: Es genügt aus Sicht des Admins nicht, den abgestürzten Container neu zu starten – das gelingt auf dem Host-System gar nicht mehr, wenn er einmal weg ist. Die meisten Container sind heute so konstruiert, dass auf Grundlage des fertigen, in sich geschlossenen Abbilds während der Nutzung ein OverlayFS entsteht. Das verschwindet allerdings mit dem Container. Startet der Admin also den MariaDB-Container neu, erfolgt das aus dem ursprünglichen Abbild, weil das Update lediglich im OverlayFS gelandet war. Und damit ist das installierte Update logischerweise auch wieder weg. Zum ewigen Glück führt dieser Pfad jedenfalls nicht.

Container sind komplexer

Von großer Bedeutung ist stattdessen die Frage nach dem Betriebskonzept, das der Admin für sein Setup gewählt hat. Hier gibt es ja mehrere Optionen, die maßgeblich von den Komponenten abhängen, die der Admin in seinem Setup integrieren muss. Grundsätzlich gilt es, dabei zwischen für den Betrieb in der Cloud ausgelegten Cloud-ready-Anwendungen und konventionellen Anwendungen zu unterscheiden, die sich zwar in Containern betreiben lassen, aber eine gewisse Schützenhilfe von außen benötigen.

Ein einfaches Beispiel macht das schnell deutlich. Praktisch jede Installation der Gegenwart setzt irgendwo in ihrem Kern auf eine Datenbank auf. Auch Anwendungen auf Basis der Mikrokomponentenarchitektur verarbeiten ja letztlich externe Daten, die in irgendeiner Weise gespeichert werden wollen. Die meisten Anwendungsentwickler und Admins entscheiden sich bei Datenbanken für erprobte Komponenten, deren Verhalten sie kennen und einschätzen können. Die sind für den Betrieb in der Cloud aber nur bedingt ausgelegt, zumindest in ihrer ursprünglichen Form.

Das gilt es zu beachten, rollt der Admin sie in Form von Containern aus: Ein einzelner Container mit einer MariaDB darin ist keine gute Idee. Muss man die Datenbank aus Sicherheitsgründen neu starten, hängt der Rest des Setups in den Seilen. Dass der Neustart des Containers womöglich gar nicht deshalb erfolgt, weil der Admin ihn anweist, sondern weil der Anbieter den Knoten wegen eines Sicherheitsupdates seinerseits rebootet, etwa beim Kernel, spielt da schon kaum mehr eine Rolle.

Aus Sicht des Admins, der Workloads in der Cloud betreibt, gilt jedenfalls: Cluster sind Pflicht, ohne implizite Redundanz auf der Anwendungsebene geht es auf keinen Fall. Auf das Datenbankbeispiel bezogen könnte ein Ergebnis aus dieser Erkenntnis etwa sein, dass MariaDB als Anwendung in Containern nie allein daherkommt, sondern der Admin es mittels der Kubernetes-API stets als Cluster ausrollt. Dann kann einer der (mindestens) drei Datenbankknoten jederzeit einen Neustart vollziehen, ohne dass es zu einer für die Endanwender bemerkbaren Downtime kommt.

Cloud-ready-Anwendungen

Etwas entspannter gestaltet sich die Situation bei Sicherheitsaktualisierungen von speziell für den Einsatz in der Cloud entwickelten Anwendungen. Die folgen meist dem Mikroarchitektur-Paradigma. Es gibt also eine Vielzahl kleiner Dienste, die über definierte Schnittstellen miteinander kommunizieren und jeweils nur eine einzelne Aufgabe erledigen. Weil es ab Werk sogar vorgesehen ist, dass einzelne Dienste dynamisch verschwinden und wieder auftauchen, gestaltet sich der Austausch der Container hier deutlich entspannter als beim Umgang mit konventionellen Lösungen. In den meisten Fällen kann der Admin die Container durch solche mit aktuellerer Software ersetzen, ohne dass Endanwender davon irgendetwas mitbekommen.

Mesh-Lösungen helfen

Ein Scherflein dazu tragen überdies Mesh-Lösungen bei, die die Kommunikation in Umgebungen auf Container-Basis übernehmen. Mesh-Lösungen waren im Linux-Magazin bereits mehrmals Gegenstand der Betrachtung, etwa der Platzhirsch Istio [1].

Lösungen wie Istio makeln die Verbindungen zwischen den einzelnen Komponenten einer Anwendung flexibel; sie fungieren (auch) als Load Balancer und verfügen über ein eigenes Monitoring der konfigurierten Ziele. Nutzt der Admin Istio etwa im vorher beschriebenen MariaDB-Szenario, läuft nicht nur die Datenbank während des Neustarts einzelner Container reibungslos weiter: Die gerade im Neustart befindliche Datenbank bekommt, einer Mesh-Lösung wie Istio sei Dank, augenblicklich auch keine Client-Anfragen mehr vom Load Balancer weitergeleitet.

Das Handling von Updates

Die beschriebenen Konzepte und Theorien helfen dem Administrator zwar dabei, seine Container so zu aktualisieren, dass für Endanwender keine Downtime entsteht. Manch passionierter Admin bemäkelt allerdings zu Recht, dass die beschriebenen Tipps die Frage nach dem handwerklichen Vorgehen bei Updates von Software in Containern im weitesten Sinne offenlassen.

Andererseits stellen sich einige sehr konkrete Fragen: Wie tauscht der Admin in einem Verbund laufender Container einen Container in einem Pod aus? Woher bekommt er das aktualisierte Abbild, worauf muss er achten? Im Folgenden fasst dieser Artikel deshalb das handwerkliche Vorgehen zusammen, das Updates in Containern dominiert. Zum einfacheren Verständnis denkt der Admin hier idealerweise in mehreren Prozessschritten.

Es stimmt was nicht

Wie bei konventionellen Systemen auch besteht der erste Schritt im Handling von Sicherheitsproblemen bei Containern darin, überhaupt herauszufinden, dass etwas nicht stimmt. Weil der Container ja gerade so gebaut ist, dass er eine logische Einheit bildet, finden die Sicherheitschecks, die “normale” Systeme regelmäßig auf bekannte Sicherheitslücken hin abklopfen, hier schlicht nicht statt.

Dabei spielt auch eine Rolle, wie Admins Docker- oder Podman-Container üblicherweise bauen: Wer seine eigenen Container erstellt, tut dies regelmäßig auf Basis eines Abbilds etwa von Alpine Linux, Ubuntu oder Debian (Abbildung 1). Taucht in den Images eine Bibliothek oder ein Programm mit Sicherheitsloch auf, enthält die nächste Version des Containers vermutlich den Fix, weil ein repariertes Paket auf den Debian-Servern vorliegt und dann in das neue Paket übernommen wird. Eine formale Ankündigung etwa des Security-Teams, die die gestopfte Lücke bekannt macht, gibt es für Container-Abbilder bis dato allerdings nicht – dafür aber ein Helferlein namens Clair, auf das wir gleich noch im Detail eingehen.

Abbildung 1: Die meisten Docker-Abbilder von Anwendungsentwicklern fußen auf den Basis-Images der Hersteller, etwa dem von Canonical für Ubuntu.

Verlässt man den Weg der Nutzung fertiger Basis-Images und baut sich stattdessen das komplette Abbild selbst, wird es noch komplizierter. In solchen Situationen ist der Administrator auf Handarbeit angewiesen. Eine Methode könnte sein, mittels Tools wie Apt-listchanges regelmäßig die Änderungen in den Paketen zu überwachen, die das jeweiligen Image enthält. Taucht hier der String “Security” auf, könnte das darauf hindeuten, dass ein Update ansteht. Von der Stange gibt es solche Lösungen jedoch nicht, und Unternehmen, die ihre eigenen Abbilder aus einer CI/CD-Toolchain heraus bauen lassen, müssen diesen Aspekt des Bauvorgangs selbst entwickeln.

Clair eilt zur Hilfe

Es gibt ein Werkzeug, das dem Administrator unter die Arme greift, wenn der sich auf die Basisabbilder der verschiedenen Distributoren verlässt. Baut er seine eigenen Docker-Abbilder nämlich so, dass die ursprünglichen Layer des Abbilds erhalten bleiben, springt ihm das kleine Werkzeug Clair zur Seite (Abbildung 2).

Abbildung 2: Automatisierte Überwachung von Sicherheitslücken in Container-Images lässt sich mit Clair erreichen, allerdings nur für die statischen Layer des jeweiligen Abbilds. Quelle: Red Hat

Clair analysiert Container-Abbilder anhand ihrer Metadaten und vergleicht die dort genutzten Images mit einer Liste veröffentlichter Security-Probleme. Findet es Schwachstellen, schlägt es Alarm und fordert den Admin auf, seine Basis-Images zu aktualisieren (Abbildung 3). Das setzt einerseits eine CI/CD-Pipeline voraus, die lokal ein neues Image mit neuem Basisabbild und den lokalen Veränderungen konstruieren kann. Andererseits zeigen Werkzeuge wie Clair für den Teil der lokalen Modifikationen keine Sicherheitsprobleme an. In Summe ist dieser Ansatz für den Admin aber immer noch deutlich bequemer, als das gesamte Handling von Sicherheitsproblemen in der eigenen Infrastruktur abzufangen. Ein genereller Tipp an dieser Stelle lautet, das Thema Security durch die Community und die Hersteller abhandeln zu lassen, wie man es im normalen Umfeld auch täte.

Abbildung 3: Erkennt Clair ein Problem mit einem Abbild, warnt es den Administrator und fordert ihn auf, das neue Abbild zu installieren. Danach muss allerdings auch ein Rollout der jeweiligen Pods erfolgen. Quelle: Red Hat

Clair gehört übrigens zu Quay, das Red Hat vor ein paar Jahren erworben hat. In OpenShift ist Clair dadurch beispielsweise integriert: Aus der OpenShift-GUI heraus lassen sich die Images laufender Pods also unmittelbar prüfen. Dabei begutachtet Clair auch hier nicht den Inhalt des Containers, sondern untersucht lediglich die Layer des Abbilds auf bekannte Sicherheitsprobleme hin (Abbildung 4).

Abbildung 4: Die Fähigkeiten von Clair lassen sich in OpenShift nicht nur per GUI nutzen, sondern auch auf der Kommandozeile.

Der Vollständigkeit halber sei an dieser Stelle außerdem noch erwähnt, dass die meisten Hersteller externer Software für ihre Docker-Container ebenfalls auf die Basisabbilder der großen Distributoren setzen (Abbildung 5). So fußt der Container, den MariaDB mit der gleichnamigen Datenbank ausliefert, auf dem “Focal”-Abbild von Ubuntu, das Canonical bereitstellt. Für die Nutzung in Clair erweist sich das als großer Vorteil, weil Clair so zumindest jene Teile des MariaDB-Abbilds prüfen kann, die vom ursprünglichen Ubuntu-Image übrigblieben.

Abbildung 5: MariaDB setzt bei seinem Container auf das Ubuntu-Basis-Abbild, sodass Fehler darin von Clair erkannt würden.

Die Abbilder korrigieren

Den zweiten Schritt nach der Erkenntnis, dass ein Sicherheitsproblem vorliegt, hat dieser Artikel implizit bereits abgearbeitet. Die wichtigsten Grundregeln lassen sich kurz aufzählen: Sicherheits-Updates in Containern kann der Admin immer dadurch lösen, dass er eine neue Version des Containers ausrollt, statt am laufenden Container herumzubasteln. Damit das klappt, muss die Architektur eines Setups von Anfang implizit redundant konzipiert sein. Zentrale Werkzeuge wie Datenbanken gilt es zu clustern, damit der Ausfall eines Containers nicht die gesamte Umgebung in den Abgrund reißt.

Wie genau der Administrator allerdings zu aktualisierten Abbildern kommt, auf deren Basis er dann neue Container startet, lässt sich in diesem Artikel kaum sinnvoll beschreiben: Die Anzahl der möglichen Setups vor Ort, die Images nutzen und generieren, ist riesig. In einem Artikel [2] zu Containern und Sicherheit hat das Linux-Magazin bereits vor gut drei Jahren im Detail erklärt, wieso es keine gute Idee ist, beliebige Container aus dem Netz zu nehmen, auszurollen und nur kurz zu testen, ob sie die gewünschte Funktionalität liefern. Daran hat sich bis heute nichts geändert, und mehr noch: Wer ernsthaft Container-Workloads betreibt, muss seine Container irgendwie aus einer CI/CD-Pipeline holen. Dass es keine sonderlich bequeme Aufgabe ist, eine solche Umgebung zu konstruieren, steht außer Frage.

Kommerzielle Distris helfen

Allerdings haben die Hersteller der kommerziellen Kubernetes-Distributionen dieses Problem erkannt und eilen dem Admin auf verschiedene Arten zur Hilfe. Wer etwa Red Hats OpenShift oder Suses Rancher nutzt, bekommt vom Hersteller zumindest sämtliche für eine CI/CD-Toolchain nötige Software vorkonfiguriert ausgeliefert. Das macht das Setup erheblich leichter, zumal die Hersteller ihre Lösungen mittlerweile auch mit gut verständlichen, intuitiven UIs ausliefern.

Das eigentliche Update

Angenommen, der Admin hat den MariaDB-Container aus unserem Beispiel als Container mit Sicherheitsproblem identifiziert und möchte ihn nun aktualisieren. Das neue Abbild hat er sich bereits organisiert, sodass im nächsten Schritt das konkrete Handling passiert. Kommt kein Flottenmanager wie Kubernetes zum Einsatz, ist das Ganze schnell erledigt: alten Pod stoppen, neuen Pod starten, Schema F, bis alle Pods durchrotiert sind – fertig.

Nicht einem Flottenmanager unterstellte Setups mit Containern finden sich heutzutage allerdings nur noch sehr selten, sodass das Beispiel kaum als praxisnah gelten darf. In der Regel hat der Admin es stattdessen mit einer beliebigen Darreichungsform von Kubernetes zu tun, etwa in Form von OpenShift, Rancher oder der tatsächlichen Kubernetes-Distribution des Herstellers. Hier kommt eine Technik ins Spiel, die die Kubernetes-Entwickler Rolling Update nennen und die im Grunde für ebensolche Szenarien vorgesehen ist.

Grundsätzlich gilt: Der Admin aktualisiert innerhalb eines Pods nicht einzelne Container. Er stellt stattdessen den bestehenden Pods neue Pods zur Seite. Auf Wunsch kann Kubernetes das Einfügen neuer Pods mit neueren Images und das Ausphasen alter Pods automatisch erledigen – ein Rolling Update. Unter der Haube nutzt es die Kubernetes-Controller für Replica, um seine Aufgabe zu erfüllen. Ein Kubernetes-Tutorial [3] beschreibt die Technik im Detail – dort steht auch, wie der Admin sie im jeweiligen Einzelfall nutzt. Der Vorteil dieses Ansatzes: Der Admin muss sich um die Beseitigung der Altlasten keine Sorgen machen. Er darf stattdessen sicher davon ausgehen, dass die löchrige Software im Nirvana verschwindet.

Fazit: Kompliziert, aber möglich

Container sind vielseitiger und komplexer als ihre konventionellen Vorgänger, und zusätzlich bekommt der Administrator es bei ihnen in aller Regel auch noch mit deren Orchestrierer zu tun. Das kann man lästig finden, oder man freut sich über die Schützenhilfe, die man als Admin von den jeweiligen Komponenten erhält. Gute und zuverlässige Sicherheitsaktualisierungen bei Containern setzen sorgfältige Planung und gute Vorbereitung voraus. Um im produktiven Alltag nicht auf die Nase zu fallen, muss der Administrator vor allem seine Prozesse im Griff haben. Werkzeuge wie Clair helfen zwar enorm, sind ohne entsprechende Vorbereitung allerdings nutzlos.

Insgesamt ist das Thema Sicherheit von Container-Abbildern in Kubernetes momentan allerdings auch noch nicht so tief verankert, wie es aus Sicht des Admins eigentlich wünschenswert wäre. OpenShift setzt als einziges Produkt Clair als Scanner für potenzielle Probleme ein. Hier sollten die Anbieter dem Admin Mittel und Wege bereitstellen, laufende Container nicht nur anhand irgendwelcher Image-IDs automatisch zu untersuchen, sondern anhand der tatsächlich gegebenen Container. (jcb)