GitLab-Seats unter Kontrolle behalten – mit Restricted Access

Restricted Access hilft Instance-Admins, Gruppen-Ownern und Kostenverantwortlichen dabei, die Anzahl der genutzten Seats (Lizenzplätze) planbar zu halten – mit weniger manueller Kontrolle. Für Workflows rund um Identity-Provider-Provisionierung, die Reaktivierung inaktiver Nutzender und Anmeldeabläufe schließt die aktuelle Version mehrere Lücken. Dadurch lässt sich Restricted Access in produktiven Umgebungen zuverlässiger einsetzen.

Dieser Artikel beschreibt, was Restricted Access leistet, was sich geändert hat und wie sich die Funktion aktivieren lässt.

Was ist Restricted Access?

Restricted Access ist eine Seat-Control-Funktion für GitLab.com und GitLab Self-Managed. Sobald alle lizenzierten Seats belegt sind, blockiert GitLab bei aktivierter Funktion das Hinzufügen weiterer zahlungspflichtiger Nutzender.

Damit lässt sich unerwartetes Seat-Wachstum vor der Vertragsverlängerung vermeiden, und die tatsächliche Seat-Nutzung bleibt näher an der gekauften Lizenzanzahl. Restricted Access verhindert neue Überbelegungen ab dem Zeitpunkt der Aktivierung – bestehende Überbelegungen werden dadurch nicht rückgängig gemacht.

Nutzende, die keinen Projekt- oder Gruppenzugriff benötigen – etwa solche, die sich über GitLab als OpenID-Connect-Provider (OIDC) authentifizieren –, lassen sich der nicht zahlungspflichtigen Rolle Minimal Access zuweisen. Eine Authentifizierung bleibt für sie weiterhin möglich, ohne dass dafür ein bezahlter Seat verbraucht wird.

Bestehende zahlungspflichtige Mitglieder bleiben unangetastet

Restricted Access wirkt ausschließlich vorausschauend. Wird die Funktion für eine Gruppe oder Instanz aktiviert, die ihr Seat-Limit bereits überschritten hat, stuft GitLab bestehende zahlungspflichtige Mitglieder weder herab noch entfernt oder blockiert es sie. Bestehende Mitgliedschaften bleiben unverändert bestehen. Bei einer bereits vorliegenden Überbelegung müssen Admins die Nutzung weiterhin manuell auf das gekaufte Limit zurückführen – etwa durch das Entfernen zahlungspflichtiger Mitglieder oder den Kauf zusätzlicher Seats.

Sobald die Seat-Nutzung wieder innerhalb des Lizenzlimits liegt, verhindert Restricted Access weiteres zahlungspflichtiges Wachstum darüber hinaus.

Restricted Access arbeitet enger mit dem Identity Provider zusammen

Ein wesentlicher Teil der jüngsten Weiterentwicklung betraf das Zusammenspiel von Restricted Access mit identitätsbasierter Provisionierung.

Ist Restricted Access aktiviert und stehen keine Seats mehr zur Verfügung, werden über SAML, SCIM oder LDAP provisionierte Nutzende nicht mehr direkt in zahlungspflichtige Rollen aufgenommen. Stattdessen weist GitLab ihnen die nicht zahlungspflichtige Rolle Minimal Access zu. Die Synchronisierung läuft dabei weiter, ohne eine sofortige Überbelegung auszulösen.

Für Organisationen mit automatisierter Provisionierung, die zugleich eine engere Kostenkontrolle anstreben, ohne auf zentrales Identity-Management zu verzichten, ist dieses Verhalten von besonderem Nutzen.

Nutzt eine Organisation GitLab als OIDC-Provider und benötigen einzelne Nutzende lediglich eine Authentifizierung statt Projekt- oder Gruppenzugriff, bleibt die Zuweisung von Minimal Access auf oberster Gruppenebene ein sinnvolles Muster. Diese Nutzenden verbrauchen keine zahlungspflichtigen Seats, und Konten mit ausschließlich Minimal Access lassen sich auch dann reaktivieren, wenn keine Seats mehr verfügbar sind.

Inaktive Nutzende verursachen keine stillen Überbelegungen mehr

GitLab deaktiviert Nutzende automatisch, wenn über einen konfigurierbaren Zeitraum keine Aktivität vorliegt, und gibt dadurch Seats wieder frei. Meldeten sich solche Nutzenden zuvor über OIDC oder Single Sign-on (SSO) erneut an, konnten sie unbemerkt als zahlungspflichtige Nutzende reaktiviert werden – Restricted Access wurde dabei umgangen, und es entstanden Lizenz-Überbelegungen.

