Basic Gitea Information
Grundstruktur
Die grundlegende Gitea-Umgebungsstruktur gruppiert Repos nach Organisation(en), von denen jede mehrere Repositories und mehrere Teams enthalten kann. Beachte jedoch, dass Benutzer wie bei GitHub Repos außerhalb der Organisation haben können.
Zudem kann ein Benutzer Mitglied von verschiedenen Organisationen sein. Innerhalb der Organisation kann der Benutzer unterschiedliche Berechtigungen für jedes Repository haben.
Ein Benutzer kann auch Teil verschiedener Teams mit unterschiedlichen Berechtigungen für verschiedene Repos sein.
Und schließlich können Repositories spezielle Schutzmechanismen haben.
Berechtigungen
Organisationen
Wenn eine Organisation erstellt wird, wird ein Team namens Owners erstellt und der Benutzer wird darin platziert. Dieses Team gewährt Admin-Zugriff auf die Organisation, diese Berechtigungen und der Name des Teams können nicht geändert werden.
Org-Admins (Eigentümer) können die Sichtbarkeit der Organisation auswählen:
Öffentlich
Eingeschränkt (nur angemeldete Benutzer)
Privat (nur Mitglieder)
Org-Admins können auch angeben, ob die Repo-Admins Zugriff hinzufügen und/oder entfernen können. Sie können auch die maximale Anzahl von Repos angeben.
Beim Erstellen eines neuen Teams werden mehrere wichtige Einstellungen ausgewählt:
Es wird angegeben, auf welche Repos der Organisation die Mitglieder des Teams zugreifen können: spezifische Repos (Repos, in denen das Team hinzugefügt wird) oder alle.
Es wird auch angegeben, ob Mitglieder neue Repos erstellen können (der Ersteller erhält Admin-Zugriff darauf).
Die Berechtigungen, die die Mitglieder des Repos haben werden:
Administrator-Zugriff
Spezifischer Zugriff:
Teams & Benutzer
In einem Repo können der Org-Admin und die Repo-Admins (wenn von der Organisation erlaubt) die Rollen verwalten, die Kollaboratoren (andere Benutzer) und Teams zugewiesen werden. Es gibt 3 mögliche Rollen:
Administrator
Schreiben
Lesen
Gitea-Authentifizierung
Web-Zugang
Verwendung von Benutzername + Passwort und möglicherweise (und empfohlen) einer 2FA.
SSH-Schlüssel
Du kannst dein Konto mit einem oder mehreren öffentlichen Schlüsseln konfigurieren, die es dem zugehörigen privaten Schlüssel ermöglichen, in deinem Namen Aktionen durchzuführen. http://localhost:3000/user/settings/keys
GPG-Schlüssel
Du kannst den Benutzer mit diesen Schlüsseln nicht imitieren, aber wenn du ihn nicht verwendest, könnte es möglich sein, dass du entdeckt wirst, weil du Commits ohne Signatur sendest.
Persönliche Zugriffstoken
Du kannst persönliche Zugriffstoken generieren, um einer Anwendung Zugriff auf dein Konto zu gewähren. Ein persönlicher Zugriffstoken gewährt vollen Zugriff auf dein Konto: http://localhost:3000/user/settings/applications
Oauth-Anwendungen
Genau wie persönliche Zugriffstoken haben Oauth-Anwendungen vollständigen Zugriff auf dein Konto und die Orte, auf die dein Konto Zugriff hat, da, wie in den Dokumentationen angegeben, Scopes noch nicht unterstützt werden:
Bereitstellungsschlüssel
Bereitstellungsschlüssel können Lese- oder Schreibzugriff auf das Repo haben, daher könnten sie interessant sein, um spezifische Repos zu kompromittieren.
Branch-Schutz
Branch-Schutzmechanismen sind darauf ausgelegt, den Benutzern keine vollständige Kontrolle über ein Repository zu geben. Das Ziel ist es, mehrere Schutzmethoden zu implementieren, bevor Code in einen Branch geschrieben werden kann.
Die Branch-Schutzmechanismen eines Repositories findest du unter https://localhost:3000/<orgname>/<reponame>/settings/branches
Es ist nicht möglich, einen Branch-Schutz auf Organisationsebene festzulegen. Daher müssen alle auf jedem Repo deklariert werden.
Verschiedene Schutzmechanismen können auf einen Branch angewendet werden (wie auf master):
Push deaktivieren: Niemand kann in diesen Branch pushen
Push aktivieren: Jeder mit Zugriff kann pushen, aber nicht erzwingen.
Whitelist-Eingeschränkter Push: Nur ausgewählte Benutzer/Teams können in diesen Branch pushen (aber kein erzwungener Push)
Merge-Whitelist aktivieren: Nur auf die Whitelist gesetzte Benutzer/Teams können PRs mergen.
Statusprüfungen aktivieren: Erfordert, dass Statusprüfungen vor dem Mergen bestanden werden.
Genehmigungen erforderlich: Gibt die Anzahl der erforderlichen Genehmigungen an, bevor ein PR gemergt werden kann.
Genehmigungen auf Whitelist beschränken: Gibt Benutzer/Teams an, die PRs genehmigen können.
Merge bei abgelehnten Reviews blockieren: Wenn Änderungen angefordert werden, kann es nicht gemergt werden (auch wenn die anderen Prüfungen bestanden werden)
Merge bei offiziellen Review-Anfragen blockieren: Wenn offizielle Review-Anfragen vorliegen, kann es nicht gemergt werden
Veraltete Genehmigungen aufheben: Bei neuen Commits werden alte Genehmigungen aufgehoben.
Signierte Commits erforderlich: Commits müssen signiert sein.
Merge blockieren, wenn Pull-Request veraltet ist
Geschützte/Ungeschützte Dateimuster: Gibt Muster von Dateien an, die vor Änderungen geschützt/ungeschützt sind
Wie du sehen kannst, könnten Repos selbst dann geschützt sein, wenn du einige Anmeldeinformationen eines Benutzers erhalten hast, was dich daran hindert, Code in master zu pushen, um beispielsweise die CI/CD-Pipeline zu kompromittieren.
Last updated
