Включение ролевой модели в KeyStack

Эта инструкция описывает процесс подключения ролевой модели на существующем LCM после обновления до релиза ks2026.2 или при установке ks2026.2 без ролевой модели.

Ролевая модель обеспечивает централизованное управление доступом пользователей к компонентам платформы через интеграцию с LDAP/AD. После включения ролевой модели доступ к GitLab и NetBox осуществляется через учётные записи централизованного каталога организации.

Примечание

При новой установке ks2026.2 с включённой интеграцией LDAP (параметр auth LDAP for GitLab and NetBox = y в installer.sh) ролевая модель настраивается автоматически: создаётся учётная запись ks-admin, блокируется root, настраивается интеграция LDAP для GitLab и NetBox, учётные данные сохраняются в Vault. Данная инструкция предназначена для случаев, когда LDAP не был включён при установке.

Ролевая модель KeyStack описана в разделе:

Предварительные требования

Перед началом работы убедитесь, что:

  • LCM обновлён до релиза ks2026.2 или установлен с этим релизом;

  • имеется доступ к серверу LDAP/AD с поддержкой LDAPS (TLS);

  • подготовлены корневой и промежуточный сертификаты для LDAP/AD;

  • известны учётные данные служебного пользователя LDAP с правами просмотра;

    Важно

    При интеграции с AD сервисы LCM (GitLab, NetBox) и Keystone должны использовать разные ТУЗ: одну — для LCM-узла, другую — для региона.

  • настроены группы LDAP/AD для ролей KeyStack admin, reader и security_auditor.

Подготовка файлов и скрипта

  1. Загрузите скрипт включения ролевой модели из репозитория вендора по ссылке, предоставленной проектным менеджером.

  2. Разместите его в директории дистрибутива ~/installer на LCM.

  3. Создайте файл с сертификатами LDAPS в директории ~/installer/certs/:

    # mkdir -p ~/installer/certs
# vi ~/installer/certs/ldaps.pem

  4. Поместите в файл ldaps.pem корневой и промежуточный сертификаты вашего сервера LDAP/AD в формате PEM.

  5. Убедитесь, что в файлах конфигурации указан актуальный релиз. Проверьте содержимое файлов ~/installer/settings и ~/installer/config/settings:

    # grep RELEASE ~/installer/settings
# grep RELEASE /installer/config/settings

  6. Убедитесь, что значение переменной RELEASE соответствует export RELEASE=ks2026.2-sberlinux.

  7. Если значение отличается, отредактируйте файлы и установите корректный релиз.

Восстановление паролей NetBox

