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

Безопасность

Как мы обеспечиваем безопасную коммуникацию между компонентами?

Мы используем шифрование TLS для всех внутренних коммуникаций между сервисами GitLab внутри кластера Kubernetes. Мы также гарантируем, чтобы любой внешний доступ был защищен с помощью HTTPS или другого безопасного протокола.

Как мы обеспечиваем безопасный сбор метрик?

Мы защищаем сбор метрик, используя контейнер sidecar kube-rbac-proxy вместе с RBAC Kubernetes. Kube-rbac-proxy действует как слой аутентификации и авторизации, обеспечивая доступ к конечным точкам метрик только для запросов с действующими правами.

Какое шифрование TLS поддерживается?

  • Для всех входящих и исходящих TLS-соединений требуется TLS 1.2 или выше.
  • TLS-сертификаты должны иметь не менее 112 бит. Ключи RSA, DSA и DH короче 2048 бит, а
    также ключи ECC короче 224 бит не безопасны и запрещены.

Политика обновлений

  • С изменением мажорной версии модуля, изменяется мажорная версия Gitlab (ex. 17 -> 18)
  • С изменением минорной версии модуля, изменяется минорная или патч версия Gitlab (ex. 17.3 -> 17.4, 17.3.0 -> 17.3.6)
  • Полный список соответствия версиям модуля к версиям Gitlab вы можете посмотреть в разделе Описание

Вопросы связанные с Gitaly серверами

Почему сервис имеет расширенные права?

Gitaly использует механизм cgroup для управления потреблением ресурсов во время операций над Git репозиториями. Чтобы работать в среде Kubernetes, мы должны разрешить pod в его собственную cgroup по пути /sys/fs/cgroup на ноде.

Capabilities:

  • SETUID , SETGID, CHOWN - Используются init контейнером, чтобы задать пользователя git:git в cgroup пода
  • FOWNER - для обхода проверки если директория с Git данными имеет другого владельца
  • SYS_ADMIN - обязательно для монтирования cgroupfs и работы cgroup иерархией
  • SYS_RESOURCE - обязательно для работы с лимитами ресурсов в cgroup (CPU, Memory, IO)
  • SYS_PTRACE - для выполнения системных вызовов вида process_vm_readv / process_vm_writev
  • KILL - обязательно для завершения или передачи сигнала процессам в управляемых cgroups

Как обновить одну из Gitaly реплик

Кейсы:

  • Перезалить данные на ноду Gitaly после пересоздания PV
  • Ручное обновление ноды когда данные устарели

Для обновления определенной ноды Gitaly выполните:

kubectl exec -i -t -n d8-code praefect-0 -c praefect -- praefect -config /etc/gitaly/config.toml verify --virtual-storage <virtual_storage> --storage <gitaly_pod_name>

Данные всех репозиториев на <gitaly_pod_name> будут помечены как устаревшие для приоритизации перепроверки. Перепроверка будет работать асинхронно в фоновом режиме.

Конфигурация сети

Как использовать ownLoadBalancer с зарезервированным публичным IPv4-адресом в Yandex Cloud

Чтобы назначить вашему ownLoadBalancer зарезервированный публичный IPv4-адрес, достаточно указать специальный label. Пример:

network:
    ownLoadBalancer:
      annotations:
        yandex.cpi.flant.com/listener-address-ipv4: xx.xx.xx.xx
      enabled: true

Важно: Указанный IPv4-адрес должен быть заранее зарезервирован в вашем облаке через Yandex Cloud Console или CLI.

Удаление модуля

При необходимости Вы можете удалить модуль и полностью очистить кластер от его следов в 2 простых шага:

  • Выключите модуль, следуя обычной процедуре выключения модуля (одинакова для всех модулей кластера DKP)
  • Добавьте в moduleConfig аннотацию modules.deckhouse.io/allow-disable: "true", чтобы предотвратить ошибку удаления от deckhouse-controller
  • Измените enable параметр в moduleConfig со значения true на false
  • Удалите namespace, так как он может содержать некоторые остаточные артефакты в виде configmap или секретов: kubectl delete ns d8-code

Перед удалением секретов не забудьте сохранить secrets/rails-secret иначе Вы потеряете возможность восстановиться из существующиъ бекапов в будущем