RBAC mit GitLab und Keycloak automatisieren

Sicherheit beginnt mit Struktur. Der Aufbau einer skalierbaren und sicheren Entwicklungsplattform erfordert die richtige Grundlage – insbesondere rollenbasierte Zugriffskontrolle (RBAC).

Die NIS2-Richtlinie (EU) 2022/2555 fordert in Artikel 21 "Maßnahmen zur Verwaltung des Zugriffs auf Netz- und Informationssysteme". Automatisierte RBAC erfüllt diese Anforderung durch systematische Zugriffskontrolle nach dem Least-Privilege-Prinzip mit lückenloser Audit-Trail-Dokumentation.

GitLab entwickelte den RBAC Accelerator – ein modulares, ergebnisorientiertes Enablement-Programm, das große Unternehmen bei der Definition, Durchsetzung und Skalierung von Zugriffsrichtlinien in GitLab unterstützt.

Diese Grundlage ermöglicht umfassendere Transformation. Der Secure SDLC Accelerator, aufbauend auf dem RBAC Accelerator, befähigt Kunden zur Integration von Compliance, Sicherheit und DevSecOps-Best-Practices in ihre Workflows.

GitLab-Kunde Lely, ein bedeutender niederländischer Hersteller landwirtschaftlicher Maschinen und Roboter, nutzte diesen Ansatz für die Migration zu GitLab Dedicated. Lely automatisierte die Nutzer-Bereitstellung via Azure AD mittels OpenID Connect (OIDC), erzwang Least-Privilege-Richtlinien und schuf ein skalierbares, wiederverwendbares Zugriffsmodell zur Unterstützung zukünftiger Entwicklungsinitiativen.

Diese Anleitung führt durch eine praktische Implementierung von GitLab + Keycloak + OIDC, von der Ausführung des Setups in einer Docker-Umgebung über die Automatisierung des Rollen-Mappings und den Entwurf einer skalierbaren Gruppenhierarchie bis zur Ausrichtung der GitLab-Zugriffskontrollen an Unternehmensstruktur und Compliance-Zielen.

Dies ist ein lokales Demo-Setup ausschließlich für Proof-of-Concept-Zwecke.

Ob beim Einstieg oder bei der Optimierung im großen Maßstab: Diese modulare Grundlage gewährleistet nicht nur sichere Zugriffskontrolle, sondern ermöglicht alles Weitere.

Erste Schritte mit Zugriffskontroll-Planung

Vor der Implementierung von Tooling ist das Verständnis der Zugriffslandschaft wesentlich.

Zu berücksichtigen:

• Welche GitLab-Ressourcen benötigen Schutz (Projekte, Gruppen, Umgebungen)?
• Wer sind die Personas (Developers, Maintainers, Guests usw.)?
• Welche Organisationseinheiten (Abteilungen, Kostenstellen) sollen Zugriff regeln?
• Wie definiert die IdP-Struktur (Keycloak) Nutzer und Rollen?

In dieser Phase lassen sich entwerfen:

• Zugriffskontroll-Matrix
• GitLab-Gruppenhierarchie (team- oder produktbasiert)
• Least-Privilege-Richtlinien-Annahmen

Beispiel Gruppenhierarchie

Demo-System-Setup: GitLab + Keycloak in lokaler Docker-Umgebung

Voraussetzungen

• Docker, Docker Compose, OpenSSL
• GitLab Version 17.7.3 und Keycloak Version 23.0.7 Container-Images
• Selbstsignierte Zertifikate

.env-Konfiguration

Das Demo-Setup nutzt folgende GitLab- und Keycloak-Versionen, Ports und Secrets.

GitLab-Konfiguration

GITLAB_VERSION=17.7.3-ee.0

GITLAB_EXTERNAL_URL=http://localhost:8081

GITLAB_SSH_PORT=8222

Keycloak-Konfiguration

KEYCLOAK_VERSION=latest

KEYCLOAK_ADMIN=<your-admin-username>

KEYCLOAK_ADMIN_PASSWORD=<your-admin-password>

KEYCLOAK_HTTPS_PORT=8443

KEYCLOAK_CLIENT_SECRET=<your-client-secret>  # Get this from Keycloak after setup

SSL-Zertifikate generieren

Zur Etablierung von Vertrauen zwischen GitLab und Keycloak, insbesondere in einer selbst gehosteten Docker-Umgebung, müssen selbstsignierte SSL-Zertifikate generiert werden. Diese Zertifikate ermöglichen verschlüsselte HTTPS-Kommunikation und stellen sicher, dass GitLab sicher mit Keycloak während des OIDC-Authentifizierungsprozesses kommunizieren kann.