Ist Restricted Access aktiv und stehen keine Seats zur Verfügung, gelangen zurückkehrende inaktive Nutzende nun stattdessen in einen Genehmigungsstatus. Ihre Gruppen- und Projektmitgliedschaften bleiben dabei erhalten, und ein Admin kann sie freigeben, sobald wieder ein Seat verfügbar ist.

Warnungen, Banner und Benachrichtigungen sind klarer

Auch der laufende Betrieb von Restricted Access wurde vereinfacht.

Direkt im Produkt zeigen neue Hinweise Admins, was vor und nach Erreichen des Seat-Limits passiert. Je nach Szenario gehören dazu:

• Kontextbezogene Warnungen bei der Konfiguration von LDAP-Sync, SAML-Gruppenverknüpfungen oder SCIM-Provisionierung, während Restricted Access aktiv ist
• Getrennte Zustände im Produkt für die Annäherung an das Seat-Limit und das Erreichen des Seat-Limits
• E-Mail-Benachrichtigungen an Gruppen-Owner oder Instance-Admins, wenn Nutzende mangels verfügbarer Seats der Rolle Minimal Access zugewiesen werden
• Audit-Sichtbarkeit für Minimal-Access-Fallback-Ereignisse

Dabei geht es nicht nur darum, neue zahlungspflichtige Ergänzungen zu blockieren, sondern dieses Verhalten nachvollziehbar und steuerbar zu machen.

Der Einstellungs-Cache von GitLab Self-Managed

Bei GitLab Self-Managed werden Anwendungseinstellungen aus Performance-Gründen standardmäßig 60 Sekunden lang zwischengespeichert.

Beim Wechsel zwischen Restricted Access und User Cap können UI-Änderungen oder das Seat-Control-Verhalten dadurch mit Verzögerung sichtbar werden. Der Cache aktualisiert sich automatisch, und das Verhalten wird danach konsistent. Bei Bedarf lässt sich das Cache-Intervall anpassen.

Weitere Details liefert die Dokumentation zum Application-Settings-Cache.

Der Unterschied zwischen Restricted Access und User Cap

Restricted Access und User Cap hängen zusammen, lösen aber unterschiedliche Probleme.

User Cap überführt neue Nutzende unabhängig von der Seat-Verfügbarkeit in einen Genehmigungs-Workflow, den Admins oder Gruppen-Owner prüfen. Restricted Access dagegen ist direkt an die Anzahl lizenzierter Seats gekoppelt und blockiert neue zahlungspflichtige Ergänzungen ausschließlich dann, wenn keine Seats mehr verfügbar sind.

Anders gesagt: User Cap ist eine Genehmigungssteuerung, Restricted Access eine Seat-Limit-Steuerung.

Beide Funktionen lassen sich zudem nicht gleichzeitig aktivieren. Wird Restricted Access aktiviert, deaktiviert GitLab User Cap automatisch. Auf GitLab.com kann der Wechsel von User Cap zu Restricted Access zusätzlich ausstehende Mitgliedschaften betreffen – die dokumentierten Auswirkungen sollten vor der Umstellung geprüft werden.

Erste Schritte

Restricted Access steht auf GitLab.com und für GitLab Self-Managed zur Verfügung.

• Auf GitLab.com aktivieren Gruppen-Owner die Funktion unter Einstellungen > Allgemein > Berechtigungen und Gruppenfunktionen > Seat Control > Restricted Access.
• Bei GitLab Self-Managed aktivieren Admins sie unter Admin > Einstellungen > Allgemein > Neue Benutzerkonto-Einschränkungen > Seat Control > Restricted Access.
• Auf GitLab.com steht Restricted Access nicht zur Verfügung, wenn die oberste Gruppe für eine externe Gruppe freigegeben ist.

Für Teams, die Seat-Wachstum gezielter steuern, Abrechnungsüberraschungen vermeiden und Provisionierung sowie Reaktivierung nachvollziehbarer gestalten möchten, bietet Restricted Access den entsprechenden Mechanismus.

Ressourcen

• Dokumentation zu Restricted Access
• Dokumentation zur Seat-Verwaltung
• Dokumentation zum Application-Settings-Cache