Basic Gitea Information
Основна структура
Основна структура середовища Gitea полягає в групуванні репозиторіїв за організаціями, кожна з них може містити кілька репозиторіїв та кілька команд. Проте, слід зауважити, що, так само, як на github, користувачі можуть мати репозиторії поза організацією.
Більше того, користувач може бути членом різних організацій. У межах організації користувач може мати різні дозволи для кожного репозиторію.
Користувач також може бути частиною різних команд з різними дозволами для різних репозиторіїв.
І, нарешті, репозиторії можуть мати спеціальні механізми захисту.
Дозволи
Організації
Коли створюється організація, створюється команда під назвою Owners, і користувача додають до неї. Ця команда надасть адміністративний доступ до організації, ці дозволи та назва команди не можуть бути змінені.
Адміністратори організації (власники) можуть вибрати видимість організації:
Публічний
Обмежений (тільки для авторизованих користувачів)
Приватний (тільки для членів)
Адміністратори організації також можуть вказати, чи адміністратори репозиторіїв можуть додавати або видаляти доступ для команд. Вони також можуть вказати максимальну кількість репозиторіїв.
При створенні нової команди вибираються кілька важливих налаштувань:
Вказується репозиторії організації, до яких члени команди матимуть доступ: конкретні репозиторії (репозиторії, де додана команда) або всі.
Також вказується, чи можуть члени створювати нові репозиторії (створювач отримає адміністративний доступ до нього)
Дозволи, які будуть у членів репозиторію:
Доступ адміністратора
Конкретний доступ:
Команди та Користувачі
У репозиторії адміністратор організації та адміністратори репозиторіїв (якщо дозволено організацією) можуть керувати ролями, наданими співробітникам (іншим користувачам) та командам. Існує 3 можливі ролі:
Адміністратор
Запис
Читання
Аутентифікація Gitea
Веб-доступ
Використовуючи ім'я користувача + пароль та, можливо (і рекомендується), 2FA.
SSH-ключі
Ви можете налаштувати свій обліковий запис з одним або кількома публічними ключами, що дозволяють пов'язаному приватному ключу виконувати дії від вашого імені. http://localhost:3000/user/settings/keys
GPG-ключі
Ви не можете видаавати себе за користувача за допомогою цих ключів, але якщо ви не використовуєте їх, можливо, що ви будете виявлені за відсутність підпису відправлених комітів.
Особисті токени доступу
Ви можете створити особистий токен доступу, щоб надати додатку доступ до вашого облікового запису. Особистий токен доступу надає повний доступ до вашого облікового запису: http://localhost:3000/user/settings/applications
Особисті токени доступу
Так само, як особисті токени доступу, додатки Oauth матимуть повний доступ до вашого облікового запису та місць, до яких має доступ ваш обліковий запис, оскільки, як вказано в документації, області поки що не підтримуються:
Ключі розгортання
Ключі розгортання можуть мати доступ тільки для читання або запису до репозиторію, тому вони можуть бути цікавими для компрометації конкретних репозиторіїв.
Захист гілок
Захист гілок призначений не надавати повного контролю над репозиторієм користувачам. Мета полягає в тому, щоб поставити кілька методів захисту перед можливістю писати код у певну гілку.
Захисти гілок репозиторію можна знайти за адресою https://localhost:3000/<orgname>/<reponame>/settings/branches
Неможливо встановити захист гілки на рівні організації. Тому всі вони повинні бути визначені для кожного репозиторію.
До гілки можуть бути застосовані різні захисти (наприклад, для master):
Вимкнути Push: Ніхто не може виконувати push в цю гілку
Увімкнути Push: Будь-хто з доступом може виконувати push, але не force push.
Білий список обмеженого Push: Тільки вибрані користувачі/команди можуть виконувати push в цю гілку (але без force push)
Увімкнути Білий список злиття: Тільки користувачі/команди з білим списком можуть злити PR.
Увімкнути перевірку статусу: Вимагати успішну перевірку статусу перед злиттям.
Вимагати схвалення: Вказати кількість схвалень, необхідних для злиття PR.
Обмежити схвалення для білого списку: Вказати користувачів/команди, які можуть схвалювати PR.
Блокувати злиття при відхиленні відгуків: Якщо запитані зміни, вони не можуть бути злиті (навіть якщо інші перевірки пройдуть)
Блокувати злиття при офіційних запитах на перегляд: Якщо є офіційні запити на перегляд, вони не можуть бути злиті
Відхиляти застарілі схвалення: При нових комітах старі схвалення будуть відхилені.
Вимагати підписані коміти: Коміти повинні бути підписані.
Блокувати злиття, якщо запит на злиття застарілий
Захищені/Незахищені шаблони файлів: Вказати шаблони файлів для захисту/зняття захисту від змін
Як бачите, навіть якщо вам вдалося отримати деякі облікові дані користувача, репозиторії можуть бути захищені, що уникне вам можливість відправляти код у master, наприклад, для компрометації конвеєра CI/CD.
Last updated
