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

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

Рекомендации безопасности на уровне инфраструктуры (целевого кластера DKP)

Эта секция фокусируется на практиках обеспечения безопасной целевой инфраструктуры для развертывания Deckhouse Code, а также описывает уже принятые в продукте меры. Требует наличия прав доступа в целевой кластер Deckhouse Kubernetes Platform для администрирования d8-code неймспейса и codeinstances custom-ресурса

Настройки коммуникации между компонентами (TLS)

Реализовано по умолчанию

Важность: Критическая

Все соединения между компонентами продукта внутри неймспейса осуществляются с помощью TLS

Настройки работы со входящим трафиком

Реализовано по умолчанию

Важность: Критическая

Аннотация nginx.ingress.kubernetes.io/backend-protocol: https, proxy-ssl-verify: 'on' и использование собственного TLS-секрета (proxy-ssl-secret) в конфигурации Ingress ресурсов обеспечивают шифрование и проверку подлинности соединения между nginx-ingress-controller и backend-сервисами (непосредственно компонентами Deckhouse Code). Это исключает возможность перехвата или подмены данных внутри кластера, повышая общую защищённость внутреннего трафика

Настройки ротации секретов для доступа к продукту

Реализовано по умолчанию

Важность: Критическая

Оператор использует сервисный аккаунт deckhouse-sa для тонкой донастройки и получения технической информации о Deckhouse Code по API. При этом для авторизации используются токены, значения которых хранятся в секретах d8-code неймспейса. Оператор автоматически ротирует используемые им токены по расписанию для повышения уровня безопасности контура продукта.

Оставаться на последней версии продукта

Реализовано по умолчанию

Важность: Умеренная

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

Доступ к неймспейсу d8-code

Важность: Критическая

В неймспейсе d8-code помимо подов приложения хранится конфигурация, в которой есть чувствительная информация, например ключи шифрования, TLS сертификаты и ключи, токены доступа к Deckhouse Code API и так далее. Доступ к d8-code должен быть только у ограниченного и верифицированного круга лиц или сервисных аккаунтов.

Такой доступ требуется для обслуживания Deckhouse Code, в том числе для ручного запуска резервного копирования, проверки состояния запущенного приложения, включения некоторых функций через rails console.

Для доступа к неймспейсу d8-code следует использовать примитивы Role / RoleBinding (не ClusterRole, если это не требуется).

Например, манифест ниже наделяет пользователя с email code@deckhouse.ru следующими правами доступа PrivilegedUser, подробнее о ролевой модели Deckhouse Kubernetes Platform можно прочесть по ссылке

Данных прав достаточно для входа в контейнеры, чтения секретов и удаления подов модуля Deckhouse Code, который находится в неймспейсе d8-code

apiVersion: deckhouse.io/v1
kind: ClusterAuthorizationRule
metadata:
  name: code-test
spec:
  accessLevel: PrivilegedUser
  allowScale: false
  namespaceSelector:
    labelSelector:
      matchExpressions: []
      matchLabels:
        module: code
  portForwarding: false
  subjects:
    - kind: User
      name: code@deckhouse.ru

Сменить пароль от учетной записи администратора

Важность: Критическая

Сразу после развёртывания продукта необходимо получить пароль администратора из секрета initial-root-password, изменить его и сохранить в безопасном месте, тем самым инвалидировав контент секрета. Сам пароль в секрете предназначен для использования администратором только для первичной настройки системы пользователем.

Для получения пароля администратора следует использовать команду:

kubectl -n d8-code get secret initial-root-password -o jsonpath='{.data.password}' | base64 -d

Для изменения пароля необходимо войти в интерфейс приложения, нажать на аватар пользователя и выбрать раздел “Настройки”. В настройках следует выбрать меню “Пароль” и сменить пароль.

Настроить в неймспейсе d8-code сетевые политики доступа

Важность: Умеренная Для минимизации векторов атаки и сокращения поверхности доступа рекомендуется сконфигурировать и использовать kubernetes networkPolicy в соответствии с потребностями организации. Пример как настраивать networkPolicy описан по ссылке.

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

Экспорт событий аудита

Важность: Умеренная

