OGOwnGate

· Команда OwnGate

Как связать GitLab с Active Directory и не раздавать пароли руками

Прямой LDAP-bind в gitlab.rb или единая точка входа? Разбираем, как перевести GitLab на OpenID Connect, включить централизованный MFA и автоматически отзывать доступ.

«Создай учётку новенькому»: будни системного администратора

Типичный вторник в ИТ-отделе. Лид разработки пишет в Telegram: *«К нам вышел новый бэкендер, накинь ему доступ в GitLab, вот список из восьми репозиториев»*.

Администратор идёт в консоль GitLab, жмёт *New User*, генерирует временный пароль, копирует его в буфер обмена, пишет письмо сотруднику, а затем вручную заходит в каждый проект и группу, выставляя роль *Developer*.

Через месяц проект заканчивается, разработчик переходит на другой стэк или увольняется. Права в репозиториях остаются жить своей жизнью.

Связка GitLab с единым шлюзом доступа

Почему так происходит? Потому что управление правами оторвано от каталога сотрудников. В этой статье разберём, как настроить единый вход (SSO) в GitLab через Active Directory по протоколу OpenID Connect, связать группы доступа и перестать администрировать пользователей вручную.

---

Вариант «в лоб»: почему прямой LDAP-bind в GitLab — это грабли

Самый частый способ, который выбирают команды — прописать настройки Active Directory прямо в конфигурационный файл /etc/gitlab/gitlab.rb:


gitlab_rails['ldap_enabled'] = true

gitlab_rails['ldap_servers'] = {

  'main' => {

    'label' => 'Active Directory',

    'host' => 'dc1.company.local',

    'port' => 636,

    'uid' => 'sAMAccountName',

    'bind_dn' => 'CN=gitlab_bind,OU=Service,DC=company,DC=local',

    'password' => 'SuperSecretPass'

  }

}

На первый взгляд всё работает: сотрудник вбивает доменный логин и пароль в форму GitLab. Но на практике вы получаете три проблемы:

1. Пароли передаются через приложение. GitLab сам принимает пароль пользователя и отправляет его в контроллер домена. Если включён детальный дебаг логов или произойдёт утечка памяти — корпоративные пароли могут оказаться в логах.

2. Сессии не отзываются. Пользователь ввёл пароль один раз, получил сессионную куку на 14 дней. Когда вы заблокируете его в AD, GitLab не узнает об этом до следующего полного синка.

3. Нет централизованного MFA. Либо вы заставляете каждого разработчика включать TOTP отдельно внутри профиля GitLab (и потом вручную сбрасываете его при утере телефона), либо живёте без второго фактора вообще.

---

Правильный путь: подключаем GitLab через OpenID Connect (OIDC)

Вместо прямого проброса паролей GitLab подключается к централизованному шлюзу доступа как стандартный OIDC-клиент:


[ Пользователь ] ──▶ [ GitLab ] ──(редирект)──▶ [ Шлюз доступа OwnGate ]

                                                        │

                                                 (проверка пароля + MFA)

                                                        ▼

                                              [ Active Directory ]

Шаг 1. Регистрация приложения в шлюзе доступа

В панели шлюза создаётся клиент gitlab:

  • Client ID: gitlab
  • Client Secret: надёжный сгенерированный секрет;
  • Valid Redirect URI: https://gitlab.company.ru/users/auth/openid_connect/callback

Шаг 2. Конфигурация GitLab (gitlab.rb)

В блоке OmniAuth прописываем параметры OIDC-провайдера:


gitlab_rails['omniauth_enabled'] = true

gitlab_rails['omniauth_allow_single_sign_on'] = ['openid_connect']

gitlab_rails['omniauth_block_auto_created_users'] = false

gitlab_rails['omniauth_auto_link_user'] = ['openid_connect']



gitlab_rails['omniauth_providers'] = [

  {

    name: "openid_connect",

    label: "OwnGate SSO",

    args: {

      name: "openid_connect",

      scope: ["openid", "profile", "email", "groups"],

      response_type: "code",

      issuer: "https://auth.company.ru",

      client_auth_method: "query",

      discovery: true,

      uid_field: "preferred_username",

      send_scope_to_token_endpoint: "false",

      client_options: {

        identifier: "gitlab",

        secret: "YOUR_CLIENT_SECRET",

        redirect_uri: "https://gitlab.company.ru/users/auth/openid_connect/callback"

      }

    }

  }

]

Применяем конфигурацию:


gitlab-ctl reconfigure

---

Маппинг групп: права определяются в Active Directory

Вместо ручного добавления пользователей в группы GitLab связывается с группами безопасности AD:

1. В AD создаются группы:

- SG_GitLab_Backend (бэкенд-разработчики);

- SG_GitLab_DevOps (инженеры инфраструктуры);

- SG_GitLab_Security (аудиторы).

2. В интерфейсе группы GitLab в разделе Group Information → SAML/SSO Group Links (или через OIDC Claims) группа связывается с соответствующей доменной группой:

- SG_GitLab_Backend $\rightarrow$ роль *Developer*;

- SG_GitLab_DevOps $\rightarrow$ роль *Maintainer*.

Теперь перевод сотрудника в другой проект или изменение прав решается добавлением его в группу Active Directory. При следующем входе GitLab автоматически обновит уровень доступа.

---

Что происходит при увольнении

Когда сотрудник блокируется в Active Directory:

1. Попытка повторного входа через шлюз немедленно блокируется;

2. Шлюз доступа отправляет запрос Backchannel Logout в GitLab;

3. Текущая активная веб-сессия пользователя принудительно инвалидируется;

4. В журнале аудита фиксируется дата, время и причина закрытия доступа.

ИТ-отделу больше не нужно помнить список из десятка проектов — доступ закрывается в единой точке контроля за одно действие.

← Все статьи