Sicherheitsüberprüfung mittels GitLab Operational Scanning

Security-Scans sind regulärer Bestandteil jedes Software-Entwicklungsprozesses. Ob beim Scannen von Source-Code (beispielsweise Java oder Python), Konfigurationsdateien (beispielsweise YAML) oder Container-Images – diese Scanning-Tools helfen Entwicklungsteams, Security-Threats systematisch zu verstehen und zu adressieren.

Traditionell führen Entwickler diese Security-Scans als Teil von CI/CD-Pipelines durch. Durch Integration dieser Scans in CI/CD wird jede Änderung an einem Projekt überprüft, um zu sehen, ob Vulnerabilities eingeführt werden. Das Verständnis von Security-Concerns während der Entwicklung trägt dazu bei, dass Änderungen adressiert werden, bevor sie in eine Live-Umgebung deployed werden. Container-Vulnerability-Scans nach dem Deployment bieten jedoch weitere Vorteile: Die automatisierten Scans laufen unabhängig vom Merge-Request-Prozess und erfordern keine Code-Änderungen, um ausgeführt zu werden. Dies gewährleistet kontinuierliche Überwachung auch für stabile Production-Umgebungen, in denen selten Deployments stattfinden.

GitLabs Operational Container Scanning-Feature ermöglicht DevSecOps-Praktikern, Container-Vulnerability-Scans gegen Container in Kubernetes-Umgebungen durchzuführen. Die Vorteile von Vulnerability-Scans auf deployed Containern umfassen regelmäßiges Scannen der Images auf neu entdeckte Vulnerabilities, Tracking, in welchen Umgebungen bestimmte Vulnerabilities deployed sind, sowie Tracking des Fortschritts bei der Behebung dieser Vulnerabilities.

Die Scans können konfiguriert werden, um in regelmäßigen Intervallen auf Containern in spezifischen Namespaces eines Kubernetes-Clusters zu laufen. Die Ergebnisse dieser Scans werden zurück zu GitLab-Projekten gesendet und können über die GitLab-UI angezeigt werden. Um zu demonstrieren, wie das Feature genau funktioniert, zeigen die nächsten Schritte in diesem Artikel, wie das Operational-Container-Scanning-Feature mit einem GitLab-Projekt, einer Sample-Applikation und einem Kubernetes-Cluster angewendet wird.

Für deutsche Unternehmen ist dieser Ansatz besonders relevant im Kontext regulatorischer Anforderungen: Die kontinuierliche Überwachung laufender Container unterstützt Compliance-Vorgaben wie ISO 27001 A.12.6.1 (technisches Schwachstellenmanagement), DSGVO Artikel 32 (angemessene technische Maßnahmen zur Verarbeitungssicherheit) und BSI Grundschutz SYS.1.6 (Container-Sicherheit). Für kritische Infrastrukturen gemäß NIS2-Richtlinie ist Runtime-Monitoring obligatorisch. In deutschen Enterprise-Umgebungen wird das Feature typischerweise mit selbstverwalteten Kubernetes-Distributionen wie OpenShift oder Rancher eingesetzt, wobei GitLab Self-Managed die vollständige Kontrolle über Scan-Daten und -Ergebnisse gewährleistet.

Prerequisites

Um zu starten, benötigen Sie Folgendes:

• GitLab-Ultimate-Account
• Kubernetes-Cluster, der GitLabs Kubernetes-Versionsanforderungen erfüllt
• kubectl CLI
• helm CLI

Zusätzlich verwendet die Walkthrough unten ein GitLab-Projekt, das in eine GitLab-Gruppe geforkt werden kann, in der Sie entsprechende Permissions haben, um die folgenden Schritte durchzuführen.

Sample-Applikation deployen

Die erste Aktion ist das Deployment einer Sample-Applikation auf dem Kubernetes-Cluster, den Sie in diesem Tutorial verwenden werden. Bevor Sie den kubectl-Command zum Deployment einer Sample-Applikation ausführen, stellen Sie sicher, dass Ihr KUBECONFIG auf den Cluster gesetzt ist, den Sie verwenden möchten. Sobald Sie für Ihren Cluster eingerichtet sind, führen Sie folgenden Command aus:

$ kubectl apply -f https://gitlab.com/gitlab-da/tutorials/cloud-native/go-web-server/-/raw/main/manifests/go-web-server-manifests.yaml

