Ролевая модель в GitLab

GitLab в составе KeyStack выполняет функции LCM (Lifecycle Management) — хранения кода автоматизации и управления процессами развёртывания, обновления и эксплуатации регионов. Ролевая модель обеспечивает контролируемый доступ к изменению критической инфраструктуры.

Политика безопасности

При включении ролевой модели автоматически активируется строгая политика безопасности: учётная запись root блокируется для предотвращения неконтролируемых изменений, создаётся технический пользователь ks-admin для выполнения автоматизированных операций. Пароль и персональный токен доступа (PAT) для ks-admin сохраняются в Vault по пути secret_v2 / deployments/ <LCM FQDN> / secrets / accounts — это обеспечивает централизованное управление техническими учётными записями.

Прямые коммиты в ветку master запрещены для исключения неконтролируемых изменений критической инфраструктуры. Все изменения выполняются через процедуру Merge Request с требованием одобрения двух участников группы KS-Admin и перезапуска пайплайна.

Аутентификация

Форма входа в GitLab по адресу https://ks-lcm.cloud.itkey.com/users/sign_in содержит две вкладки: LDAP для корпоративных учётных записей и Standard для локальных пользователей. Использование вкладки LDAP обеспечивает автоматическое получение ролей на основе членства в группах LDAP.

Форма входа в GitLab с вкладками LDAP и Standard

Форма входа в GitLab с вкладками LDAP и Standard

Работа с Merge Request

Страница Merge requests предоставляет интерфейс управления изменениями кода. Выпадающий список Select project to create merge request содержит репозитории проекта: project_k / services / upgrade, project_k / deployments / <имя региона>, project_k / services / support-bundle, project_k / services / backup и другие компоненты автоматизации.

Страница Merge requests с выбором репозитория проекта

Страница Merge requests с выбором репозитория проекта

Каждый MR проходит процедуру двойной проверки: код-ревью от двух администраторов исключает человеческие ошибки, а автоматическая валидация через пайплайн проверяет синтаксис и совместимость изменений. Это двухуровневая защита от ошибок в критической инфраструктуре.

Настройка правил Merge Request

Для обеспечения качества кода и предотвращения ошибок в критической инфраструктуре автоматически настроены правила слияния.

При необходимости настройки она выполняется от имени главного администратора GitLab, который генерируется в HashiCorp Vault. Не используйте для этих настроек учётные записи администраторов из LDAP — они не имеют необходимых прав для изменения настроек проектов GitLab.

Для того чтобы настроить правила слияния для репозитория, выполните следующие действия:

  1. Перейдите в нужный репозиторий или создайте форк существующего репозитория.

  2. Откройте раздел Settings > Merge requests.

  3. В разделе Merge checks установите следующие параметры:

    • Pipelines must succeed — запрос на слияние можно объединить только если последний пайплайн успешно завершён или всё ещё выполняется. При включении опции Skipped pipelines are considered successful пропущенные пайплайны также считаются успешными.

    • All threads must be resolved — все обсуждения в запросе на слияние должны быть разрешены перед объединением.

Настройки проверок слияния в GitLab

Настройки проверок слияния в GitLab

Эти настройки обеспечивают двухуровневую защиту от ошибок: автоматическая валидация через пайплайн проверяет синтаксис и совместимость изменений, а требование разрешения всех обсуждений гарантирует, что все замечания учтены.

Процесс создания и утверждения Merge Request

При внесении изменений в репозиторий следует придерживаться следующего процесса:

  1. Создайте новую ветку для ваших изменений.

  2. Внесите необходимые изменения в код. Подробнее в разделе Редактор кода.

  3. Создайте Merge Request для слияния изменений в основную ветку.

  4. Получите одобрение от двух пользователей с правами администратора.

  5. Дождитесь успешного прохождения пайплайна автоматической проверки.

  6. Сделайте Merge для слияния изменений в основную ветку.

Примечание

Один из одобряющих может быть инициатором запроса, но для слияния всегда требуется минимум два одобрения от администраторов. Это исключает возможность самостоятельного слияния (self-merge) и обеспечивает процедуру двойной проверки.

Настройка шаблонов сообщений

В разделе Merge suggestions можно настроить шаблон сообщения, который будет использоваться при применении предложений слияния. Доступные переменные для шаблона:

  • %{suggestions_count} — количество предложений.

  • %{files_count} — количество файлов.

  • %{co_authored_by} — информация о соавторах.

В разделе Merge commit message template настраивается шаблон сообщения для коммита слияния. Доступные переменные:

  • %{source_branch} — исходная ветка.

  • %{target_branch} — целевая ветка.

  • %{title} — заголовок запроса на слияние.

  • %{issues} — связанные задачи.

  • %{reference} — ссылка на запрос слияния.

Раздел Squash commit message template позволяет настроить шаблон для объединённых коммитов при использовании функции squash.

Редактор пайплайнов

Pipeline editor предоставляет инструменты создания и отладки процессов автоматизации. Интерфейс содержит четыре вкладки: Edit для редактирования кода, Visualize для отображения структуры процесса, Validate для проверки синтаксиса, Full configuration для просмотра итоговой конфигурации.

Индикатор «Pipeline syntax is correct» сигнализирует о корректности синтаксиса YAML-конфигурации пайплайна.

Pipeline editor с проверкой синтаксиса и вкладками управления

Pipeline editor с проверкой синтаксиса и вкладками управления

Редактор кода

Для того чтобы внести изменения в рамках одного файла, выполните следующие действия:

  1. Войдите в GitLab и перейдите в нужный вам репозиторий, например, в репозиторий региона project_k / deployments / <имя региона>.

  2. Выберите файл для редактирования, например globals.d/REGION.yml.

  3. Нажмите Edit > Edit single file.

    Изменение одного файла

    Изменение одного файла

  4. В открывшемся окне измените или добавьте строки.

  5. Нажмите Commit changes.

  6. В открывшемся окне заполните поле Commit message и нажмите Commit changes.

    Отправка изменения одного файла

    Отправка изменения одного файла

GitLab Web IDE

GitLab Web IDE — это встроенная в интерфейс GitLab среда разработки, которая позволяет просматривать, редактировать и создавать файлы напрямую из браузера, без необходимости клонировать репозиторий на локальную машину и использовать локальные редакторы кода.

Для того чтобы внести изменения в файл в репозитории с помощью Web IDE, выполните следующие действия:

  1. Войдите в GitLab и перейдите в нужный вам репозиторий, например, в репозиторий региона project_k / deployments / <имя региона>.

  2. Выберите файл для редактирования, например globals.d/REGION.yml.

  3. Нажмите Edit > Open in Web IDE.

    Open in Web IDE

    Open in Web IDE

  4. В открывшемся окне измените или добавьте строки.

  5. Перейдите во вкладку слева Source control и заполните поле Commit message.

  6. Нажмите Commit and push to master.

    Редактирование файла с помощью Web IDE

    Редактирование файла с помощью Web IDE

  7. Подтвердите изменения в открывшемся окне.

Разграничение функций по ролям

  • Admin обладает правами создания, изменения и удаления пайплайнов, управления процессами.

  • Security_auditor и reader ограничены просмотром кода, конфигураций и журналов выполнения.