Ролевая модель требует наличия паролей NetBox в файлах окружения. При необходимости восстановления паролей выполните следующие действия:

  1. Зайдите на LCM-узел по SSH.

  2. Перейдите в директорию с архивом инсталлятора.

  3. Извлеките из архива инсталлятора installer-<version>-sberlinux-offline.tgz файлы installer/netbox-docker/env/*.env. Эти файлы содержат необходимые пароли для базы данных, Redis и других компонентов NetBox.

    # tar -xzvf <имя файла архива>.tgz installer/netbox-docker/env/*.env

  4. Если пароли для сервисов были изменены, отредактируйте извлечённые файлы — укажите в них актуальные значения.

  5. Скопируйте файлы с паролями в необходимую директорию:

    # cp ~/installer/netbox-docker/env/*.env /installer/data/netbox/env/

Запуск скрипта включения ролевой модели

  1. Перейдите в директорию дистрибутива и подготовьте окружение:

    # cd ~/installer
# source settings

  2. Получите пароль пользователя root GitLab из Vault. Этот пароль находится по пути secret_v2 / deployments / <LCM FQDN> / secrets / accounts в секрете gitlab_root_password.

  3. Установите переменную окружения с паролем GitLab и запустите скрипт:

    # export GITLAB_PASSWORD=<пароль из Vault>
# bash enable_rbac.sh

  4. Скрипт запросит параметры интеграции с LDAP/AD.

  5. При выполнении скрипта ответьте на вопросы согласно вашей конфигурации LDAP/AD:

    • auth LDAP for GitLab and NetBox:

      • y — включить поддержку интеграции с каталогами LDAP и ролевой модели в GitLab и NetBox; при выборе этого варианта укажите:

        • LDAP Server URI: адрес LDAP-сервиса в формате FQDN. Например: ldap.example.com;

        • LDAP Server Port [636]: порт LDAP-сервиса, по умолчанию 636, можно задать свой;

        • LDAP BIND DN: пользователь в LDAP с правами просмотра, используется для подключения к LDAP. Например: CN=ldap-reader,CN=Users,DC=example,DC=com;

        • LDAP BIND Password: пароль пользователя для подключения к LDAP;

        • LDAP USER SEARCH BASEDN: имя контейнера (Distinguished Name) в LDAP, с которого начинается поиск пользователей. Например: DC=example,DC=com;

        • LDAP GROUP SEARCH BASEDN: база поиска групп LDAP; возвращает группы, к которым принадлежит пользователь. Например: OU=KeyStack,OU=Groups,DC=example,DC=com;

        • LDAP GROUP for reader role: группа LDAP, пользователи из которой соответствуют роли reader. Например: CN=KeyStack-Readers,OU=KeyStack,OU=Groups,DC=example,DC=com;

        • LDAP GROUP for auditor role: группа LDAP, пользователи из которой соответствуют роли security_auditor. Например: CN=KeyStack-Auditors,OU=KeyStack,OU=Groups,DC=example,DC=com;

        • LDAP GROUP for admin role: группа LDAP, пользователи из которой соответствуют роли admin. Например: CN=KeyStack-Admins,OU=KeyStack,OU=Groups,DC=example,DC=com.

Обновление конфигурации паролей NetBox

После выполнения скрипта необходимо обновить пароли в файлах конфигурации NetBox.

  1. Подготовьте команды ниже, заменив в них значения паролей (netbox_db_password, netbox_redis_cache_password и другие) на фактические пароли из вашего окружения. Замените LDAP-BIND-PASSWORD на пароль служебного пользователя LDAP, который вы указывали ранее.

  2. Выполните следующие команды на LCM:

    # cd ~/installer/config
# source settings
# sed -i "s|DB_PASSWORD=.*|DB_PASSWORD=netbox_db_password|" $NETBOX_HOME/env/netbox.env
# sed -i "s|REDIS_CACHE_PASSWORD=.*|REDIS_CACHE_PASSWORD=netbox_redis_cache_password|" $NETBOX_HOME/env/netbox.env
# sed -i "s|REDIS_PASSWORD=.*|REDIS_PASSWORD=netbox_redis_password|" $NETBOX_HOME/env/netbox.env
# sed -i "s|SUPERUSER_PASSWORD=.*|SUPERUSER_PASSWORD=netbox_admin_password|" $NETBOX_HOME/env/netbox.env
# sed -i "s|AUTH_LDAP_BIND_PASSWORD: .*|AUTH_LDAP_BIND_PASSWORD: \"LDAP-BIND-PASSWORD\"|" $NETBOX_HOME/env/netbox.env
# sed -i "s|POSTGRES_PASSWORD=.*|POSTGRES_PASSWORD=netbox_db_password|" $NETBOX_HOME/env/postgres.env
# sed -i "s|REDIS_PASSWORD=.*|REDIS_PASSWORD=netbox_redis_password|" $NETBOX_HOME/env/redis.env
# sed -i "s|REDIS_PASSWORD=.*|REDIS_PASSWORD=netbox_redis_cache_password|" $NETBOX_HOME/env/redis-cache.env

Проверка работы ролевой модели

После завершения настройки проверьте работу ролевой модели.

Проверка доступа к GitLab

Откройте веб-интерфейс GitLab и войдите с учётной записью пользователя из группы LDAP. Убедитесь, что пользователь получил соответствующие права доступа согласно своей роли.

Проверка доступа к NetBox

Откройте веб-интерфейс NetBox и войдите с учётной записью пользователя из группы LDAP. Убедитесь, что пользователь получил права доступа согласно своей роли:

  • пользователь с ролью admin может просматривать, создавать, изменять и удалять объекты NetBox;

  • пользователи с ролями reader и security_auditor могут просматривать объекты NetBox без права создания, изменения и удаления;

  • пользователи с ролями member, operator_vm, app_operator и os_operator не получают доступ к интерфейсу NetBox.

Подробное поведение ролей в NetBox описано в разделе Ролевая модель в NetBox.

Что происходит при включении ролевой модели

При включении ролевой модели выполняются следующие изменения в конфигурации GitLab:

  • Блокируется встроенный пользователь root.

  • Создаётся технологическая учётная запись ks-admin.

  • Пароль и токен доступа (PAT) для ks-admin сохраняются в Vault по пути secret_v2 / deployments / <LCM FQDN> / secrets / accounts.

  • Все технические операции в дальнейшем выполняются от имени учётной записи ks-admin.

Это обеспечивает соблюдение принципов безопасности и исключает использование встроенных учётных записей для повседневных операций.

Настройка ролевой модели в KeyStack описана в разделе: