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

Für den Start wird Folgendes benötigt:

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

Zusätzlich verwendet das Tutorial unten ein GitLab-Projekt, das in eine GitLab-Gruppe geforkt werden kann, wo entsprechende Permissions vorhanden sind, um die folgenden Schritte durchzuführen.

Sample-Applikation deployen

Die erste Aktion ist das Deployment einer Sample-Applikation auf dem Kubernetes-Cluster für dieses Tutorial. Vor Ausführung des kubectl-Commands zum Deployment der Sample-Applikation ist sicherzustellen, dass KUBECONFIG auf den gewünschten Cluster gesetzt ist. Nach erfolgter Einrichtung für den Cluster den folgenden Command ausführen:

$ 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, bis alle Pods im go-web-server-dev-Namespace laufen, durch Ausführung des folgenden Commands:

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

Output ähnlich dem unten gezeigten sollte erscheinen:

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, kann das geforkte GitLab-Projekt eingerichtet werden, um es mit dem Kubernetes-Cluster zu verbinden und die Operational-Container-Scanning-Properties zu konfigurieren.

Kubernetes-Cluster verbinden

Dieser Abschnitt zeigt, wie ein Kubernetes-Cluster über den GitLab Agent für Kubernetes mit dem GitLab-Projekt verbunden wird. Durch Konfiguration und Installation des Agent auf dem Kubernetes-Cluster lässt sich auch Operational Container Scanning konfigurieren.

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

Im geforkten GitLab-Projekt die id-Property in der config.yaml-Datei ändern, um sie mit der Gruppe abzugleichen, in die das Projekt geforkt wurde. Dadurch wird der GitLab Agent für Kubernetes konfiguriert, um Informationen über den Cluster zurück zum GitLab-Projekt zu übergeben. Diese Änderung in den Main-Branch des geforkten Projekts committen und pushen.

Zur Kubernetes-Clusters-Page des Projekts navigieren

In der GitLab-UI den Tab Operate > Kubernetes clusters des geforkten Projekts wählen. Den Button Connect a cluster (agent) klicken. Den Namen des Agent zur Input-Box unter Option 2: Create and register an agent with the UI hinzufügen und dann Create and register klicken. In diesem Fall ist der Name des Agent k8s-agent, da der Folder unter agents mit der config.yaml-Datei k8s-agent heißt. Zu beachten ist, 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 wird ein helm-Command angezeigt, der in der GitLab-UI zu sehen ist und von der Command-Line gegen den Kubernetes-Cluster auszuführen ist. Vor Ausführung des Commands sicherstellen, dass KUBECONFIG noch mit dem gleichen Cluster verbunden ist, auf dem die Sample-Applikation deployed wurde.

Nach erfolgreicher Ausführung des helm-Commands warten, bis alle Pods im gitlab-agent-k8s-agent-Namespace auf dem Cluster laufen. Das Warten kann mit folgendem Command erfolgen:

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

Ähnlicher Output wie unten gezeigt sollte erscheinen:

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 das GitLab-Projekt mit dem Kubernetes-Cluster verbunden sein und bereit, das Operational-Container-Scanning-Feature zu nutzen. Vor dem Fortfahren den kubectl get pods -n gitlab-agent-k8s-agent -w-Command weiterhin ausführen, 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 schließlich ein weiterer Pod namens trivy-scan-go-web-server-dev erscheinen. 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 für die Einrichtung des GitLab-Agent für Kubernetes auf dem Cluster verwendet wird.

Die zwei Haupt-Properties sind cadence, welches die Häufigkeit der Container-Vulnerability-Scans spezifiziert, und die namespaces-Property, die unter vulnerability_report verschachtelt ist und einen oder mehrere Namespaces definiert, auf denen der Scan durchgeführt werden soll. Die Konfiguration in config.yaml sieht wie folgt aus:

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 im go-web-server-dev-Namespace werden zurück zum GitLab-Projekt gesendet. Um die Ergebnisse zu sehen, in der GitLab-UI das geforkte Projekt wählen. Die Option Secure > Vulnerability report für das Projekt wählen 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 Image-Tags, um die Version der deployed Software zusammen mit der Umgebung einzuschließen, lassen sich systematisch die bekannten Vulnerabilities in den Kubernetes-Umgebungen auditieren und tracken, wie diese 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.

Das folgende Demo zeigt weitere Informationen:

Feedback teilen

Das Hinzufügen von GitLabs Operational Container Scanning zu 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.

Feedback zu Operational Container Scanning kann in diesem Forum-Post geteilt werden, der mit den Product- und Engineering-Teams geteilt wird, die dieses Feature supporten. Der Start mit Operational Container Scanning erfolgt durch Lesen der Dokumentation zum Feature und Starten einer kostenlosen Testversion von GitLab Ultimate.