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

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

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

Мы используем шифрование 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 реплик

Кейсы:

  • Перезалить данные на ноду 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> будут помечены как устаревшие для приоритизации перепроверки. Перепроверка будет работать асинхронно в фоновом режиме.

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

При необходимости Вы можете удалить модуль и полностью очистить кластер от его следов в 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 иначе Вы потеряете возможность восстановиться из существующиъ бекапов в будущем