Die Breaking Changes in GitLab 18.0

GitLab 18.0, unser nächstes Major Release, wird vollgepackt sein mit neuen Funktionen, die die Grenzen der DevSecOps-Innovation sprengen. Gleichzeitig werden wir einige veraltete Funktionen aus GitLab entfernen. Hier erfährst du, was du über diese Änderungen wissen musst und wie du ihre Auswirkungen minimieren kannst.

Inhaltsverzeichnis

• Bereitstellungsfenster
• GitLab.com
• GitLab Self-Managed
• GitLab Dedicated
• Breaking Changes
• Hohe Auswirkungen
• Mittlere Auswirkungen
• Geringe Auswirkungen
• Tools und Ressourcen, um deine Auswirkungen zu verwalten

Bereitstellungsfenster

GitLab.com

Breaking Changes für GitLab.com waren auf diese drei Zeitfenster beschränkt:

• 21.–23. April 2025
• 28.–30. April 2025
• 5.–7. Mai 2025

Viele weitere Änderungen werden im Laufe des Monats eingeführt. In dieser englischsprachigen Dokumentation zu den grundlegenden Änderungen erfährst du mehr über die wichtigsten Änderungen in jedem dieser Zeitfenster.

Hinweis: In Ausnahmefällen können Breaking Changes geringfügig außerhalb dieser Zeitfenster liegen.

GitLab Self-Managed

GitLab 18.0 ist ab dem 15. Mai verfügbar. Mehr über den Release-Zeitplan erfährst du hier (nur in englischer Sprache verfügbar).

GitLab Dedicated

Das Upgrade auf GitLab 18.0 findet während deines Wartungsfensters vom 24.–29. Juni 2025 statt. Mehr dazu erfährst du hier (nur in englischer Sprache verfügbar). Dort findest du auch dein zugewiesenes Wartungsfenster.

Wir haben außerdem spezielle Tools und Ressourcen entwickelt, die dir dabei helfen, die Auswirkungen der Änderungen auf deine Umgebung abzuschätzen und alle notwendigen Maßnahmen vor dem Upgrade auf 18.0 zu planen. Informationen zu diesen Tools und Ressourcen zur Risikominderung findest du weiter unten in diesem Artikel.

Auf der Seite zu veralteten Funktionen (nur in englischer Sprache verfügbar), findest du eine vollständige Liste der Komponenten, die in 18.0 entfernt werden sollen. Im Folgenden erfährst du, was auf dich zukommt und wie du dich auf die diesjährige Version vorbereiten kannst, je nachdem, welche Bereitstellung du verwendest.

Breaking Changes

Hohe Auswirkungen

1. CI/CD-Job-Token – Entfernung der Einstellung „Zugriff von deinem Projekt beschränken“

GitLab.com | Self-Managed | Dedicated

In GitLab 14.4 haben wir eine Einstellung eingeführt, um den Zugriff von den CI/CD-Job-Token (CI_JOB_TOKEN) deines Projekts zu beschränken (nur in englischer Sprache verfügbar) und so die Sicherheit zu erhöhen. Diese Einstellung wurde CI_JOB_TOKEN-Zugriff beschränken genannt. In GitLab 16.3 haben wir diese Einstellung aus Gründen der Übersichtlichkeit in Zugriff von diesem Projekt beschränken umbenannt.

In GitLab 15.9 haben wir die alternative Einstellung Autorisierte Gruppen und Projekte (nur in englischer Sprache verfügbar) eingeführt. Diese Einstellung steuert den Zugriff von Job-Token auf dein Projekt mithilfe einer Zulassungsliste. Diese neue Einstellung ist eine deutliche Verbesserung gegenüber der ursprünglichen Einstellung. Die erste Iteration wurde in GitLab 16.0 als veraltet markiert und soll in GitLab 18.0 entfernt werden.

