Wir freuen uns, GitLab 14.7 mit Audit-Event-Broadcasting, GitLab Runner FIPS 140-2-Konformität, Wildcard-Zugriffstoken und mehr zu veröffentlichen!

Dies sind nur einige Highlights von über 25 Verbesserungen in dieser Version. Lesen Sie weiter, um alles über diese coolen Updates zu erfahren. Um herauszufinden, was im nächsten Monat kommt, besuchen Sie die Seite mit den bevorstehenden Veröffentlichungen und sehen Sie sich das Video zur Veröffentlichung von 14.8 an.

Und auch...

Wir laden Sie zu unseren Treffen ein

Learn@GitLab (Online-Lernzentrum)

Der MVP dieses Monats ist Fabio Huser

Fabio hat Unterstützung für generische Zugriffstoken sowohl in der Benutzeroberfläche als auch in der REST-API hinzugefügt. Die Größe dieses Beitrags zeigt den Umfang der Arbeit, die darin steckt: ein Epos, drei Tickets und über 250 Community-Stimmen für dieses Feature!

Zuvor waren Zugriffstoken nur auf Projektebene verfügbar. Es gab eine Problemumgehung, die es Administratoren von selbst gehosteten GitLab-Instanzen ermöglichte, ein generisches Zugriffstoken über die Rails-Konsole zu generieren, aber das ließ unsere SaaS-Kunden mit nichts zurück.

Fabios Beitrag ermöglicht es jedem Benutzer mit den entsprechenden Privilegien, Zugriffstoken auf Gruppenebene zu generieren. Token können mit vordefinierter Rolle, Ablaufdatum und Umfang generiert werden.

Danke Fabio für diesen tollen Beitrag!

GitLab 14.7 Release Highlights

GitLab Runner ist FIPS 140-2-konformGitLab-Benutzer in den USA verlangen gesetzliche Vorschriften die Verwendung von FIPS (Federal Information Processing Standards)-kompatibler Software. Die FIPS-Versionen 140-2 und 140-3 definieren die Sicherheitsanforderungen für kryptografische Module, die in Computer-, Telekommunikations- und Cybersystemen verwendet werden, die vertrauliche Informationen schützen. Job Runner (GitLab Runner) ist jetzt FIPS 140-2-konform für AMD64-Rechenarchitekturen und Red Hat Enterprise Linux-Distributionen. In diesem Epic können Sie Diskussionen über GitLab FIPS-Compliance lesen.

GitLab-Job-Handler-Dokumentation und Originalticket.

Übertragen von Audit-Ereignissen Sie können jetzt Audit-Ereignisse an das Ziel Ihrer Wahl senden. Dies ist eine großartige Möglichkeit, Audit-Ereignisse von GitLab mit anderen Datenquellen, die Sie haben, zu korrelieren, ein Backup von Audit-Ereignissen zu erstellen oder Ihre eigene Automatisierung zu erstellen, um Maßnahmen zu ergreifen, wenn ein bestimmtes Ereignis eintritt.

Sie können einen HTTPS-Endpunkt mit unserer neuen GraphQL-API angeben und Ereignisse werden als Webhooks an ihn gesendet. Diese Nachrichten enthalten die gleichen Informationen wie in der Audit-Ereignis-Benutzeroberfläche: welche Änderung stattgefunden hat, wann sie stattgefunden hat, wer beteiligt war und zusätzliche Metadaten.

Nachdem Sie diese Nachrichten erhalten haben, können Sie sie nach Benutzer oder Typ filtern oder diese Daten an ein anderes Tool eines Drittanbieters weitergeben. Dies ist eine großartige Möglichkeit, benutzerdefinierte Automatisierungen basierend auf Ereignissen auszulösen, z. B. das Erstellen eines neuen Benutzers oder das Ändern eines Schlüsselparameters. Wir können es kaum erwarten zu sehen, wofür Sie diese Funktion verwenden werden! Erzählen Sie uns von Ihren Erfahrungen im entsprechenden Epos.

Dokumentation zu Broadcast-Audit-Events und dem Original-Epos.

Gruppenzugriffstoken können Sie mit einem einzigen Token Aktionen für Gruppen ausführen, Projekte in der Gruppe verwalten und sich bei Git über HTTPS authentifizieren (in GitLab 14.2 und höher).

Zuvor waren Wildcard-Zugriffstoken nur für selbstverwaltete GitLab-Instanzen verfügbar und wurden nur über die Rails-Konsole erstellt. Sie können jetzt Gruppenzugriffstoken über die Benutzeroberfläche und die API erstellen. Sie können den Tokennamen, das Ablaufdatum und den Umfang angeben. Sie können auch ein vorhandenes generisches Zugriffstoken widerrufen.

Danke an Fabio Huser für diesen Beitrag!

Dokumentation zu Gruppenzugangstoken und Originalticket.

Weitere Verbesserungen in GitLab 14.7

bbabo.Net