Bildquelle: Pexels / cottonbro studio / https://www.pexels.com/photo/man-connecting-computer-cables-6804586/
Zertifikatscluster in GitLab sind kein Altbestand mehr, sondern ein Abschaltrisiko
Alte GitLab-Kubernetes-Anbindungen wirken in vielen Umgebungen harmloser, als sie im Betriebsalltag wirklich sind. Solange Deployments noch laufen, behandeln Teams die zertifikatbasierte Integration gern wie technischen Altbestand, den man irgendwann später sauber ersetzt. Der offizielle GitLab-Stand ist dafür inzwischen zu deutlich. Im aktualisierten Blogeintrag vom 18. April 2025 kündigt GitLab an, dass die zertifikatbasierte Kubernetes-Integration auf GitLab.com im Mai 2026 ausläuft. Parallel beschreibt die aktuelle Dokumentation seit längerem klar, dass der Pfad deprecated ist, in Self-Managed ab 17.0 standardmäßig deaktiviert wurde und durch den GitLab Agent for Kubernetes ersetzt werden soll. Wer diese Lage noch immer wie ein kosmetisches Cleanup behandelt, baut nicht auf einen ruhigen Legacy-Pfad, sondern auf ein reales Betriebsrisiko.
Für Leser ohne tiefen GitLab-/Kubernetes-Hintergrund: Die alte GitLab-Integration verbindet einen Cluster über hinterlegte Zertifikate direkt mit GitLab. Der neuere Agent-Ansatz dreht dieses Modell: Ein Agent läuft im Cluster, verbindet sich kontrolliert mit GitLab und steuert Zugriffe, CI/CD-Nutzung und GitOps-nähere Abläufe sauberer. Relevant ist das, weil nicht nur ein Verbindungsweg getauscht wird, sondern das Berechtigungs- und Betriebsmodell dahinter.
Der eigentliche Migrationsjob beginnt nicht im Cluster, sondern in der Discovery
GitLab macht in den offiziellen Migrationshinweisen einen Punkt sehr klar, den Teams im Alltag gern unterschätzen: Zuerst muss überhaupt sichtbar werden, wo die alte Integration noch hängt. Dafür verweist GitLab auf einen eigenen API-Endpunkt, mit dem Gruppen alle zertifikatbasierten Cluster in ihrer Hierarchie abfragen können. Allein diese Empfehlung zeigt, dass es eben nicht nur um ein Helm-Kommando für einen neuen Agenten geht. In vielen Landschaften weiß nach einigen Jahren niemand mehr präzise, welche Gruppen, Subgroups, Projekte, Umgebungen und Auto-DevOps-Strecken noch an historischen Clusterdefinitionen hängen.
Genau dort entsteht das operative Risiko. Ein Plattformteam plant vielleicht einen sauberen Agent-Rollout für die heute aktiven Produktionscluster. Gleichzeitig lebt irgendwo noch ein altes Staging-Projekt, ein Sonderpfad für Auto DevOps oder ein historischer Projekt-Cluster weiter, der nur in seltenen Fällen benutzt wird. Solche Reste fallen im Normalbetrieb kaum auf. Im entscheidenden Release-Fenster oder bei einer Wiederanlauf-Situation tauchen sie dann plötzlich wieder auf. GitLab nennt deshalb ausdrücklich Arbeitsschritte wie das Auffinden betroffener Owner, das Prüfen direkter Kubernetes-API-Aufrufe in CI/CD-Pipelines, das Identifizieren von Auto-DevOps-Projekten und das Erfassen GitLab-managed Clusters. Das ist keine Formalität, sondern die eigentliche Vorarbeit, ohne die jede Migrationsaussage zu optimistisch klingt.
Wer hier sauber arbeitet, entdeckt fast immer mehr als nur Clusterobjekte. Sichtbar werden auch gewachsene Ownership-Lücken. Ein Projekt verwendet die alte Anbindung, aber niemand fühlt sich zuständig. Ein Deployment läuft, aber die Namespace-Logik ist nur noch implizit bekannt. Oder ein Team hat vor Jahren GitLab-managed Ressourcen genutzt und seitdem nie wieder wirklich dokumentiert, was davon heute noch produktiv relevant ist. Der Agent löst diese Unschärfen nicht automatisch. Er macht sie nur schwerer ignorierbar.
Die heikle Stelle sitzt in Pipelines, Auto DevOps und Namespace-Logik
In der GitLab-Dokumentation zur Agent-Migration steckt die eigentliche Betriebsrealität zwischen den Zeilen. Für generische Deployments reicht es nicht, einen Agenten zu installieren. Er muss für die richtigen Gruppen und Projekte autorisiert werden, und die Jobs müssen ihn anschließend explizit verwenden. Bei Auto DevOps kommt zusätzlich die Umstellung auf Variablen wie KUBE_CONTEXT und KUBE_NAMESPACE hinzu. Das klingt nach kleinen Konfigurationspunkten, ist aber im Alltag oft die Stelle, an der alte Annahmen über Environments, Namensräume und Scope-Regeln sichtbar brechen.
Besonders interessant ist die Migrationshilfe für GitLab-managed Kubernetes Resources. GitLab weist dort ausdrücklich darauf hin, dass frühere Verhaltensweisen wie Namespace-per-environment nicht einfach verschwinden, sondern bewusst in Agent-Konfiguration und Environment-Templates nachgebildet werden müssen. Das ist ein wichtiger Hinweis. Die alte zertifikatbasierte Welt war technisch oft unsauber, aber sie trug implizite Bequemlichkeiten mit sich. Wer diese stillschweigend verloren gehen lässt, produziert keinen Sicherheitsgewinn, sondern neue Betriebsfehler. Dann laufen zwar theoretisch moderne Agenten, aber die Umgebungslogik passt nicht mehr zu den Erwartungen der Teams.
Genau deshalb sollte die Migration nicht als reine Clusterarbeit delegiert werden. Sie ist ein Pipeline- und Delivery-Thema. Entscheidend ist nicht nur, ob der Cluster verbunden ist, sondern ob Branches, Environments, Deploy-Jobs, Rollbacks und Berechtigungen danach noch dieselbe fachliche Bedeutung haben. GitLab positioniert den Agenten zwar zu Recht als sicherer und zuverlässiger, aber die eigentliche Umstellung trifft das Delivery-Modell. Wer das verkennt, wird im Testlauf vielleicht Erfolg sehen und im ersten realen Sonderfall trotzdem stolpern.
Warum der Agent ein anderes Betriebsmodell erzwingt
GitLabs Argumente für den Agenten sind technisch nachvollziehbar: keine in GitLab gespeicherten Cluster-Credentials, bidirektional sauberere Kommunikation, feinere Zugriffskontrolle, belastbarere CI/CD-Anbindung und bessere GitOps-Fähigkeit. Wichtig ist aber die organisatorische Folge. Das alte Modell hat Teams oft erlaubt, GitLab wie einen Ort zu behandeln, an dem Cluster „einfach angeschlossen“ sind. Der Agent verschiebt den Schwerpunkt auf bewusst konfigurierte Zugriffe, explizite Freigaben und einen klareren Zusammenhang zwischen Projekt, Gruppe und Clusterpfad.
Das ist im Kern positiv, weil es die Integration weniger flakey und sicherer macht. Es erhöht aber den Anspruch an saubere Zuständigkeit. Die Frage lautet nicht mehr nur: „Ist der Cluster verbunden?“ Sie lautet: Welcher Agent gehört zu welchem Projekt, welche Gruppen dürfen ihn aus CI/CD ansprechen, wie werden Umgebungen modelliert und welche Ressourcen dürfen Teams darüber tatsächlich selbst verwalten? Wer diese Fragen heute nicht beantworten kann, hat kein reines Legacy-Problem, sondern ein Architekturproblem im Plattformbetrieb.
Gerade für größere Organisationen ist das der wichtigere Befund als jede einzelne Featureliste. Der Agent ist nicht bloß der Nachfolger einer alten Integration. Er ist ein Korrektiv gegen ein Betriebsmodell, das zu viel implizit gelassen hat. Das bedeutet auch: Eine erfolgreiche Migration misst sich nicht daran, dass irgendein Deployment wieder grün wird. Sie misst sich daran, dass Discovery, Ownership, Zugriff und Environment-Verhalten danach erklärbarer und belastbarer sind als vorher.
Was DevOps- und Plattformteams jetzt praktisch prüfen sollten
Der erste Schritt ist eine ehrliche Discovery über die von GitLab empfohlene Cluster-Suche plus eine Pipeline-Sichtung auf direkte Kubernetes-Zugriffe. Der zweite Schritt ist die Zuordnung von Ownership: Wer verantwortet jeden verbleibenden Clusterpfad, jede Auto-DevOps-Strecke und jede historisch gewachsene Namespace-Logik? Der dritte Schritt ist ein Migrationsdesign, das nicht nur Agent-Installation, sondern auch Autorisierung, Environment-Mapping und Rollback-Pfade umfasst. Und der vierte Schritt ist ein echter Test auf nichtproduktiven Umgebungen, bevor ein Produktionsteam erst im nächsten Wartungsfenster feststellt, dass der alte Komfortpfad die eigentliche Abhängigkeit war.
Der saubere Schluss daraus ist unbequem, aber nützlich: Zertifikatscluster in GitLab sind kein neutraler Altbestand mehr. Sie markieren Stellen, an denen Delivery, Berechtigung und Clusterbetrieb noch an einer auslaufenden Logik hängen. Genau deshalb sollte die Migration nicht als spätere Hygieneaufgabe im Backlog liegen bleiben. Sie gehört in die aktive Betriebsplanung, solange Teams die Discovery noch kontrolliert und nicht erst unter Deploy-Druck machen müssen.
