© nejron / 123RF.com

Gitlab-Instanzen sind in vielen Unternehmen längst ein zentraler Dienst und somit auch für Angreifer interessant. Daher empfiehlt es sich, sie so abzuhärten, dass sich Ganoven daran die Zähne ausbeißen. Das klappt sogar mit Linux-Bordmitteln.

Cloud-Computing, Containerisierung und agiles Arbeiten sind bekanntlich längst nicht jedermanns Sache, wie man es auch dreht und wendet: Die technischen Veränderungen und die durch technischen Veränderungen erzwungenen Änderungen in den Abläufen haben die Art und Weise verändert, wie IT-Abteilungen heute funktionieren. DevOps, SecOps, Agilität und das Pareto-Prinzip etwa lassen Programmierern heute vielerorts kaum mehr Spielraum hinsichtlich der Art und Weise, wie sie Anwendungen entwickeln und ausrollen.

Eine zentrale Rolle spielt dabei ein Werkzeug, das dessen Erfinder für diesen Zweck eigentlich gar nicht geschaffen hat: Als Linus Torvalds mit der Arbeit an Git begann, wollte er eigentlich nur ein stabiles Tool für die dezentrale Arbeit am Linux-Quelltext erschaffen, weil ihm bestehende Optionen wie CVS oder Subversion nicht zusagten [1]. Heute ist Git aus den meisten Unternehmen nicht mehr wegzudenken, etwa als Basis für CI/CD-Pipelines, die Docker-Abbilder der eigenen Anwendung bauen und in Produktion auch gleich ausrollen.

Firmen wie Gitlab [2] war das sehr recht: Sie verstanden schnell, dass Git aus mehr als einem lokalen Ordner mit ein paar Metadaten besteht und dass sich aus einem gut verwaltbaren Git-Dienst ordentlich Geld pressen lässt. Entsprechend hoch ist die Anzahl der Firmen, in denen heute eine Instanz von Gitlab als Quasi-Klassenprimus läuft und zentrale Funktionen wahrnimmt. Vielerorts ist die interne Abhängigkeit von Git mittlerweile so groß, dass ein Unternehmen während des Ausfalls einer Git-Instanz praktisch arbeitsunfähig wäre.

Administratoren treibt das um: Sie wissen, dass der plötzliche Ausfall von Hard- oder Software längst nicht die einzige Problemquelle ist, denen ihr Gitlab zum Opfer fallen könnte. Gerade weil Git-Instanzen in vielen Unternehmen zentrale Rollen einnehmen und weil in ihnen oft ein Großteil des kostbaren Firmenwissens steckt, sind sie auch für Angreifer ein interessantes und lohnenswertes Ziel. Wer eine Gitlab-Instanz erfolgreich aufbricht, stiehlt technisches Know-how, kritische Passwörter und im schlimmsten Fall Kundendaten. Es liegt also im natürlichen Interesse eines Admins, das eigene Git so effektiv wie nur irgendwie möglich gegen Ganoven zu verteidigen.

Leichter gesagt als getan, mag sich mancher Administrator dabei denken. Gerade weil Gitlab als Lösung mittlerweile so viel Funktionalität bündelt, ist das Werkzeug selbst relativ komplex geworden. Alles Jammern hilft aber nicht: Irgendwie muss der Admin sein Gitlab gegen unberechtigte Zugriffe schützen.

Wirksamer Schutz

Wie bei anderen vergleichbar komplexen Lösungen genügt zum Schutz einer Gitlab-Instanz keine Einzelmaßnahme. Gefragt ist viel eher ein Konzept. Verschiedene Funktionen von Gitlab lassen sich mit Best-Practices-Ansätzen der Industrie verbinden, um bei möglichst geringer Komforteinschränkung einen idealen Schutz zu erreichen. Das ist durchaus ein wichtiger Faktor: Eine völlig zugenagelte Gitlab-Instanz mag ja sicher sein, doch werden Nutzer sich früher oder später Alternativen in Form lokaler Git-Verzeichnisse schaffen oder Wege finden, die etablierten Einschränkungen zu umgehen. Genau das ist aber nicht das Ziel der Übung. Vielmehr gilt es, Gitlab durch sinnvolle Maßnahmen abzusichern, es dabei aber so benutzbar wie möglich zu halten. Sicherheitskonzepte für Gitlab bestehen entsprechend aus mehreren Teilen und decken unterschiedliche Faktoren ab.

