Basic Gitea Information
Grundstruktur
Die grundlegende Gitea-Umgebungsstruktur besteht darin, Repos nach Organisation(en) zu gruppieren, von denen jede mehrere Repositories und mehrere Teams enthalten kann. Beachten Sie jedoch, dass Benutzer wie bei GitHub Repos außerhalb der Organisation haben können.
Darüber hinaus kann ein Benutzer Mitglied verschiedener Organisationen sein. Innerhalb der Organisation kann der Benutzer unterschiedliche Berechtigungen für jedes Repository haben.
Ein Benutzer kann auch Teil verschiedener Teams sein, die unterschiedliche Berechtigungen für verschiedene Repos haben.
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 für Teams 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: bestimmte Repos (Repos, in denen das Team hinzugefügt ist) 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 (falls von der Org erlaubt) die den Kollaborateuren (anderen Benutzern) und Teams zugewiesenen Rollen verwalten. Es gibt 3 mögliche Rollen:
Administrator
Schreiben
Lesen
Gitea-Authentifizierung
Webzugriff
Verwendung von Benutzername + Passwort und möglicherweise (und empfohlen) einer 2FA.
SSH-Schlüssel
Sie können Ihr Konto mit einem oder mehreren öffentlichen Schlüsseln konfigurieren, die dem zugehörigen privaten Schlüssel ermöglichen, Aktionen in Ihrem Namen auszuführen. http://localhost:3000/user/settings/keys
GPG-Schlüssel
Sie können den Benutzer nicht mit diesen Schlüsseln imitieren, aber wenn Sie sie nicht verwenden, könnte es möglich sein, dass Sie entdeckt werden, wenn Sie Commits ohne Signatur senden.
Persönliche Zugriffstoken
Sie können persönliche Zugriffstoken generieren, um einer Anwendung Zugriff auf Ihr Konto zu geben. Ein persönliches Zugriffstoken gewährt vollen Zugriff auf Ihr Konto: http://localhost:3000/user/settings/applications
Oauth-Anwendungen
Wie persönliche Zugriffstoken haben Oauth-Anwendungen vollen Zugriff auf Ihr Konto und die Orte, an denen Ihr Konto Zugriff hat, da, wie in den Dokumenten angegeben, Scopes noch nicht unterstützt werden:
Bereitstellungsschlüssel
Bereitstellungsschlüssel können Lese- oder Schreibzugriff auf das Repo haben, daher können sie interessant sein, um bestimmte Repos zu kompromittieren.
Branch-Schutz
Branch-Schutzmechanismen sind so konzipiert, dass sie den Benutzern keine vollständige Kontrolle über ein Repository geben. Das Ziel ist es, mehrere Schutzmethoden zu implementieren, bevor Code in einen bestimmten Branch geschrieben werden kann.
Die Branch-Schutzmechanismen eines Repositories finden Sie 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.
Es können verschiedene Schutzmaßnahmen auf einen Branch angewendet werden (z. B. auf master):
Push deaktivieren: Niemand kann in diesen Branch pushen
Push aktivieren: Jeder mit Zugriff kann pushen, aber nicht force push.
Whitelist für eingeschränkten Push: Nur ausgewählte Benutzer/Teams können in diesen Branch pushen (aber kein force push)
Whitelist für Merge aktivieren: Nur whitelisted Benutzer/Teams können PRs mergen.
Statusprüfungen aktivieren: Erfordern, dass Statusprüfungen vor dem Mergen bestanden werden.
Genehmigungen erforderlich: Anzahl der erforderlichen Genehmigungen vor dem Mergen angeben.
Genehmigungen auf Whitelist beschränken: Benutzer/Teams angeben, die PRs genehmigen können.
Mergen blockieren bei abgelehnten Reviews: Wenn Änderungen angefordert werden, kann nicht gemerged werden (auch wenn die anderen Prüfungen bestanden sind)
Mergen blockieren bei offiziellen Review-Anfragen: Wenn offizielle Review-Anfragen vorliegen, kann nicht gemerged werden
Veraltete Genehmigungen abweisen: Bei neuen Commits werden alte Genehmigungen abgelehnt.
Signierte Commits erforderlich: Commits müssen signiert sein.
Mergen blockieren, wenn Pull-Request veraltet ist
Geschützte/ungeschützte Dateimuster: Muster von Dateien angeben, die vor Änderungen geschützt/ungeschützt werden sollen
Wie Sie sehen können, selbst wenn es Ihnen gelingt, die Anmeldeinformationen eines Benutzers zu erhalten, können Repos geschützt sein, um zu verhindern, dass Sie Code in den Master pushen, um beispielsweise die CI/CD-Pipeline zu kompromittieren.
Last updated
