Basic Gitea Information
Podstawowa struktura
Podstawowa struktura środowiska Gitea polega na grupowaniu repozytoriów przez organizacje, z których każda może zawierać kilka repozytoriów i kilka zespołów. Należy jednak zauważyć, że podobnie jak w github, użytkownicy mogą mieć repozytoria poza organizacją.
Ponadto, użytkownik może być członkiem różnych organizacji. W ramach organizacji użytkownik może mieć różne uprawnienia do każdego repozytorium.
Użytkownik może również być częścią różnych zespołów z różnymi uprawnieniami do różnych repozytoriów.
I wreszcie, repozytoria mogą mieć specjalne mechanizmy ochrony.
Uprawnienia
Organizacje
Kiedy tworzona jest organizacja, tworzony jest zespół o nazwie Owners i użytkownik jest do niego dodawany. Ten zespół daje dostęp administracyjny do organizacji, te uprawnienia i nazwa zespołu nie mogą być zmienione.
Administratorzy organizacji (właściciele) mogą wybrać widoczność organizacji:
Publiczna
Ograniczona (tylko zalogowani użytkownicy)
Prywatna (tylko członkowie)
Administratorzy organizacji mogą również wskazać, czy administratorzy repozytoriów mogą dodawać i usuwać dostęp dla zespołów. Mogą również wskazać maksymalną liczbę repozytoriów.
Podczas tworzenia nowego zespołu wybierane są kilka ważnych ustawień:
Wskazane są repozytoria organizacji, do których członkowie zespołu będą mieli dostęp: konkretne repozytoria (repozytoria, do których zespół jest dodany) lub wszystkie.
Wskazane jest również, czy członkowie mogą tworzyć nowe repozytoria (twórca otrzyma do nich dostęp administracyjny)
Uprawnienia, które członkowie repozytorium będą posiadać:
Dostęp administratora
Specyficzny dostęp:
Zespoły i użytkownicy
W repozytorium, administrator organizacji i administratorzy repozytoriów (jeśli są dozwoleni przez organizację) mogą zarządzać rolami przyznanymi współpracownikom (innym użytkownikom) i zespołom. Istnieją 3 możliwe role:
Administrator
Pisanie
Czytanie
Uwierzytelnianie Gitea
Dostęp przez web
Używając nazwa użytkownika + hasło i potencjalnie (i zalecane) 2FA.
Klucze SSH
Możesz skonfigurować swoje konto z jednym lub kilkoma kluczami publicznymi, pozwalającymi powiązanemu kluczowi prywatnemu na wykonywanie działań w Twoim imieniu. http://localhost:3000/user/settings/keys
Klucze GPG
Nie możesz podszywać się pod użytkownika za pomocą tych kluczy, ale jeśli ich nie użyjesz, może się okazać, że zostaniesz odkryty za wysyłanie commitów bez podpisu.
Tokeny dostępu osobistego
Możesz wygenerować token dostępu osobistego, aby dać aplikacji dostęp do swojego konta. Token dostępu osobistego daje pełny dostęp do Twojego konta: http://localhost:3000/user/settings/applications
Aplikacje Oauth
Podobnie jak tokeny dostępu osobistego, aplikacje Oauth będą miały pełny dostęp do Twojego konta i miejsc, do których Twoje konto ma dostęp, ponieważ, jak wskazano w dokumentacji, zakresy nie są jeszcze obsługiwane:
Klucze wdrożeniowe
Klucze wdrożeniowe mogą mieć dostęp tylko do odczytu lub do zapisu do repozytorium, więc mogą być interesujące do skompromitowania konkretnych repozytoriów.
Ochrona gałęzi
Ochrona gałęzi jest zaprojektowana, aby nie dawać pełnej kontroli nad repozytorium użytkownikom. Celem jest wprowadzenie kilku metod ochrony przed możliwością zapisu kodu do niektórych gałęzi.
Ochrona gałęzi repozytorium można znaleźć na https://localhost:3000/<orgname>/<reponame>/settings/branches
Nie można ustawić ochrony gałęzi na poziomie organizacji. Wszystkie muszą być zadeklarowane w każdym repozytorium.
Różne ochrony mogą być zastosowane do gałęzi (np. do master):
Wyłącz Push: Nikt nie może pushować do tej gałęzi
Włącz Push: Każdy z dostępem może pushować, ale nie force push.
Biała lista ograniczonego Push: Tylko wybrani użytkownicy/zespoły mogą pushować do tej gałęzi (ale nie force push)
Włącz białą listę Merge: Tylko użytkownicy/zespoły z białej listy mogą łączyć PR-y.
Włącz sprawdzanie statusu: Wymagaj przejścia sprawdzeń statusu przed połączeniem.
Wymagaj zatwierdzeń: Wskaż liczbę zatwierdzeń wymaganych przed połączeniem PR.
Ogranicz zatwierdzenia do białej listy: Wskaż użytkowników/zespoły, które mogą zatwierdzać PR-y.
Blokuj merge przy odrzuconych recenzjach: Jeśli są żądane zmiany, nie można ich połączyć (nawet jeśli inne sprawdzenia przejdą)
Blokuj merge przy oficjalnych żądaniach recenzji: Jeśli są oficjalne żądania recenzji, nie można ich połączyć
Odrzuć przestarzałe zatwierdzenia: Kiedy są nowe commity, stare zatwierdzenia zostaną odrzucone.
Wymagaj podpisanych commitów: Commity muszą być podpisane.
Blokuj merge, jeśli pull request jest nieaktualny
Wzorce plików chronionych/niechronionych: Wskaż wzorce plików do ochrony/niechronienia przed zmianami
Jak widać, nawet jeśli udało Ci się uzyskać dane uwierzytelniające użytkownika, repozytoria mogą być chronione, uniemożliwiając Ci pushowanie kodu do mastera, na przykład w celu skompromitowania pipeline CI/CD.
Last updated