Рекомендуется используя потоковую передачу событий аудита безопасности в stdout компонентами Deckhouse Code в CEF формате, настроить сборщик событий в SIEM-систему компании.

Что собирать:

в деплойментах webservice-default, webservice-internal-api и sidekiq-default есть sidecar контейнер audit, который стримит события аудита в cef формате stdout.

Пример: kubectl -n d8-code logs deployments/webservice-default -c audit

Данные логи рекомендуется собирать и доставлять в вашу SIEM систему логшипером, который используется в вашей установке Deckhouse Kubernetes Platform.

Рекомендации по безопасной настройке приложения при развертывании

Здесь — настройки самого продукта Deckhouse Code, управление пользователями, аутентификация, аудит и защита CI/CD. Большинство настроек доступны через UI, в административной панели, в противном случае явно указано обратное.

LDAP / SSO интеграция

Важность: Критическая

Рекомендуется использовать LDAP / SAML / OIDC для централизованной аутентификации, отключить локальные аккаунты там, где возможно, и синхронизировать группы (Group Sync). Позволяет снизить поверхность атаки и повысить удобство наделения и отзыва прав доступа пользователей.

Настраивается с помощью соответствующей секции в kubernetes codeinstances CR. Подробнее тут

Настройки внутри приложения Deckhouse Code

Настройки видимости проектов и групп и контроль их доступа

Частично реализовано по умолчанию

Важность: Критическая

Как найти: Необходимо перейти в панель администратора, нажав кнопку Admin внизу меню справа. В разделе Настройки следует перейти в раздел Основные и развернуть меню “Видимость и контроль доступа”. В меню требуется проверить настройки и изменить их как указано ниже:

Требуется установить видимость содержимого проекта и настроить протоколы доступа Git.

  • Минимальная роль по умолчанию для создания проектов - Реализовано по умолчанию - рекомендуется установить минимальную роль по умолчанию для создания проектов не ниже Разработчики
  • Защита от удаления проектов - Реализовано по умолчанию - следует настроить период, в течение которого удаленный проект или группу можно восстановить, рекомендованный период 7 дней
  • Уровень видимости проектов по умолчанию - Реализовано по умолчанию - рекомендуется установить уровень видимости проекта по умолчанию как Приватный
  • Уровень видимости сниппетов по умолчанию - Реализовано по умолчанию - рекомендуется установить уровень видимости сниппетов по умолчанию как Приватный
  • Уровень видимости групп по умолчанию - Реализовано по умолчанию - рекомендуется установить уровень видимости групп по умолчанию как Приватный
  • Ограничения уровня видимости - рекомендуется запретить неадминистраторам использовать выбранные уровни видимости. Следует настроить минимально необходимые уровни видимости для новых проектов. Например, целесообразно установить флажок “Публичный” и “Внутренний”, чтобы разрешить обычным пользователям создавать проекты только с уровнем видимости “Приватный”
  • Включенные протоколы доступа Git - рекомендуется разрешить только используемые протоколы (SSH или HTTP(S)); если один из них не нужен — следует отключить, чтобы ограничить скачивание репозиториев по одному из протоколов
  • SSH ключи - следует настроить разрешенные алгоритмы и размеры ключей. Доступные алгоритмы: RSA, DSA, ECDSA, ED25519, ECDSA_SK, ED25519_SK. Необходимо запретить использование устаревших алгоритмов и слабых алгоритмов:
    1. Рекомендуется выключить “DSA SSH keys”, они считаются небезопасными
    2. Для “RSA SSH keys” рекомендуется установить длину ключа минимум 3072 бит
    3. Для “ECDSA SSH keys” рекомендуется установить длину ключа минимум 256 бит
    4. ECDSA_SK SSH keys и ED25519_SK SSH keys можно оставить включенными, если планируется использовать аппаратные ключи FIDO2/U2F

Ограничения для аккаунтов пользователей

Частично реализовано по умолчанию

Важность: Умеренная

Как найти: Необходимо перейти в панель администратора, нажав кнопку Admin внизу меню справа. В разделе Настройки следует перейти в раздел Основные и развернуть меню “Аккаунт и ограничения”. В меню требуется проверить настройки и изменить их как указано ниже:

Требуется настроить параметры проектов, ограничения на максимальный размер, длительность сеансов и параметры пользователей. Базовые настройки для организации безопасности и управления доступом.