Zunächst geht es um den Schutz von Gitlab selbst. Hier spielt eine effektive Zugriffskontrolle eine ebenso große Rolle wie das Einspielen von Updates zum Stopfen von Sicherheitslöchern. Ebenso wichtig ist, die Inhalte in Gitlab zu schützen: Das tollste Sicherheitskonzept läuft ins Leere, wenn ein Einfaltspinsel versehentlich ein ganzes Repository mit sensiblen Inhalten der Öffentlichkeit freigibt. An manchen Stellen überschneiden sich die Maßnahmen zur Absicherung von Gitlab und decken sowohl die Anwendung selbst als auch deren Inhalte ab. Der Schlüssel zum Erfolg sind Beharrlichkeit und sorgfältige Prüfung der geplanten Maßnahmen. Sehen wir uns einmal näher an, welche Aspekte Teil eines Konzepts für die Absicherung von Gitlab sein können und wie sie ineinandergreifen.

Nutzerverwaltung

Bevor es auf die Ebene von Gitlab selbst geht, steht erst einmal das Thema Benutzerverwaltung ganz allgemein auf der Agenda. Leistet der Administrator hier gute Vorarbeit, lässt sich das Resultat in Gitlab später hervorragend wiederverwenden.

Ganz generell gilt: Selbst in kleinen Firmen hat sich mittlerweile flächendeckend das Prinzip zentraler Benutzerverzeichnisse durchgesetzt. Die Vorzüge dieses Prinzips sind offensichtlich: On- und Offboarding erfolgen zentral und gelten stets für alle Dienste gleichzeitig. Passwortänderungen beschränken sich nicht auf einzelne Dienste, sondern entfalten sofort überall im Setup ihre volle Wirkung.

Viele Administratoren unterschätzen die Wirkung von Gruppen, die ebenfalls Bestandteil von zentralen Benutzerverzeichnissen sein können. Gitlab hantiert im Hintergrund extrem ausführlich mit Gruppen und kann quasi jede seiner Zugriffsberechtigung auf Gruppen abbilden. Hat man seine Gruppen in LDAP oder Active Directory im Griff, lassen sie sich in Gitlab also direkt nutzen. Von den unstrittigen Vorteilen von Single Sign-on ist dabei noch gar nicht die Rede (Abbildung 1).

Abbildung 1: Wem simples LDAP als Backend nicht reicht, der erweitert sein Gitlab um SSO (hier am Beispiel von Keycloak) und hebt damit auch die Authentifizierung auf die nächste Stufe. Quelle: Yoshiaki Senda

Ganz allgemein heißt das: Ein Unternehmen, für das sich eine eigene Gitlab-Instanz rentiert, ist wahrscheinlich auch groß genug für ein zentrales Benutzerverzeichnis. Ob dabei LDAP oder Active Directory zum Einsatz kommt, spielt keine Rolle, denn Gitlab beherrscht den Umgang mit beiden Ansätzen. Dieser Artikel geht im gesamten weiteren Verlauf davon aus, dass Sie Ihre Benutzerdatenbank nicht lokal in Gitlab pflegen, sondern sie an ein zentrales Benutzerverzeichnis ankoppeln. Einige der folgenden Tipps funktionieren auch ohne diese Voraussetzung, sind aber unter Umständen schwieriger umzusetzen oder erfordern mehr Konfigurationsaufwand.

Zugriffsrechte steuern

Die meisten Angreifer versuchen bei der Attacke auf eine Gitlab-Instanz nicht, Zugriff auf das System zu erhalten, auf dem Gitlab liegt: Das wäre schon wegen vorhandener Paketfilterregeln oft deutlich komplizierter, als sozusagen den direkten Weg durch die Tür zu nehmen und sich Zugriff auf ein bestehendes Gitlab-Benutzerkonto zu beschaffen. Das Prinzip ist weder neu noch Gitlab-spezifisch; vergleichbare Angriffsmuster kommen bei praktisch jedem gehosteten Dienst zum Einsatz. Entsprechend umfangreich sind die Methoden, mit denen sich derartige Angriffe unterbinden lassen.

