GitLab startet Artifact Central in der Beta: eine Registry für die gesamte Organisation

Warum GitLab eine einzige Registry baut

GitLab hat die Beta auf der Hausmesse Transcend angekündigt. Das Unternehmen argumentiert, dass jeder Software-Build aus Open-Source-Paketen, Basis-Images und Bibliotheken zusammengesetzt wird, ergänzt um den eigenen Code des Teams, und dass ein fehlendes oder abgedriftetes Bauteil den Build scheitern lässt. Laut GitLab vervielfachen sich solche Fehler bei Agenten-Geschwindigkeit, und kein Team könne sie als manuelle Ausnahmen abarbeiten.

Außerdem verweist das Unternehmen auf den Wildwuchs bei Registries. In GitLab werden Aufbewahrungsregeln, Speicherlimits und Veröffentlichungsrechte derzeit für die Paket- und Container-Registry jedes Projekts einzeln konfiguriert. GitLab zufolge funktioniert dieses Design, solange ein Mensch jede Registry von Hand einrichtet, stößt aber an Grenzen, wenn Agenten dauerhaft über Hunderte Projekte hinweg arbeiten.

Richtlinien auf Organisationsebene und drei Repository-Typen

Artifact Central verlagert die Konfiguration eine Ebene nach oben. Teams legen Aufbewahrungsregeln, Quoten und Zugriffsrichtlinien einmal für die gesamte Organisation fest, statt sie in jedem Projekt neu anzulegen. Jedes Repository ist standardmäßig geschlossen, und die Mitgliedschaft in der Organisation allein schaltet kein Repository frei, bis eine Rolle den Zugriff gewährt. GitLab hat vier artefaktspezifische Rollen geschaffen: Admin, Manager, Contributor und Viewer. Sie sind von den bestehenden Projektrollen getrennt, sodass die Vergabe von Repository-Zugriff die Berechtigungen einer Person an anderer Stelle nicht verändert.

Entwickler arbeiten über eine einzige URL mit drei Repository-Typen:

• Hosted: private Pakete und Images, die Teams selbst bauen und veröffentlichen.
• Remote: ein Proxy vor einer externen Quelle wie Docker Hub oder Maven Central, wobei die Verbindung getestet wird, bevor irgendetwas davon abhängt.
• Virtual: ein einzelner Endpunkt, der Hosted- und Remote-Repositories bündelt. GitLab prüft zuerst das Hosted-Repository und greift dann auf die Remote-Quelle zurück, wobei der erste externe Pull zwischengespeichert wird.

In der Beta unterstützt Artifact Central Maven, npm, Docker und OCI, weitere Formate sollen folgen.

Integrierte Provenienz und gemeinsame Authentifizierung

Weil die Registry in derselben Plattform sitzt, die den Build ausgeführt hat, tragen über Artifact Central veröffentlichte Artefakte ihre Provenienz automatisch mit sich: welche Pipeline sie gebaut hat, aus welchem Branch und Commit sie stammen und wer den Job ausgelöst hat. GitLab stellt dem eigenständige Registries gegenüber, bei denen die Rückverfolgung eines Artefakts bedeutet, IDs aus einem CI-System und einer Registry mit einem Skript abzugleichen, das jemand pflegen muss.

Veröffentlichen und Abrufen laufen über CI_JOB_TOKEN, die Identität, die Pipelines bereits besitzen, für Menschen und Agenten gleichermaßen. Laut GitLab nutzt ein Agent dasselbe Job-Token statt eines separaten Dienstkontos mit eigenen Berechtigungen.

GitLab plant außerdem, diese Informationen über GitLab Orbit organisationsweit zu verknüpfen, sodass eine Frage wie „Welche laufenden Dienste sind von einer Sicherheitslücke betroffen?“ zu einer einzigen Abfrage wird.

Dependency Firewall und Migration

GitLab Dependency Firewall, ein separates Produkt, das für Premium- und Ultimate-Kunden im Early Access verfügbar ist, arbeitet von Haus aus mit Artifact Central zusammen. Sie soll riskante Pakete stoppen, bevor sie in einen Build gelangen, und wird mithilfe der glab-CLI zu jeder Pipeline hinzugefügt. GitLab plant eine engere Integration, damit eine einzige organisationsweite Richtlinie Pakete beim Abruf nach Sicherheitslücke, Lizenz oder Paketalter blockieren kann.

Für die Migration können Teams bestehende Repositories als Remotes hinter einem Virtual Repository hinzufügen. Artefakte wandern erst dann herüber, wenn ein Build sie anfordert, die alte Registry bleibt das führende System, und Teams können ein Remote später in ein Hosted-Repository umwandeln. GitLab zufolge vermeidet das Massenkopien und Migrationsfenster am Wochenende.

Verfügbarkeit und Bedeutung für Teams

Artifact Central ist als Beta für GitLab.com verfügbar, die Verfügbarkeit für GitLab Self-Managed ist laut Unternehmen für später in diesem Monat geplant. Während der Beta fallen keine Kosten an. GitLab erklärt, man werte die Nutzung aus, um die Preisgestaltung vor der allgemeinen Verfügbarkeit zu formen, und werde dann Details nennen. Eine Einladung ist nicht nötig: Nutzer melden sich auf der GitLab-Website an, und ein Teammitglied hilft bei der Aktivierung. Auch Personen ohne GitLab-Konto können sich für die Beta registrieren.

Für Plattform-Teams lautet das Versprechen, Speicherquoten und Zugriffsregeln einmal festzulegen und von jedem Repository erben zu lassen, mit einem einzigen Dashboard, das zeigt, wie viel das Unternehmen wo speichert. Für Entwickler bedeutet es eine URL für interne und externe Pakete und keine neuen Secrets, die beim Veröffentlichen aus der CI verwaltet werden müssen.