Настройки безопасности

Учётная запись администратора

Инстанс запускается с учётной записью администратора root, пароль которой создаётся при установке.

1. Войдите под root с первоначальным паролем.
2. Откройте меню пользователя и выберите «Редактировать профиль».
3. Перейдите в «Доступ» → «Пароль и аутентификация» и задайте новый пароль.
4. Сохраните новый пароль вне инстанса.

После смены пароля удалите первоначальный пароль оттуда, где его хранит поставка:

Регистрация и вход

Новые учётные записи

После установки пакета для ОС Linux, Omnibus Docker или Helm-чарта любой, у кого есть сетевой доступ к инстансу, заводит себе учётную запись. Чтобы закрыть регистрацию:

1. Перейдите в «Admin» → «Настройки» → «Основные».
2. Разверните раздел «Ограничения аккаунтов новых пользователей».
3. Снимите флажок «Разрешить новые учётные записи пользователей».
4. Нажмите «Сохранить изменения».

В модуле Deckhouse Kubernetes Platform регистрация закрыта после установки; оператор задаёт её из поля appConfig.signUpEnabled ресурса CodeInstance.

В остальных типах установки то же самое делается из консоли:

sudo gitlab-rails runner 'ApplicationSetting.current.update!(signup_enabled: false)'
sudo gitlab-rails runner 'puts ApplicationSetting.current.signup_enabled'

docker exec code gitlab-rails runner 'ApplicationSetting.current.update!(signup_enabled: false)'
docker exec code gitlab-rails runner 'puts ApplicationSetting.current.signup_enabled'

d8 k -n code exec deploy/code-toolbox -- gitlab-rails runner 'ApplicationSetting.current.update!(signup_enabled: false)'
d8 k -n code exec deploy/code-toolbox -- gitlab-rails runner 'puts ApplicationSetting.current.signup_enabled'

Вторая команда выводит false, пока регистрация закрыта.

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

• «Требовать одобрение администратора для новых учётных записей» — учётная запись ждёт администратора до первого входа;
• «Настройки подтверждения электронной почты» — в режиме «Жесткий режим» адрес подтверждается до первого входа;
• «Разрешённые домены для новых пользователей» и «Список запрещённых доменов» — почтовые домены, с которыми регистрация разрешена и запрещена;
• «Минимальная длина пароля (количество символов)» — действует для учётных записей, которые входят по паролю, по умолчанию 8 символов.

Ни одна из этих настроек не действует на учётную запись, созданную через внешнего провайдера.

Ограничения входа

1. Перейдите в «Admin» → «Настройки» → «Основные».
2. Разверните раздел «Ограничения входа».
3. Установите флажок «Требовать двухфакторную аутентификацию для администраторов».
4. Нажмите «Сохранить изменения».

В том же разделе находятся:

• «Включить режим администратора» — администратор проходит аутентификацию ещё раз перед открытием административной панели;
• «Уведомление по email о неизвестных входах» — пользователь получает письмо, когда вход выполнен с устройства или IP-адреса, которые раньше не использовались;
• «Требовать подтверждение email при блокировке учётной записи» — заблокированная учётная запись подтверждает почтовый ящик перед следующим входом.

Двухфакторная аутентификация для всех пользователей инстанса, включённые протоколы доступа к Git и аутентификация по паролю для Git через HTTPS задаются в том же разделе и описаны на странице «Пользователи и доступ». Аутентификация по паролю для веб-интерфейса описана на странице «Аутентификация».

Внешний провайдер аутентификации

При использовании LDAP, SAML или OIDC учётные записи и членство в группах хранятся в каталоге, и закрытая там учётная запись теряет доступ к Deckhouse Code без действий внутри инстанса. Провайдеры, синхронизация и связывание учётных записей описаны на странице «Аутентификация».

Видимость и контроль доступа

Настройки находятся в разделе «Admin» → «Настройки» → «Основные» → «Видимость и контроль доступа»:

• «Уровень видимости проектов по умолчанию», «Уровень видимости сниппетов по умолчанию» и «Уровень видимости групп по умолчанию» — задайте значение «Приватный», чтобы новый проект, сниппет или группа были закрыты, пока их не откроют;
• «Ограниченные уровни видимости» — уровни, которые не может выбрать неадминистратор. Если отметить здесь публичный и внутренний уровни, обычный пользователь создаёт только приватные проекты;
• срок хранения удалённой группы или проекта — время, в течение которого удаление ещё обратимо;
• «Минимальная роль по умолчанию, необходимая для создания проектов» и «Включенные протоколы доступа к Git» — описаны на странице «Пользователи и доступ»;
• «RSA SSH keys», «DSA SSH keys», «ECDSA SSH keys» и остальные списки ключей — каждый из них запрещает свой алгоритм или задаёт минимальную длину ключа, которую инстанс принимает от пользователя.

Запретите ключи DSA, задайте минимальную длину ключа RSA 3072 бита, ключа ECDSA — 256 бит. Списки ECDSA_SK и ED25519_SK оставьте включёнными, пока используются аппаратные ключи FIDO2 или U2F.

Ограничения учётных записей

Настройки находятся в разделе «Admin» → «Настройки» → «Основные» → «Аккаунт и ограничения»:

• «Лимит проектов по умолчанию» — максимальное количество проектов, которые создаёт один пользователь;
• «Максимальная продолжительность сессии» — длительность сессии в минутах, по умолчанию 7 дней; изменение применяется после перезапуска инстанса;
• «Запомнить меня» → «Разрешить пользователям использовать функцию „Запомнить меня“» — со снятым флажком сессия заканчивается по истечении срока независимо от действий пользователя;
• «Требовать дату истечения» — новый персональный, групповой или проектный токен получает дату истечения;
• «Пользовательские OAuth-приложения» — со снятым флажком пользователь не регистрирует в инстансе собственный клиент OAuth;
• группа «Ограничения пользователя» — создание групп и проектов, описано на странице «Пользователи и доступ».

Перезапустите инстанс после изменения длительности сессии:

sudo gitlab-ctl restart

docker restart code

d8 k -n code rollout restart deploy/<WEBSERVICE_DEPLOYMENT>

d8 k -n d8-code rollout restart deploy -l 'app.kubernetes.io/component in (webservice, sidekiq)'

Импорт и экспорт

Настройки находятся в разделе «Admin» → «Настройки» → «Основные» → «Настройки импорта и экспорта»:

• «Источники импорта» — системы, из которых импортируется проект; по умолчанию выключены все источники, а источник «Repository by URL» принимает любой репозиторий Git по адресу;
• «Экспорт проекта» — со снятым флажком пользователь не собирает архив .tar.gz с данными проекта для переноса на другой инстанс;
• «Разрешить перенос групп и проектов GitLab путем прямого переноса» — выключено по умолчанию;
• «Экспорты администраторами без аудита» — пока флажок установлен, экспорт, выполненный администратором, не попадает в журнал аудита.

Настройки репозиториев

Ветка по умолчанию

1. Перейдите в «Admin» → «Настройки» → «Репозиторий».
2. Разверните раздел «Ветка по умолчанию».
3. В поле «Имя начальной ветки по умолчанию» укажите имя ветки, с которой начинается каждый новый репозиторий.
4. В группе «Защита начальной ветки по умолчанию» выберите защиту, с которой создаётся ветка по умолчанию, и задайте в полях «Разрешен push» и «Разрешен merge» роль, от которой ветка принимает изменения.
5. Снимите флажки «Разрешен force push» и «Разрешить разработчикам отправлять начальный коммит».
6. Нажмите «Сохранить изменения».

Настройки действуют на репозитории, созданные после изменения; в существующем репозитории правила веток остаются прежними.

Правила отправки изменений

Раздел «Push-правила» на той же странице задаёт правила, с которыми создаётся каждый проект инстанса: регулярные выражения для сообщения коммита, адреса электронной почты автора, имени файла и имени ветки, проверки коммитера и запрет на коммит секретов, например файлов pem или id_rsa. Правило со снятым разрешением на переопределение нельзя изменить в группе или проекте. Сами правила описаны на странице «Правила отправки изменений», уровень инстанса — на странице «Пользователи и доступ».

Настройки CI/CD

Токены аутентификации раннеров

Раздел «Admin» → «Настройки» → «CI/CD» → «Непрерывная интеграция и деплой» задаёт срок жизни токенов аутентификации раннеров уровня инстанса, группы и проекта; пока значение не задано, срок не ограничен. Раннер в сети сам ротирует токен по мере приближения срока истечения; раннер, который в этот момент был офлайн, регистрируется заново.

Раннеры

Раздел «Admin» → «Настройки» → «CI/CD» → «Раннеры» содержит:

• «Получить данные о версиях релизов раннеров с GitLab.com» — пока флажок установлен, инстанс запрашивает данные о версиях раннеров с GitLab.com; снимите его в установке без доступа в интернет;
• «Разрешить токен регистрации раннера» — со снятым флажком раннер регистрируется собственным токеном аутентификации вместо общего токена регистрации инстанса, группы или проекта.

Права токена заданий

Раздел «Admin» → «Настройки» → «CI/CD» → «Права доступа токена заданий в CI/CD» содержит настройку «Включить и применять белый список токенов заданий для всех проектов». Пока она включена, задание обращается к другому проекту только тогда, когда тот перечислил проект задания в своём списке, а вариант с доступом от всех групп и проектов скрыт.

Защита от спама и ботов

Раздел «Admin» → «Настройки» → «Отчетность» → «Защита от спама и ботов» содержит reCAPTCHA и ограничение количества учётных записей на один IP-адрес. Раздел применяется для инстанса, доступного из интернета.

Статистика использования

В разделе «Admin» → «Настройки» → «Метрики и профилирование» подраздел «Статистика использования» содержит проверку обновлений и Service Ping, а подраздел «Отслеживание событий» — отправку событий. Отслеживание событий выключено, его флажок доступен только для чтения; выключенную проверку обновлений нельзя включить обратно из интерфейса.

Сетевые ограничения

Раздел «Admin» → «Настройки» → «Сеть» содержит ограничения частоты запросов: «Ограничения скорости пользователей и IP-адресов» для инстанса в целом, «Ограничения на частоту запросов Git HTTP», «Ограничения на частоту запросов Git LFS», «Ограничения скорости поиска», «Ограничения скорости создания пайплайна» и «Ограничения скорости импорта и экспорта» для своего типа запросов, каждое из которых переопределяет общее ограничение. Настройка «Исходящие запросы» ограничивает адреса, к которым обращаются хуки и интеграции инстанса.

Защита на уровне платформы

В модуле Deckhouse Kubernetes Platform трафик между компонентами, доступ к пространству имён d8-code, сетевые политики и экспорт событий аудита настраиваются в кластере. Они описаны на странице «Настройки безопасности» в документации модуля.