Eine der wirksamsten Maßnahmen stellt zweifelsohne das Absichern eines Accounts durch einen zweiten Sicherheitsfaktor dar. 2FA gilt längst als Standard in der Industrie, und Gitlab unterstützt es selbstredend. In vielen Gitlab-Instanzen liegt das Feature allerdings brach, oder der Gitlab-Administrator hat es gar nicht erst aktiviert. Sie sollten deshalb unbedingt darauf achten, in den Administrationseinstellungen unter General | Sign-in restrictions den Punkt Two-Factor Authentication (2FA) mit einem Haken zu versehen.

Abbildung 2: Zwei-Faktor-Authentifizierung stellt Gitlab vor keinerlei Probleme, sie erhöht die Sicherheit in Gitlab-Setups aber erheblich. Quelle: Gitlab

Gitlab lässt den Nutzern dann 48 Stunden Zeit, um für das eigene Konto ein zweites Zugangs-Token anzulegen. Es schadet im Normalfall aber nicht, diese Zeit noch etwas zu reduzieren. Wenn neue Mitarbeiter am ersten Arbeitstag im Rahmen des zentralen Onboardings ohnehin unmittelbar ihr Diensttelefon und ihren Git-Zugang erhalten, erscheint ein Zeitraum von acht Stunden angemessener. Je kürzer der Git-Zugang mittels nur eines Sicherheitsfaktors klappt, desto geringer ist die Wahrscheinlichkeit eines Missbrauchs.

Per Zwei-Faktor-Authentifizierung lassen sich in Gitlab übrigens auch Admin-Zugänge besser sichern. Für administrative Aufgaben lässt sich auf derselben Seite der Gitlab-Einstellungen festlegen, dass Veränderungen an der zentralen Konfiguration eine Absicherung mittels zweitem Faktor durch den ausführenden Admin erfordern. Hier sollten freilich verschiedene Tokens zum Einsatz kommen. Als Admin-Token könnte etwa ein Yubikey [3] oder ein vergleichbares Gerät dienen, das während der normalen Arbeit im Safe lagert. Das stellt sicher, dass Angreifer Gitlab nicht unbemerkt über die Konfiguration in einen Schweizer Käse verwandeln können, selbst wenn ihnen die Zugangsdaten und das reguläre 2FA-Token eines Administrators in die Hände fallen.

Keine Selbstregistrierung

Implizit klang der nächste dringende Rat für das Absichern von Gitlab bereits an, doch schadet es nicht, auf diesen wichtigen Punkt auch explizit einzugehen: Gitlab lässt sich ähnlich wie Github als komplett öffentliches Git-Verzeichnis führen. Nutzer haben dann die Option, sich selbst einen Zugang anzulegen, indem sie den Registrierungsvorgang der Software durchlaufen.

In vielen Unternehmen dürfte bereits das einschlägige Compliance-Regelwerk diesen Ansatz a priori aus dem Rennen nehmen. Trotzdem der Hinweis: Falls Sie nicht tatsächlich ausschließlich öffentliche Git-Verzeichnisse hosten möchten, schalten Sie die Selbstregistrierfunktion besser ab und wickeln die Account-Verwaltung in Gitlab stattdessen über das zentrale Benutzerverzeichnis ab. Am Markt gibt es längst Skripte, mit denen sich auf Gitlab-Instanzen komplett automatisch beliebige Accounts anlegen lassen, und wie bereits erwähnt, stellt ein existierender Account in Gitlab immer das einfachste Einfallstor für Angreifer dar.

Die relevanten Einstellungen finden Sie im Admin-Panel unter Settings | General | Sign-up restrictions. Hier sollten Sie den Haken bei Sign-up enabled entfernen.

Sichtbarkeit von Inhalten

Weiter geht es mit dem vermutlich umfangreichsten Themenblock im Hinblick auf das Schützen von Inhalten in Gitlab. Wie beschrieben verfügt die Lösung unter der Haube über ein RBAC [4]. Über Gruppen und Benutzer- sowie Gruppenberechtigungen lässt sich also problemlos steuern, auf welche Inhalte die Anwender grundsätzlich Zugriff haben sollen.

Zudem empfiehlt es sich dringend, die Standardfreigaben in Gitlab so zu modifizieren, dass Anwender ohne eigene Rechte- oder Gruppenzuweisung idealerweise gar nichts sehen. Die Einstellungen dafür verstecken sich im Admin-Panel unter Settings | General | Visibility and access control. Achten Sie darauf, dass neue Repositories grundsätzlich als private angelegt werden. In der Standardkonfiguration hat dann nur der Nutzer Zugriff auf das Repository, der es angelegt hat. Möchte er das ändern, so vergibt er explizite Zugriffsrechte für Gruppen oder Gitlab-Nutzer, die damit arbeiten sollen.

