Die Sicherheit spielt beim Einsatz von Containern eine besonders wichtige Rolle. Das Open-Source-System Kubernetes hat sich zum Standard bei der Automatisierung, Bereitstellung, Skalierung und Verwaltung von Container-Anwendungen entwickelt und erfordert deshalb besonderes Augenmerk bei der Sicherheit.
In diesem Artikel haben wir einen kleinen Leitfaden zusammengestellt, wie Ihr Kubernetes betreiben könnt und welche Aspekte dabei zu berücksichtigen sind.
Sicherheitsscanner: Was für Arten gibt es überhaupt?
Sicherheitsscanner ist ein Sammelbegriff für Programme die Prüfungen im Sicherheitsbereich durchführen. Im Allgemeinen unterteilt man diese in drei Kategorien.
Schwachstellen Scanner
Schwachstellen Scanner sind vielleicht die bekanntesten Vertreter der Sicherheitsscanner. Sie prüfen auf bekannte Schwachstellen und liefern im besten Fall weitere Informationen zu der Schwachstelle und ob es schon eine neuere Version mit einem Fix gibt. Diese Scanner können in der Regel Container Images scannen oder auch laufende Betriebssysteme. Schwachstellenscanner nutzen klassisch die Betriebssystem Paketinformationen als Datenquelle, doch immer mehr Scanner können auch Programmiersprachen eigene Installationssysteme wie npm oder Go Libraries erkennen und nutzen.
Secret Scanner
Die Secret Scanner sollen verhindern, dass in einem Repository API Keys oder Passwörter im Klartext eingecheckt werden. Dies wird meist im Bereich von Infrastruktur as Code (IaC) Daten genutzt, oder auch bei klassischen Entwicklungsdaten. Gerade bei diesem Anwendungsfall wird klar, dass diese Art von Scan so früh wie möglich im Entwicklungsprozess zu nutzen um den Aufwand, um Secrets aus einem Repo zu entfernen, so gering wie möglich zu halten.
Best-Practice Scanner
Hier ist der Einsatzzweck ganz klar auf IAC Dateien gerichtet. So soll möglichst früh erkannt werden, ob Best Practices eingehalten werden und Fehlkonfiguration vermieden werden. Was kann man sich darunter vorstellen? Ein einfaches Beispiel ist, bei der Prüfung von Dockerfiles ob ein anderer User als root genutzt wird, oder im Kubernetes Umfeld ob die Versionen der genutzten Images gepinnt sind oder der Tag latest, bzw. gar kein Tag verwendet wird.
Warum ist es sinnvoll Sicherheitsscanner zu benutzen?
Die Nutzung der verschiedenen Scanner zielt eigentlich immer auf zwei Anwendungsszenarien ab. Bei bestehenden Infrastrukturen und Repositories kann geprüft werden ob bisher alles in Ordnung ist, oder Verbesserungen ratsam sind, z.B. weil API Keys im Repository eingecheckt wurden. Gleichzeitig lassen sich die gleichen Scanner auch nutzen um in den bestehenden Entwicklungsprozess integriert zu werden und so dafür zu sorgen, dass in Zukunft solche Probleme gar nicht mehr entstehen können. Durch diese Verlagerung, of auch "shift left" genannt, wird die Qualität des Prozesses und der Ergebnisse erhöht. Bei Container Images ist es ebenfalls ratsam diese schon vor dem pushen in eine Registry auf Schwachstellen zu prüfen, damit man bei der Auslieferung einen möglichst guten Stand ohne bekannte Schwachstellen hat. Jede Schwachstelle und jedes Problem das gar nicht erst ausgerollt wird, erspart natürlich im Nachgang Aufwand um selbiges zu beheben. Natürlich müssen auch bestehende Konfigurationen oder laufende Images zyklisch geprüft werden, da in der Zwischenzeit neue Schwachstellen bekannt geworden sein können, oder durch manuelle Eingriffe z. B. Konfigurationen in einem Kubernetes Cluster verändert worden sein können.
Zusammengefasst lässt sich also sagen, dass die Scanner helfen mit möglichst guten Vorraussetzungen Neuerungen in die Produktion zu bringen und die laufende Umgebung kontinuierlich zu verbessern und zu überwachen.
Welchen Scanner nutzen wir?
Wir haben uns für trivy einen Open Source Scanner von Aqua Security entschieden. Die Vorteile liegen für uns ganz klar in zwei Bereichen. Erstens handelt es sich um eine Open Source Lösung die aktuell sehr stark weiterentwickelt wird mit einer aktiven Community. Zweitens deckt dieses Programm alle beschriebenen Einsatzzwecke ab, so dass wir nur ein Tool nutzen und beherrschen müssen. Die Dokumentation ist umfangreich und gut verständlich, was ein weiterer Pluspunkt für uns war.
Wie nutzen wir trivy?
Wir nutzen trivy Hauptsächlich in unseren CI/CD Pipelines und mittels Starboard Operator in unseren Kubernetes Umgebungen. Diese Kombination ermöglicht uns das oben beschriebene Vorgehen sowohl die Sachen zu prüfen die deployed werden sollen und zur Laufzeit zu überwachen, ob neue Schwachstellen in den laufenden Container z. B. ergeben haben. Durch die Nutzung des Starboard Operators können wir Metriken über die verschiedenen Scans direkt in Prometheus nutzen und werden über Veränderungen informiert oder alarmiert.
Beispiele
Schwachstellen Scanner bei Container Images
Wir nutzen trivy als Schwachstellen Scanner beim Bau unserer eigenen Container Images. Dabei prüfen wir nicht nur die Softwarepakete sondern erstellen auch eine Übersichtsdatei über alle Versionen und Lizenzen in einer "Software Bill of Materials" sbom Datei.
before_script: # Feststellung der aktuellen Version von trivy danach wird diese ausgegeben und heruntergeladen - export TRIVY_VERSION=$(wget -qO - "https://api.github.com/repos/aquasecurity/trivy/releases/latest" | grep '"tag_name":' | sed -E 's/.*"v([^"]+)".*/\1/') - echo $TRIVY_VERSION - wget --no-verbose https://github.com/aquasecurity/trivy/releases/download/v${TRIVY_VERSION}/trivy_${TRIVY_VERSION}_Linux-64bit.tar.gz -O - | tar -zxvf - function deploy_with_trivy_check() { docker login -u "$USERNAME" -p "$PASSWORD" $REGISTRY DOCKER_BUILDKIT=1 docker build --pull --no-cache -t $NAME:$TAG docker tag $NAME:$TAG $NAME:latest # Gitlab Report erstellen ./trivy image --exit-code 0 --format template --template "@contrib/gitlab.tpl" -o gl-container-scanning-report.json $NAME:$TAG # HTML Report erstellen ./trivy image --exit-code 0 --format template --template "@contrib/html.tpl" -o $TAG-scanning-report.html $NAME:$TAG # Ausgabe eines Reports mit Kritikalität Hoch eingestuften Schwachstellen ./trivy image --exit-code 0 --severity HIGH --ignore-unfixed $NAME:$TAG # Abbruch bei kritischen Schwachstellen mit existierendem Patch ./trivy image --exit-code 1 --ignore-unfixed --severity CRITICAL $NAME:$TAG # Erstellung der sbom Datei ./trivy image --format cyclonedx -o sbom-$NAME.json $NAME:$TAG docker push --all-tags $1} Nutzung per CLI zum Testen
Miskonfigurationscheck am Beispiel eines Dockerfiles
$ trivy config .2022-08-18T15:23:27.481+0200 INFO Misconfiguration scanning is enabled2022-08-18T15:23:27.682+0200 INFO Detected config files: 1Dockerfile (dockerfile)Tests: 22 (SUCCESSES: 21, FAILURES: 1, EXCEPTIONS: 0)Failures: 1 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 1, CRITICAL: 0)HIGH: Specify at least 1 USER command in Dockerfile with non-root user as argument Running containers with 'root' user can lead to a container escape situation. It is a best practice to run containers as non-root users, which can be done by adding a 'USER' statement to the Dockerfile.See https://avd.aquasec.com/misconfig/ds002 Prüfung eines Images, wobei nur Schwachstellen berücksichtigt werden sollen, für die es einen Fix gibt
Prüfung eines Kubernetes Namespaces
Beispiel für das finden von Zugangsdaten:
Beispiel für den Scan eines Repositories
Fazit
Mit trivy haben wir ein universelles Programm, welches nicht nur als automatisierter Bestandteil von CI/CD Pipelines und Kubernetesumgebungen einen wichtigen Beitrag zur Sicherheit des betrieben Workloads beiträgt. z. B. auf dem Arbeitsplatz des Admins oder des Entwicklers ist es durch seine einfache Handhabung eine gute Option für den eigenen Werkzeugkasten. Je früher und je häufiger Sicherheitsscanner eingesetzt werden, umso weniger Aufwand bringt es mit sich, sollte es doch zu Funden kommen.
