Container haben in den vergangenen Jahren eine beispiellose Erfolgsgeschichte hingelegt, und ein Ende des Hypes ist kaum in Sicht. Im Gegenteil: Seit Kubernetes mitmischt und die Möglichkeit bietet, über eine große Flotte von Compute-Knoten Container-Workloads effektiv zu verwalten, dringen Container immer häufiger auch auf angestammtes Gebiet der Voll- und Paravirtualisierung vor.

Damit aus dem Container-Land aber keine Horrorvision wird, müssen Unternehmen beim Betrieb von vielen Containern einige Dinge beachten. Schließlich pflegen Kubernetes & Co. sich nicht von selbst, und weniger komplex als ihre althergebrachten Vorgänger sind Ansätze auf Container-Basis auch nicht. Bei einem Blick auf den berüchtigten "Layer Cake", den etwa Docker und Kubernetes im Gespann anrühren, wird das schnell offensichtlich. Hier hat der Administrator es eher mit noch mehr "losen Teilen" zu tun als in konventionellen Setups: Die Laufzeitumgebung für Container, Kubernetes selbst, etliche Zusatzlösungen wie das MESH-System Istio, verschiedene Paketmanager wie Helm und die diversen Quellen, aus denen sich Container-Abbilder heute beziehen lassen, sind dafür nur einige Beispiele.

Dabei stellt sich besonders das Thema Sicherheit als Herausforderung dar. Denn im Cloud-Stack der Gegenwart sind so viele Komponenten aus so vielen unterschiedlichen Quellen mehr oder minder sinnvoll miteinander kombiniert, dass es aus Sicht des Admins nicht einfach möglich ist, auch nur den Überblick zu bewahren. Und noch schwieriger ist es, Sicherheitsupdates für die diversen Quellen schnell als solche zu identifizieren, die im eigenen Umfeld gebraucht werden, und sie dann zeitnah zu installieren.

Und als ob das nicht schon genug Ungemach wäre, gilt fast dasselbe für das Thema Compliance. Der größte Teil eklatanter Sicherheitsprobleme schließlich entsteht nicht aus Bugs heraus, sondern aus banalen Fehlkonfigurationen, die im Review niemandem auffallen. Versagen alle internen Kontrollprozesse, steht die eigene Container-Landschaft im blödesten Fall da wie ein offenes Scheunentor.

An dieser Stelle eilt Ihnen Kubescape [1] zur Hilfe. Mit vollmundigen Versprechungen geizen dessen Entwickler nicht: Es handele sich um das erste Werkzeug, das komplett automatisiert den gesamten Container-Stack einer Umgebung auf Sicherheits- und Compliance-Probleme abklopfen könne, und zwar auf Basis anerkannter Regularien wie NIST, MITRE oder NSA-CISA. Dabei nehme Kubescape sich nicht nur die basalen Dienste vor, die zu Kubernetes selbst gehören, sondern prüfe auch YAML-Dateien mit Ressourcendefinitionen, Code in Verzeichnissen wie GitHub oder GitLab, die Artefakte, die aus CI/CD-Werkzeugen wie Jenkins oder Argo entstehen, und schließlich das Deployment selbst und die dazu gehörenden Komponenten.

Das Ganze funktioniert laut Entwicklern in wenigen Arbeitsschritten: Installieren, starten, glücklich sein, so das Credo. Tatsächlich leistet Kubescape Erstaunliches, und haben Sie sich ein wenig in das Programm eingearbeitet, dürften Sie begeistert sein von der Vielfalt der enthaltenen Features. Obendrein ist Kubescape freie Software, ein offizielles Sandbox-Projekt der CNCF und frei im Netz erhältlich. Grund genug für Kubernetes-Administratoren, sich mit dem Tool genauer zu befassen und es auszuprobieren.

Zuvor steht allerdings ein bisschen Theorie auf dem Stundenplan – denn auch Kubescape selbst ist unter der Haube komplex. Damit Sie sich damit also nicht das nächste Werkzeug ins Haus holen, dessen Funktionalität Sie nur schemenhaft kennen oder verstehen, ist ein genauer Blick auf das nötig, was Kubescape leistet. Und das wiederum bedingt, sich genauer mit der Struktur eines üblichen Kubernetes-Setups zu befassen. Denn nur so wird erkennbar, welche Komponenten hier eigentlich in Sachen Sicherheit und Compliance eine Rolle spielen und wo Kubescape bei der Überwachung eben dieser Komponenten ansetzt.