Die Einstellung Zugriff von diesem Projekt beschränken ist für alle neuen Projekte standardmäßig deaktiviert. Ab GitLab 16.0 kannst du diese Einstellung nicht wieder aktivieren, nachdem sie in einem Projekt deaktiviert wurde. Verwende stattdessen die Einstellung Autorisierte Gruppen und Projekte, um den Zugriff von Job-Token auf deine Projekte zu steuern.

• Hinweis zur Deaktivierung (nur in englischer Sprache verfügbar)
• Überprüfung über GitLab Detective verfügbar

2. CI/CD-Job-Token – Durchsetzung der Zulassungsliste für autorisierte Gruppen und Projekte

GitLab.com | Self-Managed | Dedicated

Mit der Einstellung für autorisierte Gruppen und Projekte (nur in englischer Sprache verfügbar) (in GitLab 15.9 eingeführt und in GitLab 16.3 in Zugriff auf dieses Projekt beschränken umbenannt) kannst du den Zugriff von CI/CD-Job-Token auf dein Projekt verwalten. Wenn du Nur dieses Projekt und alle Gruppen und Projekte in der Zulassungsliste auswählst, können nur Gruppen oder Projekte, die der Zulassungsliste hinzugefügt wurden, Job-Token verwenden, um auf dein Projekt zuzugreifen.

• Vor GitLab 15.9 war die Zulassungsliste standardmäßig deaktiviert (Einstellung Alle Gruppen und Projekte (nur in englischer Sprache verfügbar)), sodass der Zugriff von Job-Token aus jedem Projekt möglich war.
• Seit GitLab 17.6 haben Administrator(inn)en von GitLab-Self-Managed- und Dedicated-Instanzen die Möglichkeit, eine sicherere Einstellung für alle Projekte zu erzwingen (nur in englischer Sprache verfügbar), die verhindert, dass Projektbetreuer(innen) Alle Gruppen und Projekte auswählen. Diese Änderung sorgt für ein höheres Maß an Sicherheit zwischen Projekten.
• In GitLab 18.0 ist diese Einstellung standardmäßig aktiviert. Auf GitLab.com werden wir die Zulassungslisten deiner Projekte automatisch auf der Grundlage deiner Projekt-Authentifizierungsprotokolle auffüllen.
• Um sich auf diese Änderung auf GitLab.com vorzubereiten, sollten Projektbetreuer(innen), die das Job-Token für die projektübergreifende Authentifizierung verwenden, die Zulassungslisten für Autorisierte Gruppen und Projekte ihres Projekts belegen. Sie sollten dann die Einstellung auf Nur dieses Projekt und Gruppen und Projekte in der Zulassungsliste ändern. Wir empfehlen die Verwendung der verfügbaren Migrationswerkzeuge (nur in englischer Sprache verfügbar), um die Erstellung der Zulassungsliste basierend auf den Authentifizierungsprotokollen (nur in englischer Sprache verfügbar) des Projekts vor GitLab 18.0 zu automatisieren.
• Benutzer(innen) von Self-Managed sollten die Zulassungslisten vor dem Upgrade auf 18.0 belegen.
• Dedicated-Benutzer(innen) sollten mit ihrem GitLab-Kontoteam zusammenarbeiten, um die geeignete Strategie für ihre spezifische Instanz zu entwickeln.

• Hinweis zur Deaktivierung (nur in englischer Sprache verfügbar)
• Dokumentation (nur in englischer Sprache verfügbar)
• Überprüfung über GitLab Detective verfügbar

3. Durchsetzung des Geltungsbereichs von Abhängigkeits-Proxy-Token

GitLab.com | Self-Managed | Dedicated

Der Abhängigkeits-Proxy für Container akzeptiert die Anfragen docker login und docker pull mit persönlichen, Projekt- oder **Gruppen-**Zugriffstoken, ohne deren Geltungsbereich zu validieren.

In GitLab 18.0 benötigt der Abhängigkeits-Proxy sowohl den Geltungsbereich read_registry als auch den Geltungsbereich write_registry für die Authentifizierung. Nach dieser Änderung werden Authentifizierungsversuche mit Token ohne diese Bereiche abgelehnt.

