Dein Blog zum Thema digitales Business

Beim Onboarding entscheidet sich, wie groß der Rechte-Berg später wird

Eine neue Person kommt ins Team, und jemand muss ihr Zugang zu GitHub geben. Der bequeme Weg: schauen, was ein Kollege mit ähnlicher Aufgabe darf, und dasselbe eintragen. Damit erbt die neue Person nicht nur, was sie braucht, sondern alles, was sich bei dem Kollegen über die Zeit angesammelt hat. Ein anderer bequemer Weg ist Admin oder Write auf alle Repositories, damit sie „sofort loslegen kann“. Beides vergibt Rechte, die erst am Ende der Einarbeitung nötig wären, obwohl die Person am Anfang steht.

GitHub sagt zur Vergabe von Rollen in der Doku zu Repository-Rollen sinngemäß: Wähle die Rolle, die zur Funktion einer Person oder eines Teams passt, ohne ihr mehr Zugriff zu geben, als sie braucht. Dieser Beitrag übersetzt den Satz in einen Ablauf entlang der Zeitachse: Was gibst du zum Eintritt, was zur Einarbeitung, was erst, wenn Verantwortung dazukommt.

Grundlage sind die Dokuseiten zu Repository-Rollen, Basisberechtigungen, Teams und Outside Collaborators, dazu die Seiten zur Konvertierung eines Mitglieds und zur Übersicht der Personen mit Zugriff. Wo eine Aussage aus der Doku stammt, steht die Quelle im Satz. Empfehlungen ohne Quellenangabe sind die Übersetzung in deine Praxis.

Drei Stufen entlang der Zeitachse

Stufe 1: Eintritt, Mitglied mit Basisberechtigung. Die Person wird Mitglied der Organisation. Laut Doku ist die Rolle „Member“ die Standardrolle ohne Administrationsrechte, und Mitglieder dürfen standardmäßig unter anderem Repositories und Projekte anlegen. Was Mitglieder darüber hinaus auf Repositories dürfen, regelt die Basisberechtigung. Nach der Doku gilt sie für alle Mitglieder der Organisation auf jedem Repository, und Änderungen wirken auf neue und bestehende Mitglieder. Eine höhere Berechtigung, die ein Admin des Repositories einem Mitglied gibt, übersteuert die Basisberechtigung. Deshalb gehört die Basisberechtigung an den Anfang deiner Planung: Alles, was du dort einstellst, bekommt jede neue Person automatisch mit. Auf der Einladungsseite wählst du die Rolle in der Organisation und kannst die Person optional direkt einem Team zuordnen.

Stufe 2: Einarbeitung, Team mit Rolle auf den Repositories der Aufgabe. Die Person kommt in das Team, das ihre Aufgabe abbildet, und bekommt darüber genau die Repositories, an denen sie arbeitet. Fünf Rollen stehen für Repositories zur Wahl, von wenig nach viel: Read, Triage, Write, Maintain und Admin. Starte mit der niedrigsten Rolle, mit der die Aufgabe geht, das kann Read oder Triage sein. Das ist eine Empfehlung, keine Aussage der Doku, und sie ist sinnvoll, weil Write mehr enthält, als der Name vermuten lässt. Laut Tabelle der Doku darf Write nicht nur pushen und Pull Requests mergen, sondern auch GitHub-Actions-Workflows anlegen, ausführen und ändern sowie Actions-Secrets anlegen, ändern und löschen. Wer Write vergibt, gibt damit auch Zugriff auf die Workflows und Secrets des Repositories.

Stufe 3: Verantwortung, höhere Rolle bei konkretem Bedarf. Maintain und Admin gibst du, wenn jemand ein Repository tatsächlich verantwortet. Die Doku beschreibt Admin als Rolle für Personen, die vollen Zugriff brauchen, einschließlich sensibler und destruktiver Aktionen. Laut Tabelle gehören dazu unter anderem das Verwalten von Zugriff für Personen, Teams und Outside Collaborators, Webhooks und Deploy Keys, die Sichtbarkeit des Repositories und das Löschen oder Übertragen. Ein Recht, das an eine Aufgabe gebunden ist, gehört mit dieser Aufgabe wieder zurück. Plane diesen Rückbau beim Vergeben mit ein, sonst wandert die Erhöhung in den Dauerzustand.