Рекомендуется установить лимиты на размер репозиториев, push’ей, импортов/экспортов. Следует задать TTL для сессий и токенов.

  • Лимит проектов по умолчанию - рекомендуется настроить максимальное количество проектов на пользователя
  • Максимальная продолжительность сессии - реализовано по умолчанию - длительность сессии в минутах. Изменение параметра требует рестарта подов webservice, sidekiq. По умолчанию 7 дней.
  • Настройки сессии - реализовано по умолчанию - считать истечение срока действия сессии пользователя от времени создания сессии (входа в приложение) или от времени последнего действия пользователя
  • Запомнить меня - включить или выключить механизм автоматического возобновления сессии. Если включено, пользователь никогда не разлогинится, если будет периодически заходить в интерфейс в течение времени, которое настроено в пункте Максимальная продолжительность сессии
  • Требовать дату истечения - реализовано по умолчанию - требовать установки даты истечения токена доступа при создании пользовательского токена
  • Пользовательские OAuth-приложения - Разрешить пользователям регистрировать любые приложения для использования GitLab в качестве провайдера OAuth. Это разрешение обычным пользователям регистрировать свои OAuth2-клиенты в Deckhouse Code (то есть использовать Deckhouse Code как провайдера OAuth2 для внутренних/сторонних приложений). Настоятельно рекомендуется выключить
  • Авторизация OAuth - разрешить использование Resource Owner Password Credentials (ROPC) механизма. Настройка разрешает пользователям (или скриптам) получать OAuth-токены по логину/паролю без регистрации OAuth-клиента (то есть без идентификации приложения). Настоятельно рекомендуется выключить
  • Разрешить новым пользователям создавать top level группы - Это изменяет настройку по умолчанию для новых пользователей, которые будут созданы вручную или первый раз зайдут через SSO/LDAP. Это не меняет настройки для уже созданных пользователей Для уже созданных пользователей настройка меняется конкретно в каждом профиле пользователя в административном интерфейсе управления пользователями (панель администратора -> Обзор -> Пользователи -> выбрать конкретного пользователя -> Редактировать -> “Может создавать группы верхнего уровня:” Да/нет)
  • Сделать профили новых пользователей приватными по умолчанию - рекомендуется ко включению
  • Разрешить пользователям с ролью Гость создавать группы и личные проекты - рекомендуется к выключению

Ограничение регистрации новых пользователей

Частично реализовано по умолчанию

Важность: Критическая

Как найти: Необходимо перейти в панель администратора, нажав кнопку Admin внизу меню справа. В разделе Настройки следует перейти в раздел Основные и развернуть меню “Ограничения регистрации”. В меню требуется проверить настройки и изменить их как указано ниже:

Требуется настроить способ создания новых учётных записей. Рекомендуется отключить регистрацию пользователей и страницу логина, а также обязательно требовать подтверждение email и установить минимальную длину пользовательских паролей. Часть опций может быть отключена для изменения через панель администратора в UI и для большей безопасности перенесена в спецификацию kubernetes custom-ресурса codeinstances

  • Регистрация включена - реализовано по умолчанию - отключить возможность создания новых пользователей через страницу регистрации (обратное включение возможно только через спецификацию CR)
  • Требуется одобрение администраторов для новых пользователей - реализовано по умолчанию - пользователь должен быть явно одобрен администратором перед входом. Действует только при включённой регистрации, не распространяется на SSO/LDAP пользователей
  • Настройки подтверждения электронной почты - следует выбрать режим обязательного подтверждения электронной почты пользователей. Если включена регистрация, необходимо использовать жесткий режим
  • Минимальная длина пароля(количество символов) - реализовано по умолчанию - только для внутренних учетных записей, неактуально при авторизации через SSO/LDAP. По умолчанию 8 символов
  • Разрешенные домены для регистрации - белый список почтовых доменов, с которыми могут зарегистрироваться новые пользователи. Действует только при включённой регистрации, не распространяется на SSO/LDAP пользователей
  • Список запрещенных доменов - черный список почтовых доменов для регистрации новых пользователей. Действует только при включённой регистрации, не распространяется на SSO/LDAP пользователей
  • Ограничения для адресов электронной почты при регистрации - способ ограничения почтовых адресов новых пользователей по регулярному выражению. Действует только при включённой регистрации, не распространяется на SSO/LDAP пользователей

