GitLab Server Onboarding in gemischten Umgebungen
Seed-Referenz fuer neue GitLab-Server, Windows-Infrastruktur-Anbindung und den operativen Aufbau von Kunden, Projekten und Rollen in hybriden Landschaften.
Seed Regelwerk
Windows + Linux + Cloud
GitLab Bootstrap
Fail-Closed Start
kein Hidden State
1. Boundary: Was gehoert in Seed, was in Node
| Bereich | Seed (IIO) | Node (Tenant) |
|---|---|---|
| Methodik | Onboarding-Ablauf, Gates, Rollenrahmen | Konkrete Umsetzung je Kunde/Standort |
| Windows-Anbindung | Standardmuster fuer AD, Entra, Intune, Fileshares, SQL/IIS | Reale Endpunkte, Trusts, OU, Gruppen, Firewall-Regeln |
| GitLab-Server | Referenzprofile klein/mittel/gross | Tatsaechliche Hosts, Runners, Backup-Ziele, SLA |
| Personen/Rollen | Rollenklassen und Pflichtfelder | Konkrete Mitarbeiter, Kundenmitarbeiter, Freelancer |
Regel: Seed definiert das Wie, Node dokumentiert das Wer/Wo/Womit.
2. Typische Windows-Infrastrukturen und IIO-Anbindung
Active Directory Domain Services
- Importiert werden nur erforderliche Identity-Attribute.
- Gruppen-Mapping auf IIO-Rollen via expliziter Zuordnungstabelle.
- Kein direkter Rollengrant ohne Review-Transaction.
Entra ID / Hybrid Identity
- SSO fuer Operatoren mit tenant-spezifischer App-Registrierung.
- Conditional Access als vorgelagertes Gate.
- Emergency Breakglass-Accounts separat dokumentieren.
Intune / SCCM Endgeraete
- Device Compliance darf Zugriffsfreigabe beeinflussen, aber nicht ersetzen.
- Nur verwaltete Endgeraete fuer privilegierte Rollen.
- Lifecycle-Events als auditable State-Updates erfassen.
Windows File Services, DFS, SMB
- SMB bleibt Datenquelle, nicht Governance-Quelle.
- Objekte werden in IIO klassifiziert (own/reference/imported/archive).
- Rechteuebernahme immer ueber Boundary-Pruefung.
IIS / MSSQL Applikationen
- Altsysteme werden ueber Adapter angebunden, nicht direkt gespiegelt.
- Schreibzugriffe nur ueber definierte Operationspfade.
- Schema-Drift wird als BLOCK klassifiziert.
RDP / VDI / Bastion
- Remote-Zugriff strikt rollenbasiert und zeitlich begrenzt.
- Session-Aufzeichnung fuer kritische Aenderungen empfohlen.
- Privileged Access nicht in Public-Doku spiegeln.
3. Referenzaufbau fuer gemischte Umgebungen
Erst Daten- und Rollenfluss festlegen, dann Tools verbinden. Die Architektur bleibt klein startbar und skaliert in Stufen.
mixed-environment/
identity/
ad/
entra/
role-mapping/
infra/
windows/
linux/
cloud/
gitlab/
servers/
groups/
projects/
runners/
tenants/
customer-private/
customer-public/
operations/
onboarding/
transitions/
offboarding/
evidence/| Zone | Zweck | Gate |
|---|---|---|
| identity | Quellen fuer Personen, Gruppen, Rollenhinweise | Role + Boundary |
| infra | Systemkontexte aus Windows/Linux/Cloud | Boundary + Transaction |
| gitlab | Code, Pipelines, Delivery, Automation | Story + Transaction + Audit |
| tenants | Kunden und Projekte mit Trennung private/public | Boundary |
| operations | Onboarding, Moves, Changes, Leaves | Audit |
4. GitLab-Server Profile nach Org-Groesse
| Profil | Typischer Umfang | Empfohlener Aufbau | Starter-Schritt |
|---|---|---|---|
| Klein | 1-3 Teams, 5-40 Nutzer | 1 GitLab-Instanz, 1 Runner-Cluster, taegliches Backup | Single-Server, SSH-first, 1 Pilotkunde |
| Mittel | 4-12 Teams, 40-300 Nutzer | HA-Services, getrennte Runner-Pools, stage/prod Trennung | 2 Pilotkunden, Rollenpakete vollständig |
| Gross | 13+ Teams, Multi-Region | Geo-Setup, zentraler Compliance-Layer, segmentierte Group-Struktur | Landing-Zone je Region plus Federation-Regeln |
5. Vollstaendiger Onboarding-Katalog
5.1 Neue Kunden onboarden
Pflichtfelder
- Kunden-ID, Verantwortliche, Vertragsstatus, Boundary-Default.
- Infrastrukturprofil (Windows-only, Linux-only, hybrid).
- Datenschutz- und Compliance-Klasse.
Gate-Reihenfolge
- Actor + Story vorhanden.
- Role-Mapping freigegeben.
- Boundary private gesetzt.
- Transaction create_customer protokolliert.
5.2 Neue Projekte onboarden
- Pro Projekt exakt eine Story und ein Owner.
- GitLab Group/Repo nach Namenskonvention anlegen.
- Runner-Zuordnung nach Risiko- und Datenklasse setzen.
- Projekt startet erst nach GO im Review-Gate.
5.3 Interne Mitarbeitende onboarden
- Identity aus AD/Entra uebernehmen, Rolle in IIO explizit setzen.
- Least Privilege default, Erhoehung nur befristet.
- Zugriffsrechte fuer GitLab, Operations und Customer-Lanes getrennt.
5.4 Kundenmitarbeitende onboarden
- Kundenmitarbeitende immer tenant-begrenzt.
- Keine Seed-admin Rechte.
- Public- und Private-Pfade im gleichen Projekt strikt getrennt.
5.5 Freelancer onboarden
- Vertrag + NDA als Voraussetzung fuer Zugriff.
- Zeitfenster und Scope technisch erzwingen (Branch, Repo, Laufzeit).
- Pflicht-Offboarding mit revocation + evidence innerhalb 24h nach Ende.
6. Minimaler Starter-Run fuer den Sofortstart
Damit ihr direkt loslegen koennt, startet mit einem kleinen, voll pruefbaren Pfad:
- Einen GitLab-Server (oder ein dediziertes Segment) als Pilot definieren.
- Einen Kunden mit privater Boundary anlegen.
- Ein Projekt plus internes Team plus ein Kundenmitarbeiter hinterlegen.
- Ersten Freelancer nur read/review-basiert anbinden.
- Review ausfuehren und als GO/BLOCK dokumentieren.
Thin-through-path zuerst
danach schrittweise erweitern
7. Fail-Closed Situationen (immer BLOCK)
- Unbekannter Actor oder fehlende Rollenbindung.
- Windows-Gruppen werden direkt zu High-Privilege-Rollen gemappt ohne Review.
- Kunden-Private-Daten landen in Public-Artefakten.
- Freelancer bleibt nach Vertragsende aktiv.
- Projekt ohne Story oder ohne Reviewer.