Gerade in größeren Unternehmen kann dieser Ansatz allerdings recht unkomfortabel sein. Gibt es in der Firma etliche Hierarchiestufen, ist es nicht sinnvoll, ein Verzeichnis innerhalb eines Teams stets nur dessen eigentlichem Besitzer vorzubehalten und darüber hinaus das manuelle Hinzufügen zu erzwingen. Das gilt umso mehr, da sich Gitlab durchaus so konfigurieren lässt, dass nur Accounts mit besonderen Rechten den Zugriff auf Repositories steuern können, nicht aber die Eigentümer der jeweiligen Verzeichnisse. Im schlimmsten Fall müsste ein Benutzer nach dem Anlegen eines Repos dann einen internen Prozess in Gang setzen, damit eine Person mit der entsprechenden Berechtigung die Teamkollegen ebenfalls dem Verzeichnis hinzufügt. Gerade in Konzernen kann dabei viel kostbare Zeit verstreichen.

Als Administrator sollten Sie sich deshalb bereits im Vorfeld ein Konzept für die Verwaltung von Rechten in Gitlab überlegen und es im zentralen Verzeichnisdienst über Gruppen idealerweise gleich auch gleich entsprechend implementieren. Eine Blaupause dafür gibt es allerdings nicht, denn dabei hängt vieles von der Größe des Unternehmens ab.

Für kleinere Personenkreise haben sich Konzepte bewährt, die im Benutzerverzeichnis eine Gruppe für Entwickler vorsehen und ihr automatisch Lese- und Schreibzugriff auf neue Repositories einräumen. In größeren Firmen oder Konzernen kann das aber schon wieder viel zu viel des Guten sein: Hier darf (und will) das Entwicklerteam aus Geschäftseinheit A üblicherweise nicht auf die Quellen des Teams aus Geschäftseinheit C zugreifen. Eine entsprechende Feinabstufung lässt sich über entsprechende Rollen- und Gruppenmitgliedschaften aber problemlos im zentralen Benutzerverzeichnis abbilden (Abbildung 3).

Abbildung 3: Ein zentrales, mit Gitlab gekoppeltes Benutzerverzeichnis erleichtert die Benutzerverwaltung erheblich. Quelle: Gitlab

Damit die ganze Mühe sich letztlich auszahlt, sollten Sie als Admin einer privaten Gitlab-Instanz dafür Sorge tragen, dass Anwender nicht versehentlich einzelne Repositories der Öffentlichkeit preisgeben können. Dazu stehen wieder mehrere Optionen zur Wahl: Einerseits lässt sich die Berechtigung zum Freigeben auf der Gitlab-Ebene separat steuern, andererseits kann man ein lokales Gitlab auch gleich so betreiben, dass der Zugriff beispielsweise nur per VPN oder aus dem lokalen Netz klappt. Das widerspricht aber allen Prinzipien von Zero Trust und sollte entsprechend nur die Ultima Ratio sein.

Obendrein schränkt diese Art der Sicherung den möglichen Teilnehmerkreis von Gitlab-Anwendern massiv ein. Es kann ja aus Sicht der Firma durchaus erwünscht sein, dass auch externe Lieferanten Zugriff auf das interne Git bekommen. So etwas lässt sich über das zentrale Benutzerverzeichnis relativ gut abbilden. Gibt es zwischen dem Lieferanten und der Gitlab-Instanz aber keinen Netzwerkpfad, läuft das Konzept ins Leere.

Gitlab-Interfaces härten

Ab Werk aktiviert Gitlab für den Zugriff von außen sowohl die interne SSH-Schnittstelle als auch ein HTTPS-Interface. Linus Torvalds selbst legte einst großen Wert darauf, an Verzeichnisse auf Git-Servern auch über HTTPS heranzukommen, weil sich bis heute vielerorts (etwa in Hotel-WLANs) die Unsitte hält, nur spezifische Ports nach draußen zu erlauben.