Schnellcheck für jede Erhöhung: Welche Aufgabe braucht das Recht, wer nimmt es zurück, wenn die Aufgabe erledigt ist, und reicht die nächstniedrigere Rolle?

Team-Zuweisung statt Einzelrechte

Die Doku nennt Teams als Mittel, den Zugriff von Personen in einer Organisation zu verwalten. Repository-Rollen lassen sich Mitgliedern, Outside Collaborators und Teams zuweisen. Für das Onboarding ist die Team-Variante aus zwei Gründen die bessere:

• Der Zugang folgt der Funktion, nicht der Person. Wer in das Team für ein Produkt aufgenommen wird, bekommt dessen Repositories. Wer die Aufgabe wechselt, wechselt das Team. Es bleibt keine Liste von Einzelfreigaben, die sich keiner mehr erklären kann.
• Es gibt einen Ort für die Änderung. Willst du einer ganzen Gruppe eine Rolle geben oder nehmen, änderst du sie einmal am Team. Einzelrechte auf Repository-Ebene musst du dagegen pro Person und pro Repository nachhalten.

Bei verschachtelten Teams erben Kindteams laut Doku die Rechte des Elternteams, deshalb bekommt eine Person mit dem Beitritt in ein Kindteam alles, was darüber hängt. Wie diese Vererbung überrascht, steht im Beitrag zu effektiven und nominalen Rechten.

Einzelrechte bleiben möglich, in den Repository-Einstellungen gibt es dafür die Zugriffsverwaltung für Personen. Behandle sie als Ausnahme mit Begründung und nicht als Normalfall, weil sie in keiner Team-Struktur auftauchen.

Outside Collaborators: Zugang ohne Mitgliedschaft

Ein Outside Collaborator ist laut Doku eine Person, die kein Mitglied der Organisation ist, aber auf ein oder mehrere Repositories der Organisation zugreifen darf. Die Doku zu Organisationsrollen nennt als Beispiel Berater oder befristete Mitarbeitende. Vier Eigenschaften ändern das Onboarding grundlegend:

1. Kein Team. Outside Collaborators können keinem Team angehören, die Team-Mitgliedschaft ist Mitgliedern der Organisation vorbehalten. Die Regel „Zugang über Team“ gilt für sie nicht.
2. Keine Basisberechtigung. Sie gilt laut Doku nicht für Outside Collaborators. Der Zugang entsteht nur durch die Rolle, die du auf dem einzelnen Repository vergibst, mit der Stufe, die du für jeden Collaborator einzeln wählst.
3. Forks separat. Soll ein Outside Collaborator auch auf Forks des Repositories zugreifen, musst du ihn dort zusätzlich hinzufügen.
4. Zwei-Faktor-Pflicht. Verlangt die Organisation Zwei-Faktor-Authentifizierung, müssen Outside Collaborators sie vor dem Annehmen der Einladung aktivieren.

Daraus folgt für deine Praxis, was die Doku nicht ausdrücklich sagt: Für Externe ist die Einzelvergabe der Normalfall, und deshalb ist die Nachverfolgung wichtiger als bei Teams. Halte pro Externem fest, für welches Repository, mit welcher Rolle und wofür er Zugang hat. Vergib für die Dauer der Zusammenarbeit die niedrigste Rolle, mit der die Aufgabe geht. Und nimm die Rechte mit dem Ende der Zusammenarbeit zurück, ohne auf den nächsten Review zu warten.

Ein Sonderfall ist der Wechsel von intern zu extern. Konvertierst du ein Mitglied zum Outside Collaborator, entfernt GitHub die Person laut Doku zur Konvertierung aus allen Teams. Der Zugriff auf Repositories, auf die sie direkt oder über frühere Team-Mitgliedschaften berechtigt war, bleibt aber bestehen. Die Doku empfiehlt deshalb, den Zugriff der Person danach zu prüfen. Eine Konvertierung ersetzt deshalb kein Aufräumen: Lege bewusst fest, welche Repositories der Person bleiben sollen, und entziehe den Rest einzeln.

Der Ablauf in fünf Schritten

Aus den drei Stufen und den Team-Regeln ergibt sich eine Reihenfolge, die du für jede neue Person gleich durchläufst. Sie ist eine Empfehlung und keine Vorgabe der Doku.