Erstelle vor dem Upgrade neue Zugriffstoken mit den erforderlichen Geltungsbereichen (nur in englischer Sprache verfügbar) und aktualisiere deine Workflow-Variablen und -Skripte mit diesen neuen Token.

Du hast auch die Möglichkeit, den Dependency Token Checker zu verwenden, ein von der Community entwickeltes Skript, mit dem du Token anzeigen und automatisch rotieren kannst.

• Hinweis zur Deaktivierung (nur in englischer Sprache verfügbar)

Mittlere Auswirkungen

1. Neue Fristen für die Datenaufbewahrung bei Sicherheitslücken auf GitLab.com

GitLab.com – nur für Kund(inn)en mit Ultimate-Tarif

Ab GitLab 18.1 werden wir mit einem schrittweisen, sechsmonatigen Rollout eine neue Frist für die Datenaufbewahrung für GitLab.com Ultimate-Kund(inn)en einführen, um die Systemleistung und -zuverlässigkeit zu verbessern. Die Datenaufbewahrungsfrist bestimmt, wie lange die Daten zu deinen Sicherheitslücken gespeichert werden.

Sicherheitslücken, die älter als 12 Monate sind und nicht aktualisiert wurden, werden automatisch in Cold-Storage-Archive verschoben. Diese Archive:

• bleiben über die GitLab-Benutzeroberfläche zugänglich und können heruntergeladen werden
• werden 3 Jahre lang aufbewahrt
• werden nach 3 Jahren endgültig gelöscht

• Hinweis zur Deaktivierung (nur in englischer Sprache verfügbar)
• Dokumentation (nur in englischer Sprache verfügbar)

2. Ablehnen von Pull-Richtlinien für Container-Images, die nicht in allowed_pull_policies enthalten sind

GitLab.com | Self-Managed | Dedicated

Alle konfigurierten Pull-Richtlinien sollten in der allowed_pull_policies-Konfiguration (nur in englischer Sprache verfügbar) vorhanden sein, die in der Datei config.toml des Runners angegeben ist. Wenn dies nicht der Fall ist, sollte der Job mit dem Fehler incompatible pull policy fehlschlagen.

Wenn in der aktuellen Implementierung mehrere Pull-Richtlinien definiert sind, werden Jobs übergeben, wenn mindestens eine Pull-Richtlinie mit den Richtlinien in allowed-pull-policies übereinstimmt, auch wenn andere Richtlinien nicht enthalten sind.

In GitLab 18.0 schlagen Jobs nur fehl, wenn keine der Pull-Richtlinien mit den in allowed-pull-policies angegebenen übereinstimmt. Im Gegensatz zum früheren Verhalten verwenden Jobs jedoch nur die in allowed-pull-policies aufgeführten Pull-Richtlinien. Diese Unterscheidung kann dazu führen, dass Jobs, die derzeit erfolgreich ausgeführt werden, in GitLab 18.0 fehlschlagen.

• Hinweis zur Deaktivierung (nur in englischer Sprache verfügbar)
• Dokumentation (nur in englischer Sprache verfügbar)

3. PostgreSQL 14 und 15 werden nicht mehr unterstützt

Self-Managed

GitLab folgt einem jährlichen Upgrade-Rhythmus für PostgreSQL (nur in englischer Sprache verfügbar).

Die Unterstützung für PostgreSQL 14 und 15 soll in GitLab 18.0 entfernt werden. Ab GitLab 18.0 ist PostgreSQL 16 die minimal erforderliche Version von PostgreSQL.

PostgreSQL 14 und 15 werden für den gesamten Release-Zyklus von GitLab 17 unterstützt. PostgreSQL 16 wird auch für Instanzen unterstützt, die vor GitLab 18.0 ein Upgrade durchführen möchten.