Gesetzt und offensichtlich sind die Komponenten von Kubernetes selbst so wie die Helferlein, die K8s für den Betrieb von Containern benötigt. Das umfasst also die Kubernetes-API, den Scheduler, den K8s-Controller-Cluster sowie die Agenten auf den Zielsystemen namens Kubelet. Obendrein ist K8s ohne Laufzeitumgebung für Container auf einem Compute-Knoten praktisch nutzlos. Nötig sind entsprechend entweder die Docker Community Edition als Laufzeitumgebung oder Podman, das ebenfalls eine mit der cri-o kompatible Laufzeitumgebung bietet. Zusammen genügen diese Komponenten, um Container über die Grenzen einzelner Compute-Systeme zu administrieren.

In den allermeisten Umgebungen der Gegenwart ist es mit diesen Basiskomponenten aber nicht getan. Denn diese umfassen nur sehr grundlegende Funktionen für komplexes Software-defined Networking (SDN) und Software-defined Storage. Ohne diese Komponenten sind gerade größere Containerflotten aber nicht sinnvoll zu betreiben. Wer eine skalierbare Plattform baut, braucht schließlich auch skalierbares Netz und skalierbaren Speicher.

Flugs kommen zusätzliche Komponenten hinzu, etwa Calico für das Netz oder Rook, das die Objektspeicherlösung Ceph in K8s packt und verwaltbar macht. Rook wie auch Calico bedienen sich dabei massiv sogenannter Custom Resource Definitions, die im Security-Kontext strenggenommen als eigener Faktor gelten müssen. Denn das bestgesicherte Kubernetes nützt nichts, wenn es durch eigens erstellte oder auch nur eingespielte Erweiterungen doch wieder löchrig wird. Zumal fertige Lösungen wie Rook längst nicht die einzigen Projekte sind, die extern an Kubernetes herumschrauben. Auch Werkzeuge wie Istio gehören dazu und erweitern die Kubernetes-API um eigene Einstellungen und Dienste (Bild 1). Erschwerend kommt hinzu: All diese Tools und Erweiterungen bringen wieder eigene Software in eigenen Containern mit, die ebenfalls zumindest zu überwachen ist, wenn es um die Sicherheit geht.

Noch gar keine Erwähnung haben dabei Tools gefunden, die Sie über andere Wege in Ihre Installationen packen. Es existiert ja auch noch der Paketmanager Helm, der die einfache Installation von Software verspricht, dabei aber selbst aus Software besteht, die potenziell anfällig für Probleme in Sachen Security ist. Und wohlgemerkt: All diese Herausforderungen kommen in einem Kubernetes-Cluster zu jenen hinzu, die mit den normalen Systemen ohnehin einhergehen. Die Container laufen nicht im luftleeren Raum – sie benötigen Standard-Linux-Systeme mit Laufzeitumgebung, die ebenfalls wieder Sicherheitsprobleme und Fehleinstellungen aufweisen können. Zwar geht der Trend dahin, in Container-Umgebungen das Host-System zum "Container-Abspieler" zu degradieren. Ein Linux-Kernel und ein grundlegendes Set an Userland-Software ist aber auch hier involviert – und bereitet dem Admin Sorgen in Sachen Sicherheit.

Kubescape also tritt nun mit dem erklärten Ziel an, Ihnen in dieser komplexen Gemengelage auf Grundlage definierter Best Practices die Arbeit zu erleichtern und Ihre gesamte Umgebung komplett automatisch zu durchleuchten. Das Funktionsprinzip ist dabei einfach: Sie laden das Werkzeug herunter, und zur Abwechslung muss Kubescape zur Wahrnehmung seiner Aufgabe mal nicht als eigene Komponente innerhalb von Kubernetes laufen. Es funktioniert rein extern und setzt sich damit nicht der Kritik aus, die viele andere Kubernetes-Werkzeuge trifft: dass es nämlich nur die Sicht "von innen" sieht und Probleme außerhalb der Kubernetes-Welt gar nicht erkennen kann.