1. Vor der Einladung: Aufgabe der Person und das Team klären, das sie abbildet. Gibt es das Team nicht, legst du es an, statt Einzelrechte zu vergeben.
2. Einladung mit der niedrigsten Organisationsrolle und dem Team. Die Person bekommt Member und die Team-Zuordnung, nichts darüber hinaus.
3. Rolle des Teams auf den Repositories prüfen, bevor die Person das erste Mal arbeitet: Ist Write nötig, oder genügt Read oder Triage?
4. Erhöhungen einzeln begründen, mit Aufgabe und Rücknahme (siehe Schnellcheck oben). Für Maintain und Admin gilt das doppelt.
5. Gegenprobe: In den Repository-Einstellungen zeigt GitHub eine Übersicht der Teams und Personen mit Zugriff, die Doku zur Zugriffsübersicht nennt sie als Hilfe für Offboarding, Compliance-Nachweise und allgemeine Sicherheitsprüfungen. Prüfe dort für ein bis zwei Repositories, ob der Zugang der neuen Person dem Plan entspricht.

Testfälle, bevor du das Verfahren einführst

• Neue Person nur als Member ohne Team einladen: Prüfe, dass sie nur auf das zugreifen kann, was die Basisberechtigung vorsieht. Nach der Doku ist das Lesen öffentlicher Repositories ohnehin möglich, und interne Repositories sind mindestens lesbar, auch wenn die Basisberechtigung auf None steht.
• Dieselbe Person in ein Team mit Read auf einem Repository aufnehmen: Bei Basisberechtigung Read oder None kann sie lesen, aber nicht pushen.
• Ein Team mit Write auf einem Repository prüfen: Laut Doku darf Write Actions-Secrets ändern. Prüfe, ob du das für die Einarbeitung willst.
• Einen Outside Collaborator auf einem einzelnen Repository anlegen: Er taucht in keinem Team auf, und die Basisberechtigung gilt für ihn nicht.
• Ein Testmitglied zum Outside Collaborator konvertieren: Prüfe danach, auf welche Repositories der Zugriff bestehen bleibt.

Schlägt ein Fall anders aus als erwartet, stimmt deine Annahme über die Rechtestruktur nicht, und du korrigierst sie, bevor die erste echte Person eingeladen wird.

Wo das Thema an Nachbarthemen grenzt

Dieser Beitrag behandelt den Anfang: wie du Zugang für eine neue Person aufbaust. Wie sich Basisberechtigung, Team-Vererbung und direkte Rechte zu den tatsächlich wirksamen Rechten addieren, steht in Effektive vs. nominale Rechte in GitHub. Wie du den Bestand später wiederkehrend prüfst, beschreibt Berechtigungs-Reviews in GitHub-Organisationen. Und wie der Zugang am Ende sauber entzogen wird, behandelt Offboarding in GitHub. Warum ein Fork Zugriffe mitbringt, die im Original längst geregelt waren, steht in Forks und private Repos. Der Ablauf hier ergänzt diese Beiträge um den Zeitpunkt, an dem der Rechte-Berg entsteht.

Wo Unterstützung ansetzt

Das Leistungsspektrum ist gestaffelt und baut auf Delivery-Transparenz auf. Es läuft über drei Felder: Implementation (Delivery- und Nachweiskontrollen in die Pipeline einziehen), AI Governance (Nachvollziehbarkeit dort schaffen, wo KI-gestützte Schritte in Build und Deployment Freigaben und Verantwortung verwischen) und Maintenance (die Übergabefrage: wem ein System nach dem Go-Live gehört und woran man merkt, dass es niemandem gehört). Ein festes Angebot daraus entsteht erst, wenn klar ist, was du wirklich brauchst. Kontakt: mm@mhm-dl.de.

Über das Anmeldeformular für den Newsletter trägst du deine E-Mail-Adresse ein, kreuzt die Einwilligung an und bestätigst die Anmeldung danach per Mail. Mit der Anmeldung willigst du ein, dass der Newsletter unter anderem folgende Themen behandelt: Schulungen zu Docker, Kubernetes, CI/CD, Git-Workflows und DevSecOps-Werkzeugen sowie die Anforderungen aus NIS2, CRA und DORA und deren technische Umsetzung.