Um diese Änderung auf Instanzen vorzubereiten, die kein PostgreSQL-Cluster (nur in englischer Sprache verfügbar) verwenden (z. B. wenn du eine einzelne PostgreSQL-Instanz ausführst, die du mit einem Omnibus-Linux-Paket installiert hast), versuchen Upgrades auf GitLab 17.11, PostgreSQL automatisch auf Version 16 zu aktualisieren. Wenn du PostgreSQL-Cluster verwendest oder dich gegen dieses automatische Upgrade entscheidest (nur in englischer Sprache verfügbar), musst du manuell ein Upgrade auf PostgreSQL 16 durchführen, um ein Upgrade auf GitLab 18.0 durchführen zu können. Stelle sicher, dass du über genügend Speicherplatz verfügst, um das Upgrade durchzuführen.

• Hinweis zur Deaktivierung (nur in englischer Sprache verfügbar)
• Dokumentation (nur in englischer Sprache verfügbar)
• Migrationsrichtlinien (nur in englischer Sprache verfügbar)

4. Einstellung der Terraform-CI/CD-Vorlagen

Self-Managed

Die Terraform-CI/CD-Vorlagen werden eingestellt und in GitLab 18.0 entfernt. Dies betrifft die folgenden Vorlagen:

• Terraform.gitlab-ci.yml
• Terraform.latest.gitlab-ci.yml
• Terraform/Base.gitlab-ci.yml
• Terraform/Base.latest.gitlab-ci.yml

GitLab kann die Binärdatei terraform in den Job-Images nicht auf eine Version aktualisieren, die unter der BSL lizenziert ist.

Um Terraform weiterhin zu verwenden, klone die Vorlagen und das Terraform-Image und pflege sie nach Bedarf. GitLab bietet detaillierte Anweisungen für die Migration zu einem benutzerdefinierten Image.

Als Alternative empfehlen wir die Verwendung der neuen CI/CD-Komponente OpenTofu auf GitLab.com oder der neuen CI/CD-Vorlage OpenTofu in GitLab Self-Managed. CI/CD-Komponenten sind noch nicht für GitLab Self-Managed verfügbar. Ticket #415638 enthält jedoch den Vorschlag, diese Funktion hinzuzufügen. Wenn CI/CD-Komponenten auf GitLab Self-Managed verfügbar werden, wird die CI/CD-Vorlage OpenTofu entfernt.

Erfahre mehr über die neue CI/CD-Komponente OpenTofu.

• Hinweis zur Deaktivierung (nur in englischer Sprache verfügbar)

5. Wichtiges Update des Prometheus-Unterdiagramms

Self-Managed

Mit GitLab 18.0 und GitLab Chart 9.0 wird das Prometheus-Unterdiagramm von 15.3 auf 27.3 aktualisiert.

Zusammen mit diesem Update wird standardmäßig Prometheus 3 ausgeliefert.

Für das Upgrade sind manuelle Schritte erforderlich. Wenn du Alertmanager, Node Exporter oder Pushgateway aktiviert hast, musst du auch deine Helm-Werte aktualisieren.

Weitere Informationen findest du im Migrationsleitfaden (nur in englischer Sprache verfügbar).

• Hinweis zur Deaktivierung (nur in englischer Sprache verfügbar)

Geringe Auswirkungen

1. Pakete für SUSE Linux Enterprise Server 15 SP2 werden nicht mehr erstellt

Self-Managed

Die langfristige Unterstützung (LTSS) für SUSE Linux Enterprise Server (SLES) 15 SP2 endete im Dezember 2024.

Daher werden wir die SLES-SP2-Distribution für Linux-Paketinstallationen nicht mehr unterstützen. Du solltest ein Upgrade auf SLES 15 SP6 durchführen, um weiterhin Support zu erhalten.

• Hinweis zur Deaktivierung (nur in englischer Sprache verfügbar)

2. Entfernen des Gitaly-Ratenbegrenzers

Self-Managed