Kubescape scannt tatsächlich alles – Ressourcen in Kubernetes, genutzte Container-Abbilder aber eben auch die Systemkonfiguration der Host-Systeme und dort eventuell installierte Software. Am Ende eines Laufs zeigt es eine Übersicht der gefundenen Sicherheits- und Compliance-Probleme an. Dabei sortiert es seine Erkenntnisse nach ihrer Bedrohlichkeit: Eindeutige, dringende Sicherheitsprobleme werden in rot dargestellt und stehen auf der Ergebnisliste ganz oben. Ergebnisse, bei denen Kubescape nicht ganz sicher ist, die aber – wenn sie zutreffen – ebenfalls problematisch wären, zeigt das Werkzeug in der Mitte der Liste in gelb an. Weniger wichtige Einträge folgen am Ende.

Obendrein setzt Kubescape auf ein Punktesystem: Für jedes gefundene Problem vergibt es einen Punktwert. Übersteigt der Punktwert einer Installation einen festgelegten Grenzwert, schlägt Kubescape Alarm und fordert Sie so zum Handeln auf. Kritische Sicherheitslücken sorgen in der Standardkonfiguration dabei stets dafür, dass der errechnete Punktwert die Meldungsgrenze durchbricht. Wer sich bei diesem Prinzip stark an InSpec von Chef erinnert fühlt, liegt richtig. Es wäre durchaus legitim, Kubescape als einen Technikzwilling von InSpec zu bezeichnen, der auf den Einsatz in Kubernetes-Umgebungen spezialisiert ist.

Grau ist bekanntlich alle Theorie, Kubescape aber muss natürlich praktisch zum Einsatz kommen. Und das ist gar nicht so kompliziert, wie es angesichts des beschriebenen Funktionsumfangs vielleicht erwartbar wäre. Für einen glatten Start gelten lediglich ein paar Bedingungen, die Ihre Arbeitsumgebung erfüllen muss. Die erste Bedingung erklärt sich dabei fast von selbst: Vom System aus, auf dem Sie Kubescape ausführen möchten, müssen Sie Zugriff auf die gesamte K8s-Instanz haben. Es empfiehlt sich hier, falls noch nicht vorhanden, so etwas wie eine "Cluster-Workstation" zu konstruieren, die an den gesamten Kubernetes-Cluster und an die Host-Systeme herankommt.

Vielerorts wetteifern die IT- und Sicherheitsabteilungen leider darum, Setups hinter möglichst vielen absurden Firewallkonstrukten zu verstecken; zum Teil umfasst das sogar Firewalls zwischen den einzelnen Systemen einer Umgebung. Falls das im Einzelfall zutrifft, ist es möglicherweise nötig, mehr als einen Host zu nutzen, um Scans durchzuführen. Und natürlich kann der Host für den Kubescape-Betrieb auch eine virtuelle Instanz sein. Wie Sie Kubescape installieren, hängt im Wesentlichen von Ihrer persönlichen Präferenz ab. Der einfachste Weg besteht darin, das Programm direkt von GitHub herunterzuladen. Das erledigt das Kommando

auf einem beliebigen Linux-System. Die Entwickler weisen allerdings ausdrücklich darauf hin, dass es sich bei Kubescape um eine Lösung mit Sicherheitsbezug handelt. Schon aus Compliance-Gründen sollten Sie das referenzierte Shell-Skript also besser zunächst herunterladen und studieren, bevor Sie es ausführen. Alternativ stehen für etliche Linux-Distributionen fertige Pakete bereit. Wer Kubescape beispielsweise auf einem aktuellen Ubuntu-System ausführen möchte, findet komplette Pakete in einem Launchpad-PPA-Verzeichnis.

sorgen dafür, dass dieses Verzeichnis auf dem System aktiviert ist, und installieren auch das für Kubescape benötigte Paket. Bei dieser Vorgehensweise finden Updates in Launchpad automatisch ihren Weg in die eigene Installation. Das ist bei der zuvor beschriebenen Variante mit Shell-Skript nicht der Fall.

Eine Art Mittelweg ist für RHEL nötig, denn für dieses bieten die Entwickler kein nutzbares Repository an, zumindest aber fertige RPM-Pakete. Unter [2] finden sich diese; sie sind danach mittels "dnf" installierbar. Auch hier trifft Sie allerdings die Verantwortung, sich um Updates selbst zu kümmern.

