Die Nordlicht Reisen GmbH wächst: Drei Teams arbeiten am Buchungsportal (Webseite, Zahlung, Betrieb), dazu kommen zwei Externe einer Agentur, die nur an der Webseite arbeiten sollen. Bisher ist jede Person „Administrator“, weil das am wenigsten Rückfragen erzeugt. Letzte Woche hat jemand versehentlich eine Dienstverbindung zur Produktion gelöscht. Sie sollen die Rechte in GitHub und in Azure DevOps so ordnen, dass jede Person genau das darf, was ihre Aufgabe verlangt, und dass sich das mit wenigen Gruppen verwalten lässt.

Die Prüfung nennt das: Berechtigungen und Rollen in GitHub und Berechtigungen und Sicherheitsgruppen in Azure DevOps planen, Zugriffsebenen vergeben und Projekte und Teams strukturieren. Im Mittelpunkt steht eine Entscheidung nach dem Prinzip des geringsten Rechts: Wer bekommt welche Rolle an welcher Stelle, und warum nicht mehr.

Vorwissen: Das Prinzip der geringsten Rechte für Azure-Rollen behandelt K3, Lektion 3.3.5; Rollenzuweisungen in Azure (Azure RBAC) kennen Sie aus AZ-104, Modul 2. Hier geht es um die Rechte in den beiden Entwicklungsplattformen, nicht um Rechte auf Azure-Ressourcen. Die Rechte einer Identität in Pipelines stehen in Lektion 5.1, Schutzregeln für Zweige in Lektion 2.2 und Berechtigungen im Repository in Lektion 2.4.

GitHub: Rollen in Organisation und Repository

GitHub trennt zwei Ebenen, und die Verwechslung beider ist die häufigste Fehlerquelle: Rollen in der Organisation (was jemand an der Organisation verwalten darf) und Rollen an einem Repository (was jemand am Code und seinen Einstellungen darf).

Rollen in der Organisation

Laut GitHub gibt es diese vordefinierten Rollen:

Rolle Was sie laut GitHub kann
Owner vollständiger Verwaltungszugriff auf die Organisation; GitHub rät, die Rolle zu begrenzen, aber nicht auf weniger als zwei Personen
Member die Standardrolle ohne Verwaltungsrechte; Mitglieder können standardmäßig Repositories und Projekte anlegen
Moderator ein Mitglied, das zusätzlich Fremde sperren, Interaktionen begrenzen und Kommentare ausblenden kann
Billing manager verwaltet Zahlungseinstellungen, ohne weitergehenden Zugriff
Security manager sieht Sicherheitswarnungen, verwaltet Sicherheitsfunktionen und liest alle Repositories der Organisation
GitHub App manager verwaltet die Registrierungen von GitHub Apps der Organisation, installiert oder entfernt aber keine Apps
Outside collaborator Zugriff auf ein oder mehrere Repositories, ohne Mitglied der Organisation zu sein (Berater, Zeitkräfte)

Eigene Organisationsrollen (zum Beispiel mit dem einzelnen Recht „View organization audit log“) gibt es laut GitHub nur mit GitHub Enterprise Cloud. Für die Nordlicht Reisen heißt das: Die Agentur-Personen sind Outside collaborators, nicht Mitglieder; so sehen sie nur, was ihnen ausdrücklich freigegeben ist.

Rollen am Repository

Die Rolle bestimmt den Zugriff auf ein einzelnes Repository. GitHub beschreibt fünf vordefinierte Rollen von wenig nach viel:

Rolle Empfohlen laut GitHub für
Read alle, die nichts am Code ändern, aber ansehen oder diskutieren wollen
Triage Mitwirkende, die Issues, Diskussionen und Pull Requests verwalten, ohne Schreibrecht
Write Mitwirkende, die aktiv in das Projekt pushen
Maintain Projektverantwortliche, die das Repository verwalten, ohne Zugriff auf sensible oder zerstörerische Aktionen
Admin wer vollen Zugriff braucht, einschließlich sensibler und zerstörerischer Aktionen (zum Beispiel Sicherheitseinstellungen verwalten oder das Repository löschen)

Eigene Repository-Rollen setzen ebenfalls GitHub Enterprise Cloud voraus. Zusätzlich legen Organisationsinhaber Basisberechtigungen fest, die für alle Mitglieder an jedem Repository der Organisation gelten; Inhaber haben auf jedem Repository der Organisation Admin-Zugriff. Wählen Sie die Basisberechtigung deshalb so niedrig, wie Ihre Teams es vertragen, und heben Sie die Rechte je Team an.

Teams

Ein Team spiegelt die Struktur Ihrer Firma, verwaltet Zugriff auf Repositories und verschickt Benachrichtigungen. Nach GitHub gilt:

  • Nur Mitglieder der Organisation können in Teams sein; Outside collaborators nicht. Sie bekommen ihre Rechte direkt am Repository.
  • Besitzer und Team-Maintainer können einem Team Admin-, Lese- oder Schreibzugriff auf Repositories der Organisation geben.
  • Teams lassen sich verschachteln: Ein Elternteam kann mehrere Kindteams haben, ein Kind hat genau ein Elternteam, und Kindteams erben die Repository-Rechte des Elternteams. GitHub rät, vor dem Verschachteln den bestehenden Zugriff zu prüfen, dem Elternteam nur Rechte zu geben, die für alle darunter sicher sind, und sensiblere Rechte tiefer zu vergeben.
  • Teams können in der Datei CODEOWNERS Eigentümer von Codebereichen sein (Lektion 2.2). Sichtbare Teams sehen und erwähnen alle Mitglieder der Organisation, geheime Teams nur ihre Mitglieder und die Besitzer.