Eine Einstellung, die für jedes Mitglied gilt, ohne dass sie jemand einzeln zugewiesen hat
In jeder GitHub-Organisation gibt es eine einzige Einstellung, die bestimmt, was ein Mitglied automatisch auf jedem Repository der Organisation darf, ganz ohne Team-Zuweisung und ohne Einzelrecht: die Basisberechtigung, in der GitHub-Oberfläche „Base permission“. Laut Dokumentation gilt sie für alle Mitglieder der Organisation beim Zugriff auf jedes Repository der Organisation, Ausnahme sind Outside Collaborators: „Base permissions do not apply to outside collaborators.“
Dass eine höhere Team- oder Repo-Zuweisung die Basisberechtigung übersteuert, ist hier nicht Thema (siehe Effektive vs. nominale Rechte in GitHub und GitHub Onboarding Berechtigungen), dieser Beitrag erklärt nur die Einstellungswerte selbst und wer sie setzen darf.
Die vier Werte: None, Read, Write, Admin
Nach dem offiziellen Schema der GitHub-REST-API (Feld default_repository_permission, Beschreibung „Default permission level members have for organization repositories“) kennt die Basisberechtigung vier Werte: none, read, write und admin, Standardwert ist read. Die Dokumentation zur Einstellung selbst nennt dieselbe Grundaussage aus Nutzersicht: „By default, members of an organization will have Read permissions to the organization’s public repositories.“ Gesetzt wird der Wert über ein Dropdown-Menü in den Organisationseinstellungen unter „Member privileges“, der Schritt dazu lautet laut Dokumentation: „Under ‚Base permissions‘, select the dropdown menu and click a permissions level.“
Ein Sonderfall betrifft den Wert none: Er schließt interne Repositories nicht vollständig aus. Die Dokumentation hält fest: „Internal repositories have a minimum visibility level of read, even if the base permission has been set to none.“ Wer auf none stellt, um den Zugriff auf null zu setzen, gibt damit trotzdem jedem Mitglied Leserecht auf interne Repositories.
Wer die Basisberechtigung ändern darf
Die Berechtigungsangabe der Dokumentation ist eindeutig: „Organization owners can set base permissions for an organization.“ Kein anderer Rollenträger kann den Wert ändern, auch nicht ein Admin einzelner Repositories. Die Einstellung liegt auf Organisationsebene und ist damit an die höchste Rolle der Organisation gebunden.
Der Fallstrick: eine Änderung wirkt auf den gesamten Bestand, nicht nur auf neue Mitglieder
Zwei Eigenschaften der Basisberechtigung machen aus einer einzelnen Einstellung ein Risiko, wenn sie zu großzügig gesetzt ist. Erstens gilt sie für jedes Mitglied automatisch, ohne dass irgendwer eine Zuweisung getroffen hat: Steht sie auf write, kann jedes Mitglied der Organisation auf jedem Repository pushen, auch auf Repositories, mit denen es nie etwas zu tun hatte. Zweitens wirkt jede Änderung nicht nur auf künftige, sondern auch auf bestehende Mitglieder, laut Dokumentation: „All changes to base permissions will affect both new and existing members.“ Wer die Basisberechtigung aus Bequemlichkeit hochsetzt, weil eine einzelne Person mehr braucht, gibt diesen Zugriff damit der gesamten Organisation, Bestand und Zukunft, in einem Schritt.
Enterprise-Besonderheit: benutzerdefinierte Rollen unter dem Default
Für Organisationen mit benutzerdefinierten Repository-Rollen gilt eine zusätzliche Regel, die die Dokumentation so beschreibt: „If you’ve created a custom repository role with an inherited role that is lower access than your organization’s base permissions, any members assigned to that role will default to the organization’s base permissions rather than the inherited role.“ Eine bewusst eng geschnittene eigene Rolle unterhalb der Basisberechtigung bleibt damit wirkungslos, die betroffenen Mitglieder landen trotzdem auf dem Niveau der Basisberechtigung. Für die vier Werte selbst liefert die Dokumentation keinen Hinweis auf eine andere Verfügbarkeit in Enterprise-Umgebungen, belegt ist ausschließlich dieses Zusammenspiel mit benutzerdefinierten Rollen.
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.
Kommentar verfassen