Letztlich legen aber Sie als Admin fest, ob der konkrete Anwendungsfall tatsächlich den Zugriff über beide Protokolle erfordert. Sie können die Benutzer durchaus dazu verdonnern, sich auf SSH zu beschränken. Das erzwingt nicht nur die sichere Authentifizierung mittels SSH-Schlüssel, sondern ermöglicht auch das Abschalten der HTTP-basierten Schnittstelle. Das reduziert wiederum die Angriffsfläche, die eine Gitlab-Instanz insgesamt bietet.

Passwörter

Grundsätzlich gilt: Passwörter, die in irgendeiner Form Zugang zu kritischen Daten oder kritischen Diensten ermöglichen, gehören nicht im Klartext in Gitlab, weder in ein Repository noch in dessen Konfiguration. Hier bietet es sich stattdessen an, auf einen externen Passwortspeicher zurückzugreifen, wie Hashicorp Vault [5], das sich nahtlos in Gitlab integrieren lässt. Eigentlich ist auch dieser Aspekt eine absolute Selbstverständlichkeit, trotzdem ignorieren ihn viele Unternehmen sträflich.

Inhalte sichern

Bis hierhin ging es vorrangig um das Sichern der Gitlab-Instanz selbst. Daneben stellt sich die Frage nach dem Sichern der hinterlegten Inhalte. Hier ergeben sich für Angreifer mannigfaltige Möglichkeiten, verdeckte Vorgänge in den Untiefen eines Git-Verzeichnisses unterzubringen. Ein kurzes Gedankenexperiment soll das verdeutlichen.

Wie eingangs beschrieben, spielt Git in vielen Unternehmen längst nicht mehr nur im Kontext der Anwendungsentwicklung eine Rolle. DevOps hat vielerorts dazu geführt, dass unmittelbar aus der Versionsverwaltung heraus Text in die Produktion geschoben wird. Bei entsprechend gebauten CI/CD-Toolchains klappt das sogar vollautomatisch. Gelingt es einem Angreifer nun, trotz der bereits beschriebenen Sicherheitsmaßnahmen die Zugangsdaten eines Accounts zu ergaunern, der Commit-Rechte in die produktive Gitlab-Umgebung hat, zieht das im schlimmsten Fall weitreichende Folgen nach sich: Auf diesem Weg lassen sich indirekt Änderungen in der Produktion vornehmen. Tarnt ein Ganove sie entsprechend, fallen sie möglicherweise nicht einmal auf.

Umgehen lässt sich das Problem durch eine Kaskade von Maßnahmen. Zunächst sollte es innerhalb des Unternehmens eine klare Vorgabe für die Art und Weise geben, wie das Git-Verzeichnis zu nutzen ist. Dazu gehören Alltäglichkeiten wie der Umstand, dass Entwicklung stets innerhalb eines persönlichen Zweigs eines Repositorys stattzufinden hat, den man klar einem Benutzer zuordnen kann. Gleichzeitig muss die genutzte CI/CD-Toolchain so konfiguriert sein, dass stets ausschließlich der Master-Tree (oder ein beliebiger, aber fest definierter anderer Tree) zum Einsatz kommt, um in der Produktion Änderungen auszurollen.

Darüber hinaus gilt es, interne Review-Ketten zu etablieren. Gitlab bietet diese Möglichkeiten und lässt sich beispielsweise so konfigurieren, dass ein Nutzer die Änderungen eines eigenen Zweigs grundsätzlich nicht per Push direkt in den Hauptzweig eines Verzeichnisses integrieren kann (Abbildung 4). Ganz vollständig ist das Konzept aber nicht, denn ein Gitlab-Nutzer mit entsprechenden Berechtigungen kann Gitlab durchaus so umbauen, dass er doch wieder zum Zug kommt. Umgehen lässt sich das letztlich nur durch eine klare Trennung zwischen jenen Accounts in Gitlab, die Merge Requests für eigene Branches in Richtung des Hauptzweigs vornehmen können, und jenen, die den Merge Request annehmen und damit die Änderungen scharfschalten dürfen.

Abbildung 4: Im Idealfall können Benutzer in Gitlab nicht unmittelbar aus einem eigenen Zweig heraus in den Master-Branch pushen. Hier empfiehlt es sich, über ein Review-Regime die Inhalte zu schützen. Quelle: Gitlab

