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. Jednak należy zauważyć, że, podobnie jak w przypadku githuba, użytkownicy mogą mieć repozytoria poza organizacją.
Co więcej, 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łonkiem różnych zespołów z różnymi uprawnieniami do różnych repozytoriów.
Na koniec repozytoria mogą mieć specjalne mechanizmy ochrony.
Uprawnienia
Organizacje
Po utworzeniu organizacji tworzony jest zespół o nazwie Właściciele, do którego dodawany jest użytkownik. Ten zespół zapewni dostęp administratora do organizacji, te uprawnienia i nazwę 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/lub usuwać dostęp dla zespołów. Mogą również określić maksymalną liczbę repozytoriów.
Podczas tworzenia nowego zespołu wybierane są kilka istotnych 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 otrzyma dostęp administratora do niego)
Uprawnienia, jakie będą mieć członkowie repozytorium:
Dostęp Administratora
Dostęp Specyficzny:
Zespoły i Użytkownicy
W repozytorium administrator organizacji i administratorzy repozytorium (jeśli zezwala na to organizacja) mogą zarządzać rolami nadanymi współpracownikom (innym użytkownikom) i zespołom. Istnieją 3 możliwe role:
Administrator
Zapisz
Odczyt
Autentykacja Gitea
Dostęp przez sieć
Korzystając z nazwy użytkownika + hasła 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 podawać się za 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.
Tokeny dostępu osobistego
Możesz wygenerować token dostępu osobistego, aby udzielić aplikacji dostępu 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 ma dostęp twoje konto, ponieważ, zgodnie z dokumentacją, zakresy nie są jeszcze obsługiwane:
Klucze deploy
Klucze deploy mogą mieć dostęp tylko do odczytu lub zapisu do repozytorium, więc mogą być interesujące do skompromitowania konkretnych repozytoriów.
Ochrona gałęzi
Ochrona gałęzi ma na celu nie dawanie użytkownikom pełnej kontroli nad repozytorium. Celem jest ustawienie kilku metod ochrony przed możliwością pisania kodu w określonej gałęzi.
Ochrony gałęzi repozytorium można znaleźć pod adresem https://localhost:3000/<nazwa_organizacji>/<nazwa_repozytorium>/settings/branches
Nie można ustawić ochrony gałęzi na poziomie organizacji. Dlatego wszystkie zabezpieczenia muszą być zadeklarowane dla każdego repozytorium.
Do gałęzi można zastosować różne zabezpieczenia (np. dla master):
Wyłączanie Push: Nikt nie może przesłać do tej gałęzi
Włączanie Push: Każdy z dostępem może przesłać, ale nie force push.
Biała lista ograniczonego Push: Tylko wybrane użytkownicy/zespoły mogą przesyłać do tej gałęzi (ale bez force push)
Włącz białą listę scalania: Tylko użytkownicy/zespoły z białej listy mogą łączyć PR.
Włącz sprawdzanie stanu: Wymaga, aby sprawdzenia stanu zostały zakończone pomyślnie przed scaleniem.
Wymagaj zatwierdzeń: Wskazuje liczbę wymaganych zatwierdzeń przed scaleniem PR.
Ogranicz zatwierdzenia do białej listy: Wskazuje użytkowników/zespoły, które mogą zatwierdzać PR.
Zablokuj scalanie przy odrzuconych recenzjach: Jeśli są żądane zmiany, nie można ich scalić (nawet jeśli inne sprawdzenia przechodzą)
Zablokuj scalanie przy oficjalnych żądaniach recenzji: Jeśli są oficjalne żądania recenzji, nie można ich scalić
Odrzuć przeterminowane zatwierdzenia: Po dodaniu nowych commitów stare zatwierdzenia zostaną odrzucone.
Wymagaj podpisanych commitów: Commity muszą być podpisane.
Zablokuj scalanie, jeśli pull request jest przestarzały
Chronione/Niechronione wzorce plików: Wskazuje wzorce plików do ochrony/przeciwko zmianom
Jak widać, nawet jeśli udało ci się uzyskać pewne dane uwierzytelniające użytkownika, repozytoria mogą być chronione, uniemożliwiając przesyłanie kodu do mastera na przykład w celu skompromitowania procesu CI/CD.
Last updated