Ограничение входа пользователей

Частично реализовано по умолчанию

Важность: Критическая

Как найти: Необходимо перейти в панель администратора, нажав кнопку Admin внизу меню справа. В разделе Настройки следует перейти в раздел Основные и развернуть меню “Ограничения входа”. В меню требуется проверить настройки и изменить их как указано ниже:

Рекомендуется ограничить круг лиц, имеющих доступ к Deckhouse Code, руководствуясь принципом наименьших привилегий. Часть опций может быть отключена для изменения через панель администратора в UI и для большей безопасности перенесена в спецификацию kubernetes custom-ресурса codeinstances

  • Период отсрочки двухфакторной аутентификации - реализовано по умолчанию - максимальное время, в течение которого пользователи могут откладывать настройку двухфакторной аутентификации (в часах). Рекомендуется установить значение 0, чтобы требовать настройку второго фактора при следующем входе
  • Уведомление по email о неизвестных входах - Включить email-уведомления - реализовано по умолчанию - Уведомлять пользователей по email, если пользователь вошел с нового устройства или IP адреса, который раньше не использовался для доступа к Deckhouse Code
  • Разрешить аутентификацию по паролю через веб-интерфейс - настройка возможна только через спецификацию CR. Рекомендуется выключить на настроенном инстансе, если все пользователи, в том числе и администраторы Deckhouse Code авторизуются через SSO/LDAP
  • Разрешить аутентификацию по паролю для Git через HTTP(S) - рекомендуется снять этот флажок, чтобы вместо этого использовать личный токен доступа. Данная опция должна быть отключена в целях безопасности
  • Обязать администраторов использовать двухфакторную аутентификацию - рекомендуется к включению
  • Требовать включение двухфакторной аутентификации для всех пользователей - рекомендуется к включению, даже при включенной авторизации через SSO/LDAP. Рекомендуется к выключению, если второй фактор проверяется на уровне SSO провайдера
  • Включить режим администратора - Требовать дополнительную аутентификацию для выполнения административных задач. Рекомендуется к включению
  • Требовать подтверждение электронной почты для заблокированных учётных записей - Если аккаунт пользователя заблокирован, GitLab попросит подтвердить владение почтой: при следующей попытке входа система отправит код/ссылку на основной e-mail, и без этого подтверждения войти нельзя. Рекомендуется к включению

Настройки импорта и экспорта

Частично реализовано по умолчанию

Важность: Умеренная

Как найти: Необходимо перейти в панель администратора, нажав кнопку Admin внизу меню справа. В разделе Настройки следует перейти в раздел Основные и развернуть меню “Настройки импорта и экспорта”. В меню требуется проверить настройки и изменить их как указано ниже:

Для защиты кодовой базы рекомендуется установить ограничения на экспорт и импорт проектов и групп по принципам “наименьших привилегий” и белых списков

  • Источники импорта - реализовано по умолчанию - При необходимости следует разрешить импорт проектов из конкретных систем. Источник “Repository by URL” позволяет импортировать любой Git репозиторий по URL. По умолчанию все выключено
  • Разрешить перенос групп и проектов Gitlab путем прямого переноса - реализовано по умолчанию - действие запрещено по умолчанию
  • Экспорты администраторами без аудита - реализовано по умолчанию - Если выключить, экспорт/скачиванию экспортов проектов или групп не пишутся в логи аудита безопасности. Экспорты, сделанные не-админами, по-прежнему попадают в аудит.
  • Экспорт проекта - Разрешить создание .tar.gz архива с данными проекта (репозитории, задачи, MR, комментарии, вложения, настройки и многое другое), чтобы затем импортировать его на другой инстанс Deckhouse Code/Gitlab или в другую группу. Рекомендуется к выключению
  • Максимальное количество одновременных заданий импорта для GitHub - рекомендуется установить разумное ограничение на количество одновременных импортов проектов для сохранения ресурсов системы
  • Максимальное количество одновременных заданий импорта для BitBucket Cloud - рекомендуется установить разумное ограничение на количество одновременных импортов проектов для сохранения ресурсов системы
  • Максимальное количество одновременных заданий импорта для BitBucket Server - рекомендуется установить разумное ограничение на количество одновременных импортов проектов для сохранения ресурсов системы

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