namespace/go-web-server-dev created
deployment.apps/go-web-server created
service/go-web-server created

Warten Sie, bis alle Pods im go-web-server-dev-Namespace laufen, indem Sie folgenden Command ausführen:

$ kubectl get pods -n go-web-server-dev -w

Sie sollten Output ähnlich dem unten gezeigten sehen:

NAME                            READY   STATUS    RESTARTS   AGE
go-web-server-f6b8767dc-57269   1/1     Running   0          18m
go-web-server-f6b8767dc-fkct2   1/1     Running   0          18m
go-web-server-f6b8767dc-j4qwg   1/1     Running   0          18m

Sobald alles läuft, können Sie Ihr geforktes GitLab-Projekt einrichten, um es mit Ihrem Kubernetes-Cluster zu verbinden und die Operational-Container-Scanning-Properties zu konfigurieren.

Kubernetes-Cluster verbinden

In diesem Abschnitt lernen Sie, wie Sie einen Kubernetes-Cluster über den GitLab Agent für Kubernetes mit Ihrem GitLab-Projekt verbinden. Durch Konfiguration und Installation des Agent auf Ihrem Kubernetes-Cluster können Sie auch Operational Container Scanning konfigurieren.

id-Property für GitLab Kubernetes-Agent ändern

Im geforkten GitLab-Projekt, das Sie verwenden, ändern Sie die id-Property in der config.yaml-Datei, um sie mit der Gruppe abzugleichen, in die Sie das Projekt geforkt haben. Dadurch konfigurieren Sie den GitLab Agent für Kubernetes, um Informationen über Ihren Cluster zurück zu Ihrem GitLab-Projekt zu übergeben. Stellen Sie sicher, dass Sie diese Änderung in den Main-Branch des geforkten Projekts committen und pushen.

Zur Kubernetes-Clusters-Page des Projekts navigieren

Wählen Sie in der GitLab-UI den Tab Operate > Kubernetes clusters des geforkten Projekts. Klicken Sie den Button Connect a cluster (agent). Fügen Sie den Namen des Agent zur Input-Box unter Option 2: Create and register an agent with the UI hinzu und klicken Sie dann Create and register. In diesem Fall ist der Name des Agent k8s-agent, da der Folder unter agents mit der config.yaml-Datei k8s-agent heißt. Beachten Sie, dass dieser Folder jeden Namen haben kann, der den Kubernetes-Naming-Restrictions folgt, und dass k8s-agent nur der Einfachheit halber verwendet wird.

GitLab-Kubernetes-Agent installieren

Nach Registrierung des Agent werden Sie aufgefordert, einen helm-Command, der in der GitLab-UI gezeigt wird, von Ihrer Command-Line gegen Ihren Kubernetes-Cluster auszuführen. Bevor Sie den Command ausführen, stellen Sie sicher, dass Ihr KUBECONFIG noch mit dem gleichen Cluster verbunden ist, auf dem Sie die Sample-Applikation deployed haben.

Nach erfolgreicher Ausführung des helm-Command warten Sie, bis alle Pods im gitlab-agent-k8s-agent-Namespace auf Ihrem Cluster laufen. Sie können warten, bis alles läuft, mit folgendem Command:

$ kubectl get pods -n gitlab-agent-k8s-agent -w

Sie sollten ähnlichen Output wie unten gezeigt sehen:

NAME                                         READY   STATUS    RESTARTS   AGE
k8s-agent-gitlab-agent-v2-6bb676b6bf-v4qml   1/1     Running   0          10m
k8s-agent-gitlab-agent-v2-6bb676b6bf-xt7xh   1/1     Running   0          10m

Sobald die Pods laufen, sollte Ihr GitLab-Projekt mit Ihrem Kubernetes-Cluster verbunden sein und bereit, das Operational-Container-Scanning-Feature zu nutzen. Bevor Sie fortfahren, führen Sie weiterhin den kubectl get pods -n gitlab-agent-k8s-agent -w-Command aus, um Konzepte im nächsten Abschnitt zu erklären.

Operational Container Scanning

