Skip to main content

Gitlab Permissions Guide

В данном гайде описываются рекомендации как настроить роли и права разработчиков и других инженеров в случае когда в качестве платформы для git используется saas или selfhosted версия Gitlab

Как и все гайды Ensi данный гайд может быть удален или доработан под требования конкретного внедрения

Обзор ролей в Gitlab#

Остановимся на главных ролях:

  1. Reporter - доступ только на чтение;
  2. Developer - стандартная роль для разработчиков. Обычно есть право на создание новых репозиториев. Push и Merge в защищенные ветки часто недоступен для этой роли.
  3. Maintainer - кроме всех прав Developer еще всегда может создавать репозитории, иногда имеет право создавать подгруппы, может удалять и переименовывать репозитории. Может иметь больше прав на push/merge в защищенные ветки. Может настраивать CI/CD. Это группа для разработчиков наделенных опытом и ответственностью, а также devops инженеров
  4. Owner - полный доступ к группе, включая добавление новых участников и смена ролей.

Конкретные права ролей зависят от настроек групп и/или даже репозиториев в этих группах.

Полное описание ролей и прав можно найти на специальной странице документации Gitlab

Проецирование команд в Gitlab#

Вне зависимости от того планируется ли развитие Ensi-сервисов силами одной общей команды разработки или команд будет несколько рекомендуется создать одну общую группу-директорию под все сервисы платформы конкретного внедрения. Пример такой группы

  • если команда одна, то удобнее будет добавлять людей непосредственно в эту корневую группу;
  • если команд несколько - создаем подгруппу под каждую команду и добавляем людей в них. Подгруппу называем с префиксом Team, чтобы не путать с подгруппами для доменов. После этого для каждой команды определяем список доменов (тоже подгрупп), которыми она владеет, заходим в эти подгруппы и шарим их с нужной командой;
  • если у вас сначала была одна команда, а потом она выросла и разбилась на несколько - создаем подгруппы под них, а из корневой всех убираем;

Разработчики соседних команд должны иметь доступ хотя бы на чтение к чужим доменам. Для этого шарим домен с соседними командами, но выставляем ограничение на максимальную роль.

  • если вы практикуете innersource между командами, то это Developer;
  • если нет - скорее всего вам подойдет и Reporter дающий только доступ на чтение;

Определение роли пользователя в команде#

После того как появились команда/ы и домены/сервисы которыми эта команда владеет встает вопрос с какой ролью добавлять конкретного пользователя в команду.

Гайдлайны здесь следующие:

  • если человеку достаточно лишь доступа на чтение - добавляем с ролью Reporter;
  • присоединившимся к команде разработчикам - по-умолчанию Developer;
  • самым опытным и погруженным в проект разработчикам - Maintainer; Это люди ответственные за ревью младших разработчиков, сборку релизов и т д. В группе всегда должен быть хотя бы один разработчик с ролью Maintainer или выше;
  • У всех DevOps инженеров должна быть роль Maintainer;
  • в группе необязательно должен быть Owner, необходимые действия может совершать Owner вышестоящих групп Gitlab. Однако, если команда большая, отвечает за большое число сервисов, много людей приходит и уходит, то может быть удобно переложить эти функции на одного из Maintainer-ов, дав ему Owner права на конкретную группу.

Настройки групп связанные с ролями и правами#

Allowed to create projects (repositories) : Developers and Maintainers

Allowed to create subgroups: Maintainers

Настройки проектов-репозиториев связанные с ролями и правами#

Вне зависимости от выбранного flow работы с git рекомендуется делать production ветку защищенной со следующими настройками:

Repository → Protected Branched → Allowed to Merge : Developers and Maintainers

Repository → Protected Branched → Allowed to Push : No one. Может быть смягчено до Maintainers на период разработки MVP