Für Produktivumgebungen empfiehlt sich die Nutzung von Zertifikaten einer vertrauenswürdigen Certificate Authority (CA), für lokales Testen und Entwicklung sind selbstsignierte Zertifikate ausreichend.

Schrittweise Anleitung:

1. Ordner für die Zertifikate erstellen.

mkdir -p certs

2. Selbstsigniertes Zertifikat mit OpenSSL generieren.

  -keyout certs/tls.key \
  -out certs/tls.crt \
  -subj "/CN=keycloak" \
  -addext "subjectAltName=DNS:keycloak,DNS:localhost"

3. PKCS12-Keystore für Keycloak erstellen.

  -in certs/tls.crt \
  -inkey certs/tls.key \
  -out certs/keystore.p12 \
  -name keycloak \
  -password pass:password

Service mit Docker Compose starten

Mit den Zertifikaten lässt sich die lokale GitLab + Keycloak-Umgebung mittels Docker Compose aufsetzen:

version: '3.8'  services:
  gitlab:
    image: gitlab/gitlab-ee:${GITLAB_VERSION}
    container_name: gitlab 
    restart: unless-stopped 
    environment:
      GITLAB_OMNIBUS_CONFIG: | 
        external_url '${GITLAB_EXTERNAL_URL:-http://localhost:8081}' 
        gitlab_rails['gitlab_shell_ssh_port'] = ${GITLAB_SSH_PORT:-8222}
        gitlab_rails['display_initial_root_password'] = true
        # OAuth Configuration 
        gitlab_rails['omniauth_enabled'] = true 
        gitlab_rails['omniauth_allow_single_sign_on'] = ['openid_connect'] 
        gitlab_rails['omniauth_block_auto_created_users'] = false 
        gitlab_rails['omniauth_providers'] = [
            { 'name' => 'openid_connect', 'label' => 'Keycloak', 'args' => { 'name' => 'openid_connect', 'scope' => ['openid', 'profile', 'email'], 'response_type' => 'code', 'issuer' => 'https://localhost:8443/realms/GitLab', 'client_auth_method' => 'query', 'discovery' => false, 'uid_field' => 'preferred_username', 'pkce' => true, 'client_options' => { 'identifier' => 'gitlab', 'secret' => '${KEYCLOAK_CLIENT_SECRET}', 'redirect_uri' => '${GITLAB_EXTERNAL_URL:-http://localhost:8081}/users/auth/openid_connect/callback', 'authorization_endpoint' => 'https://localhost:8443/realms/GitLab/protocol/openid-connect/auth', 'token_endpoint' => 'https://keycloak:8443/realms/GitLab/protocol/openid-connect/token', 'userinfo_endpoint' => 'https://keycloak:8443/realms/GitLab/protocol/openid-connect/userinfo', 'jwks_uri' => 'https://keycloak:8443/realms/GitLab/protocol/openid-connect/certs'
                    }
                }
            }
        ] 
    volumes:
      - gl-config:/etc/gitlab
      - gl-data:/var/opt/gitlab
      - ./certs/tls.crt:/etc/gitlab/trusted-certs/keycloak.crt
    ports:
      - '${GITLAB_EXTERNAL_PORT:-8081}:8081'
      - '${GITLAB_SSH_PORT:-8222}:22'
    shm_size: '256m' 
  keycloak:
    image: quay.io/keycloak/keycloak:${KEYCLOAK_VERSION}
    container_name: keycloak-server 
    restart: unless-stopped 
    command: [ "start-dev", "--import-realm", "--https-port=${KEYCLOAK_HTTPS_PORT}", "--https-key-store-file=/etc/x509/https/keystore.p12", "--https-key-store-password=password" ] 
    volumes:
      - ./data:/opt/keycloak/data/import
      - ./certs:/etc/x509/https
    environment:
      KEYCLOAK_ADMIN: ${KEYCLOAK_ADMIN}
      KEYCLOAK_ADMIN_PASSWORD: ${KEYCLOAK_ADMIN_PASSWORD}
    ports:
      - "${KEYCLOAK_HTTPS_PORT}:8443"
volumes:
  gl-config:
  gl-data:

Der Befehl docker-compose up -d startet die GitLab + Keycloak-Umgebung in Minuten. bash docker-compose up -d

Keycloak-Realm-Konfiguration

Der Keycloak-Realm wird beim Start automatisch konfiguriert, wie in der docker-compose-Datei definiert. Die Realm-Konfiguration umfasst:

• Vorkonfigurierter GitLab-Client - Standard-Client-Secret Zugriff auf die Keycloak-Admin-Konsole unter https://localhost:8443:
• Username: admin - Passwort: aus der .env-Datei - Zur Verifikation des Setups:
  • In Keycloak-Admin-Konsole einloggen
  • GitLab-Realm auswählen
  • Clients > gitlab prüfen

Die Client-Konfiguration gegen die Umgebung verifizieren. Zur Demonstration des automatisierten RBAC-Mechanismus sind folgende Schritte erforderlich:

• Realm-Rollen auf GitLab-Rollen mappen - Gruppenstruktur mit Rollen-Mapping erstellen, entsprechend dem Gruppe-Untergruppe-Projekt-Muster in GitLab Vor der Bereitstellung erster Nutzer in die Nutzergruppen empfiehlt sich der Login in die GitLab-Instanz zum Abruf des Instanz-Root-Passworts:

1. GitLab unter http://localhost:8081 aufrufen. 2. Root-Passwort abrufen: bash docker exec gitlab grep 'Password:' /etc/gitlab/initial_root_password
2. Als Root mit dem abgerufenen Passwort einloggen.

Alles zusammenführen

Zur Demonstration der Leistungsfähigkeit dieses integrierten RBAC-Modells beginnt ein realer Nutzer-Journey – von der Identität zum Zugriff.

In Keycloak wird ein Nutzer gezeigt, der spezifischen Realm-Rollen (z.B. developer, maintainer) und Gruppen (z.B. /engineering/platform) zugewiesen ist. Diese Rollen wurden via OIDC-Claims auf GitLab-Zugriffsebenen gemappt, während Gruppenzugehörigkeiten mit GitLabs strukturierter Hierarchie von Root-Gruppen, Untergruppen und Projekten übereinstimmen.

Beim Login über GitLabs SSO-Keycloak-Endpoint wird der Nutzer automatisch in die korrekte Gruppe bereitgestellt und erhält die entsprechende Rolle – ohne manuelle Intervention.

In GitLab lässt sich sehen, dass der Nutzer mit dem zugewiesenen Projekt interagieren kann: Ein Developer kann beispielsweise Code pushen und einen Merge Request öffnen, aber nicht in geschützte Branches mergen – Validierung des Least-Privilege-Modells.

ISO 27001 Anhang A.9.2 fordert Verwaltung privilegierter Zugriffsrechte. Die automatisierte OIDC-basierte Rollenbereitstellung erfüllt diese Anforderung durch systematische Zugriffskontrolle: Nutzer erhalten ausschließlich die minimal erforderlichen Berechtigungen, dokumentiert durch Audit-Trails in GitLab und Keycloak.

Abschließend lässt sich Zugriff über mehrere Teams oder Produkte demonstrieren, die zentral in Keycloak verwaltet, aber präzise in GitLab durch Gruppensynchronisation und Berechtigungsvererbung durchgesetzt werden. Diese Demo illustriert nicht nur Rollenzuweisung, sondern wie GitLab und Keycloak gemeinsam Echtzeit-Zugriffs-Governance im großen Maßstab liefern – bereit für sichere, konforme Enterprise-Softwareentwicklung.

Warum GitLab?

GitLabs umfassende, intelligente DevSecOps-Plattform ist die ideale Grundlage für sichere, skalierbare Zugriffsverwaltung. Mit nativem OIDC-Support, granularer Rollen-Durchsetzung, SCIM-basierter Nutzer-Bereitstellung und integriertem Audit-Logging ermöglicht GitLab Unternehmen, Kontrolle zu zentralisieren ohne Agilität zu beeinträchtigen. Die flexible Gruppenhierarchie spiegelt Unternehmensstrukturen wider und erleichtert die Zugriffsverwaltung über Teams hinweg.

Die Integration mit Identity-Providern wie Keycloak automatisiert Onboarding, gewährleistet Least-Privilege-Zugriff und schafft eine nahtlose Identität-zu-Berechtigung-Pipeline, die regulatorische und Sicherheitsziele unterstützt. Als Kernkomponente von GitLabs Sicherheitsfunktionen ist RBAC direkt mit CI/CD, Policy-Durchsetzung und Vulnerability-Management-Workflows verbunden.

Zusammenfassung

RBAC ist erst der Anfang. Mit GitLab und Keycloak wird nicht nur Zugriff gesichert, sondern strukturierte, automatisierte Governance ermöglicht, die skaliert. Bei der Erweiterung auf Policy-Durchsetzung, Secure SDLC und DevSecOps-Automatisierung wird diese Grundlage zum Startpunkt für nachhaltige Enterprise-Software-Delivery.

Starte noch heute mit RBAC in GitLab mit einer kostenlosen Testversion von GitLab Ultimate. Jetzt anmelden!