Zusätzlich zu den Pods für den GitLab-Agent, die im gitlab-agent-k8s-agent-Namespace laufen, sollte es schließlich einen weiteren Pod namens trivy-scan-go-web-server-dev geben. Dieser Pod startet in den konfigurierten Intervallen, führt einen Container-Vulnerability-Scan mit dem Tool Trivy gegen den go-web-server-dev-Namespace durch und terminiert nach Abschluss des Scans. Alle Scan-Ergebnisse werden automatisch zurück zum GitLab-Projekt gesendet. Dieser Prozess läuft kontinuierlich und unabhängig von Entwicklungsaktivitäten.

Die Operational-Container-Scanning-Properties sind in der config.yaml-Datei definiert, die verwendet wird, um den GitLab-Agent für Kubernetes auf Ihrem Cluster einzurichten.

Die zwei Haupt-Properties, die zu definieren sind, sind cadence, welches spezifiziert, wie häufig der Container-Vulnerability-Scan ausgeführt werden soll, und auch die namespaces-Property, die unter vulnerability_report verschachtelt ist und einen oder mehrere Namespaces definiert, auf denen der Scan durchgeführt werden soll. Sie können sehen, wie dies in config.yaml unten aussieht:

container_scanning:
  cadence: '*/5 * * * *'
  vulnerability_report:
    namespaces:
      - go-web-server-dev

Die Cadence folgt einem Cron-Format. In diesem Fall bedeutet */5 * * * *, dass der Scan alle fünf Minuten ausgeführt wird – diese hohe Frequenz dient Demo-Zwecken. Für Production-Umgebungen sind typischerweise längere Intervalle sinnvoll (beispielsweise alle 12 oder 24 Stunden), abhängig von den Compliance-Anforderungen und der Änderungsrate der Container-Images. Die Konfiguration erfolgt über Configuration-as-Code, wodurch versionierte, nachvollziehbare Scan-Konfigurationen für Compliance-Audits ermöglicht werden.

Die durch den Scan aufgedeckten Vulnerabilities für Container, die im go-web-server-dev-Namespace laufen, werden zurück zu Ihrem GitLab-Projekt gesendet. Um die Ergebnisse zu sehen, gehen Sie zur GitLab-UI und wählen Sie Ihr geforktes Projekt. Wählen Sie die Option Secure > Vulnerability report für das Projekt und dann den Tab Operational vulnerabilities, um Scan-Ergebnisse anzuzeigen.

Die Scan-Ergebnisse enthalten Informationen über den Schweregrad der Common Vulnerabilities and Exposures (CVEs) zusammen mit dem Namen des Image und dem Cluster, auf dem die Vulnerability aktiv deployed ist. Durch Verwendung des Tags des Image, um die Version der deployed Software zusammen mit der Umgebung einzuschließen, können Sie systematisch auditieren, welche bekannten Vulnerabilities in Ihren Kubernetes-Umgebungen existieren, und tracken, wie sie von Engineering-Teams adressiert werden.

GitLab integriert die Scan-Ergebnisse direkt in das Issue-Tracking-System: Für jede identifizierte Vulnerability kann ein Follow-up-Issue erstellt oder der CVE-Kontext zu einem bestehenden Issue hinzugefügt werden. Dies ermöglicht systematisches Tracking der Vulnerability-Behebung über den gesamten Entwicklungszyklus hinweg und unterstützt Audit-Anforderungen durch vollständige Dokumentation des Behebungsprozesses.

Sehen Sie sich dieses Demo für weitere Informationen an:

Teilen Sie Ihr Feedback

Das Hinzufügen von GitLabs Operational Container Scanning zu Ihren Kubernetes-Umgebungen kann Entwicklungs-, Security- und Infrastruktur-Teams helfen, ein einheitliches Verständnis der Container-Security in Kubernetes-Umgebungen über die gesamte Organisation hinweg zu haben. Zusätzlich zu GitLabs CI-Container-Scanning-Capabilities und der Fähigkeit, Container zu scannen, die zu GitLabs Container-Registry gepusht werden, hat GitLab Lösungen in jeder Phase des Software-Development-Lifecycles, um Container-Security-Concerns zu adressieren.

Sie können Ihr Feedback zu Operational Container Scanning in diesem Forum-Post teilen, den wir mit unseren Product- und Engineering-Teams teilen werden, die dieses Feature supporten. Sie können mit Operational Container Scanning starten, indem Sie die Dokumentation zum Feature lesen und eine kostenlose Testversion von GitLab Ultimate starten.