Gitaly unterstützte bisher RPC-basierte Ratenbegrenzung. Wir stellen diese Funktion ein, da sie nicht die gewünschten Ergebnisse erzielt. Weitere Informationen findest du im Ticket für die Deaktivierung.

Wenn Kund(inn)en den Ratenbegrenzer konfiguriert haben (der veraltet ist), wird kein Fehler zurückgegeben und die Konfiguration wird einfach ignoriert.

Kund(inn)en sollten stattdessen den Gleichzeitigkeitsgrenzwert (nur in englischer Sprache verfügbar) verwenden.

• Hinweis zur Deaktivierung (nur in englischer Sprache verfügbar)

3. Einstellung der Unterstützung für NGINX-Controller-Image 1.3.1

Self-Managed

Wir aktualisieren das Standard-NGINX-Controller-Image auf 1.11.2. Diese neue Version erfordert neue RBAC-Regeln und einige Benutzer(innen) setzen nginx-ingress.rbac.create: false, um ihre eigenen RBAC-Regeln zu verwalten.

Diese Benutzer(innen) müssen die RBAC-Regeln hinzufügen, bevor sie zu 1.11.2 oder höher migrieren. Wir haben einen Fallback-Mechanismus hinzugefügt, um 1.3.1 nur dann bereitzustellen, wenn dieser Helm-Wert wie oben festgelegt ist. Wir haben auch nginx-ingress.controller.image.disableFallback hinzugefügt, das standardmäßig auf „false“ gesetzt ist. Benutzer(innen), die ihr eigenes RBAC verwalten, können diesen Wert auf „true“ setzen, damit ihre Bereitstellungen auch 1.11.2 verwenden können, nachdem sie sichergestellt haben, dass die neuen RBAC-Regeln in Kraft sind.

Wir planen, die Unterstützung für das 1.3.1-Image und den Fallback-Mechanismus mit der Version 17.5 einzustellen, damit wir diese Unterstützung vollständig entfernen und nur noch 1.11.2 verwenden können, das zahlreiche Sicherheitsvorteile bietet.

Hinweis zur Deaktivierung (nur in englischer Sprache verfügbar)

4. Update der Hauptversion der Analysatoren der Anwendungssicherheitstests

GitLab.com | Self-Managed | Dedicated

Die Phase der Anwendungssicherheitstests wird die Hauptversionen der Analysatoren zusammen mit der Veröffentlichung von GitLab 18.0 aktualisieren.

Wenn du nicht die standardmäßig enthaltenen Vorlagen verwendest oder deine Analysator-Versionen fixiert hast, musst du deine CI/CD-Job-Definition aktualisieren, um entweder die fixierte Version zu entfernen oder die neueste Hauptversion zu aktualisieren.

Benutzer(innen) von GitLab 17.0–17.11 erhalten bis zur Veröffentlichung von GitLab 18.0 weiterhin normale Analysator-Updates. Nach GitLab 18.0 werden alle neu behobenen Bugs und Funktionen nur noch in der neuen Hauptversion der Analysatoren veröffentlicht.

Gemäß unseren Wartungsrichtlinien portieren wir keine Fehler und Funktionen in veraltete Versionen zurück. Sicherheitspatches werden bei Bedarf in die letzten drei Nebenversionen zurückportiert.

• Hinweis zur Deaktivierung (nur in englischer Sprache verfügbar)

5. API-Entdeckung verwendet standardmäßig Branch-Pipelines

GitLab.com | Self-Managed | Dedicated

In GitLab 18.0 aktualisieren wir das Standardverhalten der CI/CD-Vorlage für die API-Erkennung (API-Discovery.gitlab-ci.yml).

Vor GitLab 18.0 konfiguriert diese Vorlage Jobs so, dass sie standardmäßig in Merge Request-Pipelines (nur in englischer Sprache verfügbar) ausgeführt werden, wenn ein MR geöffnet ist.

