Basic Gitea Information
Podstawowa struktura
Podstawowa struktura środowiska Gitea polega na grupowaniu repozytoriów według organizacji, z których każda może zawierać kilka repozytoriów i kilka zespołów. Należy jednak zauważyć, że podobnie jak w githubie, 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 być również 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
Gdy organizacja jest tworzona, tworzony jest zespół o nazwie Właściciele i użytkownik jest do niego dodawany. Ten zespół zapewni dostęp administracyjny do organizacji, te uprawnienia i nazwa zespołu nie mogą być modyfikowane.
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ć lub 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ń:
Wskazuje się 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.
Wskazuje się również, czy członkowie mogą tworzyć nowe repozytoria (twórca uzyska dostęp administracyjny do niego).
Uprawnienia, które członkowie repozytoriów będą mieć:
Dostęp administratora
Dostęp specyficzny:
Zespoły i użytkownicy
W repozytorium, administrator organizacji i administratorzy repozytoriów (jeśli dozwolone przez organizację) mogą zarządzać rolami nadawanymi współpracownikom (innym użytkownikom) i zespołom. Istnieją 3 możliwe role:
Administrator
Zapis
Odczyt
Uwierzytelnianie Gitea
Dostęp przez sieć
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ąc 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żywasz, może być możliwe, że zostaniesz odkryty za wysyłanie commitów bez podpisu.
Osobiste tokeny dostępu
Możesz wygenerować osobisty token dostępu, aby dać aplikacji dostęp do swojego konta. Osobisty token dostępu daje pełny dostęp do twojego konta: http://localhost:3000/user/settings/applications
Aplikacje Oauth
Podobnie jak osobiste tokeny dostępu, 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 zapisu do repozytorium, więc mogą być interesujące do kompromitacji konkretnych repozytoriów.
Ochrona gałęzi
Ochrona gałęzi ma na celu nieprzekazywanie pełnej kontroli nad repozytorium użytkownikom. Celem jest wprowadzenie kilku metod ochrony przed możliwością pisania kodu w niektórej gałęzi.
Ochrona gałęzi repozytorium może być znaleziona w https://localhost:3000/<orgname>/<reponame>/settings/branches
Nie jest możliwe ustawienie ochrony gałęzi na poziomie organizacji. Wszystkie muszą być zadeklarowane w każdym repozytorium.
Różne ochrony mogą być stosowane do gałęzi (jak do master):
Wyłącz Push: Nikt nie może przesyłać do tej gałęzi
Włącz Push: Każdy z dostępem może przesyłać, ale nie może wymusić przesyłania.
Biała lista ograniczonego Push: Tylko wybrani użytkownicy/zespoły mogą przesyłać do tej gałęzi (ale nie mogą wymusić przesyłania)
Włącz białą listę scalania: Tylko użytkownicy/zespoły z białej listy mogą scalać PR-y.
Włącz kontrole statusu: Wymagaj, aby kontrole statusu przeszły przed scaleniem.
Wymagaj zatwierdzeń: Wskaź liczbę zatwierdzeń wymaganych przed scaleniem PR-a.
Ogranicz zatwierdzenia do białej listy: Wskaź użytkowników/zespoły, które mogą zatwierdzać PR-y.
Zablokuj scalanie przy odrzuconych recenzjach: Jeśli zmiany są wymagane, nie może być scalone (nawet jeśli inne kontrole przejdą)
Zablokuj scalanie przy oficjalnych prośbach o recenzję: Jeśli są oficjalne prośby o recenzję, nie może być scalone
Odrzuć przestarzałe zatwierdzenia: Gdy pojawią się nowe commity, stare zatwierdzenia zostaną odrzucone.
Wymagaj podpisanych commitów: Commity muszą być podpisane.
Zablokuj scalanie, jeśli pull request jest przestarzały
Wzory plików chronionych/niechronionych: Wskaź wzory plików do ochrony/od ochrony przed zmianami
Jak widać, nawet jeśli udało ci się uzyskać jakieś dane uwierzytelniające użytkownika, repozytoria mogą być chronione, co uniemożliwia ci przesyłanie kodu do mastera, na przykład w celu kompromitacji pipeline CI/CD.
Last updated