Ist Kubescape auf dem lokalen System startklar, sollte der bloße Aufruf von kubescape einen entsprechenden Hilfetext auf den Bildschirm holen. Ohne weitere Vorbereitung würden Sie nun beim Aufruf des Scan-Kommandos kubescape scan --verbose allerdings eine Fehlermeldung sehen. Denn damit Kubescape einen Kubernetes-Cluster untersuchen kann, muss es dessen Knoten kennen und auf diesen natürlich auch Zugriff haben. Vorbildlich haben die Kubescape-Entwickler dies implementiert, indem sie dieselbe Clusterkonfiguration verwenden, die auch für "kubectl" zum Einsatz kommt – also dem Hauptverwaltungswerkzeug für K8s überhaupt. Haben Sie sich allerdings wie empfohlen einen eigenen Host für den Kubescape-Betrieb eingerichtet, fehlt eben diese Konfiguration dort vermutlich.

Das Problem ist aber schnell in den Griff zu kriegen. Wer schon ein System hat, auf dem "kubectl" funktioniert, kopiert von dort einfach den gesamten Ordner "~/.kube/" auf den Kubescape-Host. Darin liegt dann auch "~/.kube/config", die die Zugangsdaten für Kubernetes enthält. Die "Kubeconfig", so der Name der Datei, produziert K8s zumindest beim initialen Setup des Clusters einmal (Bild 2), bei bestehenden K8s-Systemen ist sie zumindest also auf jenem Host zu finden, von dem aus das Setup von Kubernetes erledigt wurde.

Werkzeuge wie OpenShift geben die "kubectl"-Konfiguration beim eigenen Setup oft auch auf dem Bildschirm aus und ermöglichen so, sie unabhängig zu sichern. Die Chancen stehen grundsätzlich gut, dass die Datei auf einem System vorhanden ist, wenn der Aufruf von kubectl cluster-info funktioniert. Übrigens: "kubectl" sollte auch auf dem Host vorhanden sein, von dem aus Sie kubescape später aufrufen. Wie das zu bewerkstelligen ist, erklären die K8s-Entwickler in einer eigenen Anleitung [3]. In den meisten Fällen genügt es jedoch, das Paket "kubectl" über die Paketverwaltung der eigenen Distribution zu installieren.

Danach beginnen Sie, mittels Kubescape nach Problemen in Sachen Sicherheit und Compliance zu suchen. Das Kommando kubescape scan --verbose setzt einen umfangreichen Scan in Gang, der die Zielinstanz von K8s nach sämtlichen enthaltenen Regelwerken überprüft. Darin enthalten sind wie beschrieben MITRE- und NSA-Frameworks sowie einige Regeln des Kubescape-eigenen Regelwerks. Hat das Programm seine Arbeit beendet – je nach Umfang der Installation kann das eine ganze Weile dauern – zeigt es eine Tabelle mit den gesammelten Erkenntnissen an. Deren Interpretation ist für das ungeübte Auge allerdings gar nicht so leicht, wie man es erwarten oder sich wünschen würde.

Die in Bild 3 dargestellte Tabelle unterteilt sich zunächst in fünf Spalten. Die erste ist leicht: Sie erklärt die Schwere eines gefundenen Problems oder einer festgestellten Abweichung vom Compliance-Regelwerk. Ganz grundsätzlich gilt: Tauchen hier Einträge auf, die als "Critical" oder "High" klassifiziert sind, ist erhöhte Achtsamkeit und üblicherweise auch schnelles Eingreifen nötig. Spalte 2 verrät Ihnen die Bezeichnung des durchgeführten Tests. Hier müssen Sie ein Gefühl für die Arbeit mit Kubescape entwickeln. Denn auf den ersten Blick ist oft nicht klar zu erkennen, ob es sich um ein Compliance- oder ein Sicherheitsproblem handelt.

Immerhin: Stellt Kubescape ein Problem fest, das eine CVE-Nummer hat, nutzt es diese üblicherweise auch im "Control Name". Die Bezeichnung "Control Name" leitet sich übrigens von der Tatsache ab, dass einzelne Prüfpunkte im Kontext von Compliance-Zertifizierungen üblicherweise ebenfalls als Control bezeichnet werden [4]. Vorbildlich ist bei Kubescape, dass die meisten Controls sprechende Namen haben. "Disable anonymous access to Kubelet Service" etwa informiert Sie verständlich über das Problem ("Anonymer Zugriff auf das Kubelet ist erlaubt") und liefert gleich die passende Handlungsanweisung mit.