Ab GitLab 18.0 richten wir das Verhalten dieser Vorlage am Verhalten der stabilen Vorlagen-Editionen (nur in englischer Sprache verfügbar) für andere AST-Scanner aus:

• Standardmäßig führt die Vorlage Scan-Jobs in Branch-Pipelines aus.
• Du kannst die CI/CD-Variable AST_ENABLE_MR_PIPELINES: true festlegen, um MR-Pipelines zu verwenden, wenn ein MR geöffnet ist. Die Implementierung dieser neuen Variable wird im Ticket #410880 nachverfolgt.

• Hinweis zur Deaktivierung (nur in englischer Sprache verfügbar)

6. DAST DAST_DEVTOOLS_API_TIMEOUT hat einen niedrigeren Standardwert

GitLab.com | Self-Managed | Dedicated

Die Umgebungsvariable DAST_DEVTOOLS_API_TIMEOUT bestimmt, wie lange ein DAST-Scan auf eine Antwort des Browsers wartet. Vor GitLab 18.0 hatte die Variable einen statischen Wert von 45 Sekunden. Ab GitLab 18.0 hat die Umgebungsvariable DAST_DEVTOOLS_API_TIMEOUT einen dynamischen Wert, der basierend auf anderen Timeout-Konfigurationen berechnet wird.

In den meisten Fällen war der Wert von 45 Sekunden höher als der Timeout-Wert vieler Scannerfunktionen. Der dynamisch berechnete Wert macht die Variable DAST_DEVTOOLS_API_TIMEOUT nützlicher, indem er die Anzahl der Fälle erhöht, für die sie gilt.

• Hinweis zur Deaktivierung (nur in englischer Sprache verfügbar)

Tools und Ressourcen, um deine Auswirkungen zu verwalten

Wir haben spezielle Tools entwickelt, um unseren Kund(inn)en zu helfen, zu verstehen, wie sich diese geplanten Änderungen auf ihre GitLab-Instanz(en) auswirken. Sobald du die Auswirkungen für deine Arbeit analysiert hast, solltest du die in der Dokumentation beschriebenen Maßnahmen überprüfen, um einen reibungslosen Übergang zu GitLab 18.0 zu gewährleisten.

• Veraltete Funktionen der erweiterten Suche: Dieses Tool nutzt die erweiterte Such-API von GitLab, um Zeichenfolgen zu finden, die in allen GitLab-Gruppen und -Projekten veraltet sind. Es zeigt auch, welche Dateien manuell überprüft werden sollten. Hinweis: Kann ein paar falsch positive Ergebnisse liefern.
• Dependency Scanning Build Support Detection Helper: Dieses Tool identifiziert Projekte, die von drei Einstellungen der Abhängigkeitssuche betroffen sind (1, 2, 3; alle auf Version 19.0 verschoben). Es verwendet die API, um nach relevanten Dateien und CI-Job-Namen zu suchen.
• GitLab Detective (nur Self-Managed): Dieses experimentelle Tool überprüft automatisch eine GitLab-Installation auf bekannte Probleme. Es führt komplexe Überprüfungen durch, indem es Konfigurationsdateien oder Datenbankwerte analysiert. Hinweis: Muss direkt auf deinen GitLab-Knoten ausgeführt werden.

Wir haben außerdem eine Reihe von Mikrokursen (15 Minuten oder kürzer) auf der GitLab University gestartet, die dir bei der Planung und Durchführung von Maßnahmen zur Minderung einiger dieser Änderungen helfen. Starte deine Lernreise hier.

Wenn du einen kostenpflichtigen Tarif hast und Fragen zu diesen Änderungen hast oder Unterstützung benötigst, öffne ein Support-Ticket im GitLab-Support-Portal.

Wenn du Benutzer(in) einer kostenlosen Gitlab.com-Lizenz (nur in englischer Sprache verfügbar) bist, kannst du über meist englischsprachige Community-Quellen wie die GitLab-Dokumentation, das GitLab-Community-Forum und Stack Overflow auf zusätzlichen Support zugreifen.