Bei der Nordlicht Reisen GmbH hat letzte Woche jemand versehentlich einen Zugangsschlüssel für das Zahlungssystem ins Repository des Buchungsportals committet und gepusht. Dazu kommt die Frage, wer überhaupt Tags setzen oder Zweige löschen darf, und was zu tun ist, wenn jemand eine Datei überschreibt. Sie sollen die Rechte festlegen und den Ablauf für beide Fälle beschreiben.
Die Prüfung nennt vier Fähigkeiten: Berechtigungen im Repository, Tags, bestimmte Daten mit Git wiederherstellen und bestimmte Daten aus der Quellcodeverwaltung entfernen.
Vorwissen: Warum ein Geheimnis nie in den Code gehört und wie die Pipeline ohne Geheimnis an Azure kommt, lehrt K3, Lektion 3.3.3 (Geheimnisse nie ausgeben) und 3.7.5 (Ausliefern ohne Geheimnis). Wie Versionen aus Tags entstehen, steht in K3, Lektion 3.7.4. Die Schutzregeln für Zweige kennen Sie aus Lektion 2.2; Rollen und Gruppen im Ganzen folgen in Modul D5.
Berechtigungen in Azure Repos
Microsofts Seite zu den Repository-Berechtigungen beschreibt: Sie setzen Rechte auf der Ebene All Repositories (gilt für jedes Git-Repository des Projekts) oder für ein einzelnes Repository; einzelne Repositories erben vom Eintrag der Projektebene. Zweige erben eine Teilmenge der Rechte des Repositories (Branch-Rechte stehen auf einer eigenen Seite). Den Weg beschreibt Microsoft so: Project settings, Repositories, dann entweder All Repositories oder das Repository, jeweils Security. Dafür brauchen Sie Manage permissions; Mitglieder der Gruppe Project Administrators haben es standardmäßig.
Die Rechte und die Standardgruppen
| Recht | Wofür | Standardmäßig |
|---|---|---|
| Read | klonen, abrufen, lesen; auch Pull Requests anlegen, kommentieren, abstimmen | Readers, Contributors, Build Administrators, Project Administrators |
| Contribute, Create branch, Create tag, Manage notes | beitragen, Zweige und Tags anlegen | Contributors und höher |
| Create repository, Delete repository, Rename repository | Repositories verwalten | Project Administrators |
| Edit policies, Manage permissions, Remove others' locks | Richtlinien, Rechte, fremde Sperren | Project Administrators |
| Bypass policies when completing pull requests, Bypass policies when pushing, Force push (Historie umschreiben, Zweige und Tags löschen) | umgehen und umschreiben | für keine Gruppe gesetzt |
Die letzte Zeile ist die wichtigste: Microsoft setzt die gefährlichen Rechte standardmäßig für niemanden. Das heißt, dass auch die Project Administrators sie sich erst geben müssten. Seit einer Aktualisierung von Azure DevOps erhalten Ersteller eines Zweigs außerdem nicht mehr automatisch Edit policies; Sie vergeben es ausdrücklich.
Allow, Deny, Not set
Microsoft erklärt drei Zustände:
- Not set gewährt und verweigert nichts; ein Recht aus einer anderen Gruppe oder von einer höheren Ebene kann weiter gelten.
- Allow gewährt das Recht, solange nicht ein spezifischeres Deny es übersteuert.
- Deny übersteuert in der Regel Allow, auch ererbte oder über andere Gruppen gegebene Rechte, und trifft alle Mitglieder der Gruppe.
Prüfen Sie Gruppenmitgliedschaften und Vererbung, bevor Sie Deny setzen. Die Vererbung eines Repositories schalten Sie unter Inheritance auf On oder Off. Microsofts Rat: Notieren Sie die Einstellung vorher und prüfen Sie hinterher mit einer betroffenen Person, ob der Zugriff stimmt; wer Vererbung abschaltet, verliert Rechte der Projektebene.
Umgehen von Richtlinien
Früher gab es ein einziges Recht „Exempt from policy enforcement“. Es erlaubte sowohl das Umgehen beim Abschluss eines Pull Requests als auch den direkten Push. Zwei Rechte ersetzen es: Bypass policies when completing pull requests (nur beim Abschluss) und Bypass policies when pushing (direkter Push auf Zweige mit erforderlichen Richtlinien). Microsoft nennt als Beispiele für das gelegentliche Umgehen das Zurücknehmen einer Änderung, die den Build bricht, und einen Hotfix mitten in der Nacht. Wer vorher das alte Recht hatte, erhielt beide neuen; prüfen Sie das und lassen Sie das Push-Recht Not set, wenn es nicht gebraucht wird.