Die beiden folgenden Spalten "Failed Resources" und "All Resources" lösen hingegen regelmäßig Stirnrunzeln aus. Das ist eigentlich gar nicht nötig – in der Spalte "All Resources" listet Kubescape nämlich die Ressourcen in einem Kubernetes-Cluster auf, die es überprüft hat. Die Spalte "Failed Resources" führt die Submenge der insgesamt überprüften Dienste auf, die Kubescape im Kontext eines bestimmten Control-Eintrags als "non-compliant" erkannt hat. Die Krux bei der Sache: Nicht jedes Kubescape-Control bezieht sich ausschließlich auf Ressourcen in Kubernetes. So kann es vorkommen, dass Kubescape kritische Fehler findet, sowohl bei "Failed Resources" als auch bei "All Resources" aber "0" anzeigt, wie im Beispiel des anonymen Zugriffs auf "kubelet". Dann handelt es sich eben nicht um Fehler, die einzelnen Ressourcen in K8s zuzuordnen sind, sondern entweder um Fehler von Komponenten der K8s-Infrastruktur selbst oder um Meta-Checks. Schlagen etwa zu viele Tests für Controls der Kategorie "Medium" fehl, zeigt Kubescape dafür eine eigene Warnung an.

Die letzte Spalte schließlich informiert Sie über den Compliance-Score einer Umgebung im Hinblick auf bestimmte Controls. Zeigt das Werkzeug im Feld "Compliance Score" keinen Prozentwert an, sondern lediglich "Action Required", ist das eine unmittelbare Handlungsaufforderung an Sie. Ansonsten steht hier eine Prozentzahl, die angibt, wie viele der getesteten Ressourcen in Kubernetes den Vorgaben entsprechen. Oberhalb der Tabelle liefert Kubescape zudem eine Übersicht, darunter eine genauere Darstellung der Compliance-Erfüllung im Hinblick auf die genutzten Regelwerke, also MITRE und NSA sowie die Kombination der beiden.

Wer mit dem tabellarischen Ausgabeformat von Kubescape nichts anfangen kann, verlängert über den Parameter "--format" das Ausgabeformat. Zur Auswahl steht JSON (kubescan scan --format json --format-version v2 --output results.json2) ebenso wie PDF (kubescan scan --format pdf --output results.pdf) oder HTML (kubescan scan --format html --output results.html). Soll Kubescan auch die Ressourcen auflisten, die alle Tests bestanden haben, ermöglicht dies der angehängte Parameter "--verbose".

Zusätzlich lässt Kubescape sich auch außerhalb eines laufenden Kubernetes-Clusters nutzen, um Ressourcen bereits zu überprüfen, noch bevor sie ihren Weg in den Cluster finden. Wer beispielsweise einen lokalen Ordner voller YAML- oder JSON-Dateien hat, die per kubectl apply später in Kubernetes landen sollen, überprüft diese mit kubescape scan *.yaml oder kubescape scan *.jsondirekt im entsprechenden Ordner auf der Kommandozeile. Derselbe Trick funktioniert mit einem lokalen Ordner voller Helm-Charts, die Sie kubescape scan einfach ebenfalls als Parameter übergeben.

Kubescape ist ein mächtiges Werkzeug, um laufende Kubernetes-Instanzen und noch gar nicht im Cluster aktive Ressourcen effizient zu überwachen. Es ermöglicht, die hochkomplexe Welt von Kubernetes deutlich sicherer zu durchsegeln, als es ohne Kubescape der Fall wäre. Denn Kubernetes besteht aus so vielen Schichten und Ebenen und möglichen Anbauteilen, dass der Admin ohne automatische Hilfe in seinem Werkzeugkasten kaum den Überblick über alle zu überprüfenden Faktoren behalten kann. Mit Kubescape ist das kein Problem, denn der am Ende eines Scans gezeigte Report vermittelt einen schnellen Eindruck dessen, was zu tun ist. Weil die Software unter freier Lizenz steht und kostenlos verfügbar ist und sich zudem schnell in Betrieb nehmen lässt, sollte es zum Standardrepertoire jedes Unternehmens gehören, das Kubernetes nutzt oder sogar selbst in der eigenen Infrastruktur betreibt.