Эта секция позволяет ограничить доступ и характер взаимодействия пользователей с репозиториями для всех существующих проектов

Как найти: Необходимо перейти в панель администратора, нажав кнопку Admin внизу меню справа. В разделе Настройки следует перейти в раздел Репозиторий. Требуется развернуть соответствующие меню, проверить настройки и изменить их как указано ниже:

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

Реализовано по умолчанию

Важность: Умеренная

  • Защита начальной ветки по умолчанию - защита включена, ветка изначально будет защищенной (protected branch)
  • Разрешен push - только пользователи с ролью Maintainer и выше могут выполнять прямой коммит в основную ветку. По возможности, рекомендован полный запрет на прямой коммит в основную ветку всем пользователям и работа только через бранчи и создание запросы на слияние (Pull requests)
  • Разрешен merge - по умолчанию только пользователи с ролью Maintainer и выше могут выполнять merge веток в основную
  • Разрешен force push - разрешение всем пользователям с доступом на push выполнять force push. Отключено по умолчанию
  • Разрешить разработчикам делать push начального коммита - разработчики могут сделать push начального коммита в репозиторий, но не последующих. Запрещено по умолчанию

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

Важность: Умеренная

Рекомендовано настроить правила отправки изменений (push rules) на уровне всей инсталляции продукта и запретить их переопределение на уровне групп и проектов. Это позволит обеспечить единую политику безопасности для всех пользователей и проектов и минимизирует риск несанкционированных изменений исходного кода. Следующие правила рекомендуется настроить:

  • Регулярное выражение для емейла автора коммита - запретить коммиты от некорпоративных адресов электронной почты
  • Проверять имя коммитера - имя коммиттера должно совпадать с именем профиля в Code
  • Проверять email коммитера - адрес электронной почты коммитера должен быть подтвержден в профиле Code
  • Проверка зарегистрованного пользователя - автор коммита должен быть пользователем Code
  • Блокировать утечки секретов - нельзя коммитить файлы с именами pem или id_rsa. Полный список запрещённых имён смотри в документации

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

Как найти: Необходимо перейти в панель администратора, нажав кнопку Admin внизу меню справа. В разделе Настройки следует перейти в раздел CI/CD. Требуется развернуть соответствующие меню, проверить настройки и изменить их как указано ниже:

Непрерывная интеграция и деплой

Важность: Умеренная

  • Срок действия токена аутентификации для инстанс раннеров - Настройка управляет сроком жизни токенов аутентификации для раннеров, созданных на уровне инстанса. По умолчанию бессрочно
  • Срок действия токена аутентификации для групповых раннеров - Настройка управляет сроком жизни токенов аутентификации для раннеров, созданных на уровне группы. По умолчанию бессрочно
  • Срок действия токена аутентификации для проектных раннеров - Настройка управляет сроком жизни токенов аутентификации для раннеров, созданных на уровне проекта. По умолчанию бессрочно

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

Раннеры

Важность: Критическая

  • Получить данные о версии релиза GitLab Runner с GitLab.com - данные о версиях официальных раннеров периодически запрашиваются с GitLab.com, чтобы определить, требуется ли обновление раннеров. В закрытых окружениях настоятельно рекомендуется к выключению.
  • Разрешить токены участника - Этот параметр включает или выключает функционал создания раннеров с помощью токенов регистрации. Токены регистрации раннеров — это «общие секреты» на уровне инстанса/группы/проекта, с помощью которых любой, у кого есть токен, мог зарегистрировать новый раннер. Этот механизм считается устаревшим и небезопасным, необходимо использовать токены аутентификации раннеров. Токены аутентификации уникальные для каждого раннера, поддерживают ротацию и являются безопасной заменой токенам регистрации. Настоятельно рекомендуется к выключению.

Разрешения токена задания CI/CD

Реализовано по умолчанию

Важность: Критическая

