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

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

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

Примечание

При установке LCM с параметром enable_rbac_model: true в lcm-config.yaml (и настроенной интеграцией LDAP) ролевая модель настраивается автоматически в процессе установки — см. раздел Установка KeyStack LCM. Данная инструкция описывает включение ролевой модели на уже развёрнутой инсталляции, если она не была включена при установке.

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

Важно

Если используется LCM старой версии (pre-k0s), учтите, что миграция доступна начиная с версии ks2026.2.1. Сначала выполните миграцию на LCM в режиме k0s по инструкции Миграция со старой версии LCM. После завершения миграции включите ролевую модель по этой инструкции.

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

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

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

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

  • подготовлен файл с корневым сертификатом LDAP/AD в формате PEM и размещён в том же каталоге, что и lcm-config.yaml; при использовании промежуточных центров сертификации в файл добавлена вся цепочка сертификатов;

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

    Важно

    Количество необходимых ТУЗ зависит от выбранного варианта управления паролями: с автоматической ротацией или без неё. Оба варианта описаны в разделе Ротация учётных записей LDAP.

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

Включение параметра в lcm-config.yaml

  1. Откройте файл конфигурации:

    $ vi ~/installer/lcm-k0s/lcm-config.yaml

  2. Включите ролевую модель:

    enable_rbac_model: true

  3. Если интеграция с LDAP/AD ещё не настроена, задайте блок Active Directory:

    # Active Directory
ldap_enable: "true"
ldap_host: "dc-01.domain.loc"
ldap_port: 636
ldap_ca_cert_file: "ldap-root-cert.crt"
ldap_bind_dn: "CN=test,CN=Users,DC=domain,DC=loc"
ldap_user_search_basedn: "CN=Users,DC=domain,DC=loc"
ldap_group_search_basedn: "CN=Users,DC=domain,DC=loc"
ldap_reader_group_dn: "CN=KeyStack-Readers,CN=Users,DC=domain,DC=loc"
ldap_auditor_group_dn: "CN=KeyStack-Auditors,CN=Users,DC=domain,DC=loc"
ldap_admin_group_dn: "CN=KeyStack-Admins,CN=Users,DC=domain,DC=loc"

    Подготовка сертификата LDAPS и описание параметров приведены в разделе Подключение к Active Directory инструкции Установка KeyStack LCM.

  4. Настройте учётные записи привязки LDAP в зависимости от выбранной схемы управления паролями:

Применение изменений

Примените изменения — повторно запустите штатную команду установки приложений (обычный re-apply конфигурации, см. README дистрибутива lcm-k0s):

$ task k8s-install-apps-multi-node

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

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

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

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

  • пользователи с ролями admin, security_auditor и reader получают доступ к интерфейсу GitLab;

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

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

Проверка доступа к 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. При использовании внешнего Vault путь имеет вид /secrets/<vault_engine>/<vault_prefix>/secrets/accounts, где vault_engine и vault_prefix задаются в lcm-config.yaml.

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

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

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