Das müssen nicht zwangsläufig unterschiedliche Personen erledigen. Bei entsprechend geringem Personalstand wäre etwa denkbar, dass Entwickler A Änderungen mit seinem normalen Account vornimmt und damit auch den Merge Request anlegt, dann aber mit einem speziellen Zusatzkonto den Merge Request akzeptiert. Es hat sich zudem bewährt, für den erfolgreichen Push aus einem Entwicklerzweig in den Hauptzweig das Einverständnis von mehr als einem Benutzer vorauszusetzen. Selbst bei vollständiger Kompromittierung eines einzelnen Anwenders ist es dann unmöglich, Änderungen in Git einfach durchzuwinken – und vor allem nicht, ohne dass es jemandem auffällt.

Das ganze Konzept funktioniert in der Praxis freilich nur, wenn die Reviewer von Merge Requests ihrer Rolle auch mit der gebotenen Verantwortung nachkommen. Gerade in kleineren Unternehmen ist das Durchwinken von Änderungen in Git oft eher eine Formalie als ein formaler Review Prozess. Das kann allerdings schnell zum Problem werden, denn Angreifer setzen gezielt auf eben solche Ungenauigkeiten. Wer langfristig Sorgfalt walten lässt, erhöht dadurch nicht nur mit einiger Wahrscheinlichkeit die Qualität des Codes im eigenen Git, sondern macht Angreifern auch das Leben schwerer.

Die ewige Leier

Zu guter Letzt darf ein Hinweis auf ein Prozedere nicht fehlen, das eigentlich keiner Erwähnung bedürfen sollte, das aber noch immer viel zu viele Firmen sträflich vernachlässigen. Gerade weil Git oft eine zentrale Komponente ist, scheuen viele Unternehmen sich, Sicherheitsaktualisierungen dafür zeitnah einzuspielen. Wer so vorgeht, braucht sich über das Thema Härtung von Gitlab im Grunde überhaupt keine Gedanken mehr zu machen.

Denn klar ist: Gitlab lässt sich in vielen Firmen unmittelbar aus dem Internet erreichen, kommt an zentraler Stelle zum Einsatz und ist mithin prädestiniert für Angreifer und automatisierte Angriffe. Sobald Gitlab ein Bulletin über eine entdeckte Sicherheitslücke veröffentlicht, gilt es, die nötige Gegenmaßnahme mit kurzer Vorlaufzeit in die Produktion zu bringen, um die Gitlab-Instanz keinem unnötigen Risiko auszusetzen (Abbildung 5).

Abbildung 5: Die Enterprise-Version von Gitlab verfügt über eine Statusanzeige, die Alarm schlägt, wenn Gitlab verwundbar ist. Updates muss man dann aber auch einspielen, sonst nutzt das schönste Dashboard nichts. Quelle: Gitlab

Das sollte umso mehr eine Selbstverständlichkeit sein, weil Gitlab heute vielerorts in Form von Containern zur Anwendung kommt, die sich in wenigen Sekunden ersetzen lassen. Wer sein Gitlab nicht furchtlos und schnell aktualisiert, weil er Angst vor losen Teilen und Bröseln nach dem Update hat, der hat schlicht die Kontrolle über einen zentralen Teil seiner Infrastruktur verloren.

Fazit

Gitlab lässt sich mit verhältnismäßig wenig Aufwand gut härten. Indem Sie die Grundregeln beachten und beispielsweise ein zentrales Benutzerverzeichnis zum Einsatz bringen, ersparen Sie sich von vorneherein viele Probleme, die das Hantieren mit lokalen Benutzerdaten mit sich bringt.

Wie üblich müssen Sie sich aber auch bei Gitlab die Frage stellen, wie ein realistisches Angriffsszenario aussieht und welche Teile der lokalen Gitlab-Instanz es mit entsprechender Priorität abzusichern gilt. Sowohl Gitlab selbst als auch dessen Inhalte lassen sich schon in den Grundversionen der Software auf etlichen Wegen schützen. Ein sicheres Gitlab setzt entsprechend ein umfassendes Konzept voraus, dessen Entwicklung stets ganz am Anfang stehen sollte. Idealerweise haben Sie diesen Schritt bereits abgehakt, noch bevor Gitlab den Betrieb aufnimmt. Aber auch in bestehenden Instanzen lassen sich die meisten Funktionen im Nachhinein recht problemlos nachrüsten. (jlu)