Критическая секция для предотвращения несанкционированного доступа к данным одного проекта другим проектом

  • Включить и применять белый список токенов заданий для всех проектов - при выполнении задания сборки раннеры могут обращаться к другим проектам внутри Deckhouse Code. Когда эта опция включена, в проекте, к которому идет обращение внутри задания, должно быть явно разрешено такое обращение от конкретного проекта. Опция разрешения доступа от всех групп и проектов будет скрыта. Рекомендуется оставить включенной

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

Важность: Низкая

Как найти: Необходимо перейти в панель администратора, нажав кнопку Admin внизу меню справа. В разделе Настройки следует перейти в раздел “Отчетность”. Требуется развернуть соответствующие меню, проверить настройки и изменить их как указано ниже:

Данная секция позволяет осуществить настройку reCAPTCHA, ограничения количества ip-адресов на одного пользователя и прочих аналогичных механизмов для защиты от ботов и спама. Настройка необходима только для инсталляций, к которым есть доступ через интернет.

Отсылка метрик в сторонние системы

Реализовано по умолчанию

Важность: Критическая

Как найти: Необходимо перейти в панель администратора, нажав кнопку Admin внизу меню справа. В разделе Настройки следует перейти в раздел “Метрики и профилирование”. Требуется развернуть соответствующие меню, проверить настройки и изменить их как указано ниже:

Требуется настроить параметры сбора и отправки метрик и прочей статистики использования продукта во внешние системы. Такое поведение является нежелательным и отключено по умолчанию (кроме сбора и отправки технических метрик в систему мониторинга Deckhouse, расположенную в том же кластере)

  • Статистика использования - проверка обновлений средствами продукта и отправка статистики по использованию продукта отключены на уровне кода. Проверка обновлений реализована средствами Deckhouse Kubernetes Platform
  • Отслеживание событий - отслеживание и отправка событий отключены на уровне кода, включить их нельзя

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

Реализовано по умолчанию

Важность: Умеренная

Как найти: Необходимо перейти в панель администратора, нажав кнопку Admin внизу меню справа. В разделе Настройки следует перейти в раздел “Сеть”. Требуется развернуть соответствующие меню, проверить настройки и изменить их как указано ниже:

Ограничение скорости и количества запросов (rate limiting) является важным механизмом для защиты системы от DDOS-атак и перегрузки ресурсов.

  • Ограничения скорости пользователей и IP-адресов - секция позволяет установить ограничения на количество различных типов запросов к Deckhouse Code, в зависимости от типа запроса и IP-адреса пользователя
  • Ограничения скорости реестра пакетов - установить ограничения скорости для запросов к API реестра пакетов, которые переопределяют общие ограничения для пользователей и IP-адресов
  • Лимиты скорости файлов API - установить определенные ограничения для запросов Files API, которые заменяют общие ограничения пользователей и скорости IP-адресов
  • Ограничения скорости поиска - Установить ограничения скорости для поисковых запросов через веб или API
  • Ограничения на частоту запросов Git HTTP - рекомендуется настроить определенные ограничения для запросов Git HTTP
  • Ограничения на частоту запросов Git SSH - рекомендуется настроить определенные ограничения для запросов Git SSH
  • Ограничения на частоту запросов Git LFS - рекомендуется настроить определенные ограничения для запросов Git LFS
  • Исходящие запросы - Ограничить запросы к сторонним ресурсам от хуков и интеграций
  • Гранулярные ограничения частоты запросов к различным API ресурсам - рекомендуется настроить ограничения на частоту запросов к различным API ресурсам, в зависимости от профиля использования API
  • Ограничения скорости импорта и экспорта - Установить ограничение скорости для импорта и экспорта проектов и групп на пользователя.
  • Ограничения скорости создания пайплайна - Ограничьте количество запросов на создание пайплайна в минуту. Это ограничение включает пайплайны, созданные с помощью пользовательского интерфейса, API и фоновой обработки

Настройки для ежедневной эксплуатации

Общие рекомендации по управлению доступом, группами, ревью и поддержание безопасности в повседневной работе.

Настройки уровня групп

Как найти: Необходимо перейти в конкретную группу, в боковом меню слева следует перейти во вкладку “Настройки”. Структура документации отражает название разделов меню и секций этих разделов

Основные

Важность: Критическая

Рекомендуется контролировать уровень видимости группы и следовать концепции наименьших привилегий, выставляя приватный, где это возможно. Чем строже уровень доступа, тем легче осуществить гранулярный контроль и тем меньше риск утечки информации.

Права доступа и возможности группы

Частично реализовано по умолчанию

Важность: Критическая

  • Участники не могут приглашать группы за пределами имя группы и ее подгруппы - реализовано по умолчанию доступно только в группе верхнего уровня. Применяется ко всем подгруппам. Группы (за пределами конкретной группы), которым уже предоставлен доступ, по-прежнему сохраняют доступ, если они не удалены вручную
  • Проекты в имя группы не могут быть переданы другим группам - применяется ко всем подгруппам, если не переопределена владельцем подгруппы. Отключает возможность выдачи доступа другим пользователям или группам за пределами имя группы
  • Уровень доступа к wiki - следует контролировать, кто может просматривать и редактировать wiki в группе. Во избежание компрометации внутренней информации целесообразно установить приватный уровень, если в обратном нет необходимости
  • Включенные протоколы доступа к git - гранулярная настройка протоколов (SSH / HTTP(S)), по которым возможен git-доступ в конкретной группе
  • Минимальная роль необходимая для создания проектов - минимальная роль у пользователя, необходимая для создания проектов в конкретной группе. Рекомендуется “Владелец” или “Мейнтейнер”
  • Роли которым разрешено создавать подгруппы - минимальная роль у пользователя, необходимая для создания подгрупп в группе. Рекомендуется “Владелец” или “Мейнтейнер”
  • Пользователи могут создавать токены доступа группы и токены доступа проекта в этой группе - настройка разрешает/запрещает членам группы создавать групповые и проектные токены для внешних интеграций. Групповые токены может создать только пользователь с ролью “Владелец” в этой группе. Пользователи могут создавать токены на уровне проекта, но их максимальные права будут ограничены ролью пользователя в проекте
  • Все пользователи в этой группе должны включить двухфакторную аутентификацию - следует контролировать обязательность двухфакторной аутентификации для всех пользователей в группе. Целесообразно включить данную опцию и установить как можно меньшую задержку применения 2FA, если в обратном нет необходимости. Также не следует разрешать подгруппам устанавливать собственные правила двухфакторной аутентификации
  • Контроль доступа к страницам->Ограничить доступ только для участников проекта ко всем проектам группы - При включении этой настройки доступ к контенту страниц (pages) будет только для участников конкретного проекта. При выключении доступ можно настраивать в каждом проекте отдельно

Репозиторий

Деплой токены

Важность: Умеренная

Рекомендуется регулярно проводить аудит деплой-токенов и удалять лишние, а также следить, чтобы текущие сохраняли гранулярность, были четко описаны и имели срок действия

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

Важность: Умеренная

Настройки безопасности основной ветки для всех проектов группы. Позволяют переопределять настройки всей инсталляции Deckhouse Code для вашей конкретной группы. Смотрите эту секцию с детальными рекомендациями

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

Важность: Умеренная

Рекомендовано настроить правила отправки изменений (push rules) на уровне группы. Если разрешено переопределение глобальных правил - переопределить для более гранулярного контроля доступа к проектам и артефактам в группе. Список рекомендованных к настройке правил приведен тут

Также, рекомендуется запретить проектам группы переопределение уже сконфигурированных на этом уровне правил, если нет необходимости в обратном.

CI/CD

Секция настройки и переопределения параметров CI/CD для всех проектов группы

Пайплайны

Важность: Умеренная

Рекомендуется включить опцию Включить формат JWT для токенов заданий CI/CD

Переменные

Важность: Умеренная

  • Маскируйте переменные CI/CD, которые содержат чувствительную информацию, чтобы избежать их непреднамеренной публикации в логах пайплайна или событиях аудита

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

Как найти: Необходимо перейти в конкретный проект, в боковом меню слева следует перейти во вкладку “Настройки”. Структура документации отражает название разделов меню и секций этих разделов

Основные

Уровень доступа, доп.функции проекта, разрешения

Частично реализовано по умолчанию

Важность: Умеренная

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

Репозиторий

Ниже приведены рекомендации по настройке основных параметров безопасности репозитория проекта

Правила отправки изменений (push rules)

Важность: Умеренная

Рекомендовано настроить правила отправки изменений(push rules) на уровне проекта. Если разрешено переопределение правил уровня группы - переопределить для более гранулярного контроля доступа к проектам и артефактам в группе. Список рекомендованных к настройке правил приведен тут

Рекомендуется обратить внимание на применение остальных правил отправки изменений, если они помогут повысить безопасность в контексте конкретного проекта.

Защищенные ветки

Важность: Низкая

Для обеспечения безопасности кодовой базы в основной и стабильных ветках репозитория используйте механизм защиты веток (protected branches), позволяющий переопределить роли, имеющие право на слияние MR или прямой коммит. По умолчанию прямой коммит в защищенную ветку могут делать только пользователи с ролью “Мейнтейнер” и “Владелец”

Защищенные теги

Важность: Низкая

Если в процессе разработки используются теги (например, для релизов), можно указать шаблон, какие теги может создавать та или иная роль в проекте. Например, теги с версиями продукта вида _v может создавать только “Мейнтейнер”

Деплой токены

Важность: Умеренная

Рекомендуется регулярно проводить аудит деплой-токенов и удалять лишние, а также следить, чтобы текущие сохраняли гранулярность, были четко описаны и имели срок действия

Ключи деплоя

Важность: Умеренная

Ключи деплоя являются альтернативным токенам деплоя механизмом для выпуска непривязанных к пользовательскому аккаунту токенов и к нему применимы все те же рекомендации.

Запросы на слияние

Важность: Умеренная

Секция регламентирует правила работы с запросами на слияния (MR) в репозитории проекта

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

  • Включение механизма владения кодом (CODEOWNERS) для обеспечения гранулярного рецензирования изменений в кодовой базе проекта
  • Включение расширенных политик ревью запросов на слияния (Merge request approval rules) для обеспечения гранулярного контроля над процессом и участниками рецензирования изменений в кодовой базе проекта. В рамках этих правил также стоит рассмотреть:
    • Запрет автору MR утверждать собственный MR
    • Настройку минимального числа рецензентов (approvers)
    • Запрет изменения правил на уровне проекта через включение файла с описанием политик рецензирования из другого проекта (механизм include), куда у разработчиков этого проекта нет доступа

Проверки слияния

Важность: Умеренная

Для повышения безопасности кодовой базы рекомендуется проводить ряд ручных и автоматизированных проверок перед слиянием кода в основные/стабильные ветки:

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

CI/CD

Секция настройки и переопределения параметров CI/CD для конкретного проекта

Пайплайны

Важность: Умеренная

В этой секции рекомендуется убедиться, что у вас включена опция Используйте отдельные кеши для защищенных ветвей

Также рекомендуется:

  • Контролировать доступ к .gitlab-ci.yml через механизм владения кодом (CODEOWNERS), чтобы не допустить случайного или намеренного изменения пайплайнов или их компонентов
  • Использовать механизм ручного одобрения (manual approval) при написании пайплайна для ограничения на запуск критичных пайплайнов или их компонентов

Переменные

Важность: Умеренная

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

Помимо этого, рекомендуется:

  • Не следует хранить секреты в plaintext, предпочтительно использовать CI/CD переменные или настроить интеграцию с Deckhouse Stronghold или другим совместимым Vault хранилищем. Пример интеграции с Vault совместимым хранилищем доступен по ссылке
  • Следует обозначать переменные как protected и masked везде, где возможно, во избежание раскрытия их значений или случайного переопределения в пайплайне

Токены запуска конвейера

Токены запуска конвейера способны запускать пайплайны с правами пользователя его выпустившего, что является потенциальным вектором атаки. К таким токенам применимы все рекомендации из секции настройки уровня групп.

Права доступа токена заданий CI/CD

Рекомендуется контролировать список групп и проектов, которым разрешен доступ из своих пайплайнов к данным текущего проекта по принципу белого списка

Пакеты и реестры

Важность: Умеренная

Защищайте критические пакеты, опубликованные в реестре пакетов (package registry) с помощью механизма защищенных пакетов, настраивая доступ к ним только для пользователей выше определенной роли.

Аналогичная рекомендация применима к реестру контейнеров (container registry)