Установка KeyStack LCM

Компонент KeyStack LCM (Lifecycle Manager) обеспечивает жизненный цикл облака. Он также используется в качестве seed node — с него происходит установка и настройка всех остальных узлов в составе облака.

Примечание

В данной инструкции в качестве базового доменного имени облачной платформы используется cloud.itkey.com и имена сервисов по умолчанию. При выполнении инструкции указывайте ваши действительные имена.

Базовая установка LCM

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

  2. Скопируйте дистрибутив KeyStack на него любым удобным способом.

  3. Переключитесь на пользователя root, перейдите в папку с файлом дистрибутива и распакуйте дистрибутив платформы KeyStack.

    # sudo su -
# tar -xvf installer-ks2025.2.2-sberlinux-offline.tgz
# cd installer/

  4. Если для хранилища артефактов будет использовано клиентское хранилище Docker-образов:

    1. В папке installer/certs создайте файл mynexus.itkey.com.pem (где mynexus.itkey.com — FQDN вашего сервиса Nexus) и разместите в нем полную цепочку сертификатов вашего сервиса Nexus.

    2. Убедитесь, что в вашем Docker-хранилище существует пользователь с правами pull и push.

    Docker-образы для OpenStack и kolla-ansible будут сохранены в вашем Nexus в пространстве project_k.

  5. При интеграции KeyStack с клиентским сервисом идентификации и аутентификации (Active Directory или другой сервис LDAP с TLS) в папке installer/certs создайте файл ldaps.pem и разместите в нем полную цепочку сертификатов LDAPs.

  6. В распакованном архиве запустите скрипт installer.sh.

  7. Последовательно введите запрашиваемые данные:

    • home dir for the installation: путь к директории для установки, по умолчанию /installer;

    • IP address of this machine: IP-адрес LCM-узла, соответствующий доменному имени ks-lcm;

    • Use remote/existing Artifactory:

      • y — использовать собственное хранилище артефактов; при выборе этого варианта укажите:

        • FQDN хранилища Nexus (например, mynexus.itkey.com), не должно совпадать с FQDN для Nexus в составе дистрибутива KeyStack;

        • имя пользователя с правами pull и push в Docker-хранилище;

        • пароль пользователя с правами pull и push в Docker-хранилище, длина — не менее 8 символов.

      • n — развернуть новый Nexus на LCM-узле (вариант по умолчанию).

    • auth LDAP for Gitlab and Netbox:

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

        • LDAP Server URI: адрес LDAP-сервиса в формате ldaps://<IP или FQDN>;

        • LDAP BIND DN: пользователь в LDAP с правами просмотра, используется для подключения к LDAP;

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

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

        • LDAP GROUP SEARCH BASEDN: группа для поиска пользователя; вернет все группы, к которым принадлежит пользователь;

        • LDAP GROUP for reader role: группа LDAP, пользователи из которой соответствуют роли reader;

        • LDAP GROUP for auditor role: группа LDAP, пользователи из которой соответствуют роли auditor;

        • LDAP GROUP for admin role: группа LDAP, пользователи из которой соответствуют роли admin.

    • root domain name: корневое доменное имя сервисов KeyStack, например, cloud.itkey.com, оно будет добавлено к введенным ниже именам сервисов, таким образом, получатся имена вида <сервис>.cloud.itkey.com;

    • Nexus domain name: доменное имя сервиса Nexus, например, nexus;

    • GitLab domain name: доменное имя сервиса GitLab, например, ks-lcm;

    • Vault domain name: доменное имя сервиса Vault, например, vault;

    • Netbox domain name: доменное имя сервиса NetBox, например, netbox;

    • Generate Self-signed certificates:

      • y — сгенерировать новые самоподписанные сертификаты (вариант по умолчанию);

      • n — использовать существующие сертификаты; при выборе этого варианта разместите в папке installer/certs сертификаты:

        • ca.crt — корневой сертификат (root CA);

        • chain-ca.pem — цепочка CA-сертификатов;

        • nexus.cloud.itkey.com.crt и nexus.cloud.itkey.com.key — сертификат и приватный ключ сертификата для сервиса Nexus;

        • ks-lcm.cloud.itkey.com.crt и ks-lcm.cloud.itkey.com.key — сертификат и приватный ключ сертификата для сервиса GitLab;

        • vault.cloud.itkey.com.crt и vault.cloud.itkey.com.key — сертификат и приватный ключ сертификата для сервиса Vault;

        • netbox.cloud.itkey.com.crt и netbox.cloud.itkey.com.key — сертификат и приватный ключ сертификата для сервиса NetBox.

  8. Дождитесь завершения операции. На LCM-узле будут установлены и настроены компоненты:

    • SSH-ключи для беспарольного доступа на узлы;

    • самоподписанные сертификаты для служб LCM, при их использовании;

    • хранилище Sonatype Nexus (если был выбран вариант создания нового хранилища);

    • система автоматизации (GitLab-CI);

    • репозитории управления облаком (CI/CD);

    • NetBox (CMDB).

    Данные с текущей конфигурацией инсталляции сохраняются в Vault в директорию secret_v2 / deployments / <LCM FQDN> / secrets / accounts.

  9. При успешной установке будут показаны реквизиты для доступа к компонентам KeyStack. Сохраните реквизиты доступа к компонентам:

    • GitLab root password

    • GitLab runner token

    • GitLab SSH private key

    • GitLab SSH public key

    • Nexus admin password

    • Netbox admin password

    • Netbox postgres password

    • Netbox redis password

    • Netbox redis cache password

    • Vault Initial Root Token

    • Vault Unseal Key 1

    • Root CA Certificate

    Осторожно

    Реквизиты будут показаны только один раз. После закрытия или очищения терминала реквизиты доступа будут безвозвратно удалены.

  10. Добавьте корневой сертификат (значение параметра Root CA Certificate) в формате Base64 ASCII в ваши доверенные корневые центры сертификации для корректной работы веб-интерфейсов платформы.

Настройка собственного корневого сертификата

Инсталлятор генерирует собственные сертификаты платформы с помощью openssl:

  1. Создает корневой CA (центр сертификации): корневой сертификат и приватный ключ. Срок действия — 10 лет.

  2. Создает wildcard-сертификат и приватный ключ для сервисов GitLab, Nexus, Vault, NetBox и делает их доверенными этому CA. Также создается цепочка сертификатов вида chain-cert.pem для сервисов. Срок действия — 2 года.

  3. Создает в Vault репозиторий installer для хранения сертификатов и создает в нем CA на основе корневого CA. Срок действия — 2 года.

  4. Создает роль, с помощью которой можно выписывать сертификаты на основе запросов пользователей.

Важно

Все пароли и сертификаты платформы должны храниться в сервисе Vault.

Для того чтобы использовать собственные сертификаты, выполните следующие действия:

  1. Подготовьте цепочку сертификатов для своего Nexus в файле nexus.itkey.com.pem.

  2. Откройте веб-интерфейс развернутого Vault (vault.cloud.itkey.com).

  3. Авторизуйтесь с помощью реквизитов для Vault, полученных на этапе установки дистрибутива KeyStack.

  4. Откройте на редактирование файл secret_v2 / deployments / <LCM FQDN> / secrets / accounts / ca.crt и дополните его корневым и промежуточным CA-сертификатами своего Nexus.

Настройка ролевой модели в GitLab и NetBox

Примечание

Для настройки ролевой модели необходимо включить интеграцию с каталогами LDAP на этапе установки LCM (опция auth LDAP for Gitlab and Netbox).

Настройка ролевой модели в NetBox

  1. После инсталляции зайдите в веб-интерфейс NetBox одним пользователем из каждой сопоставленной группы LDAP. При этом действии каждая группа будет зарегистрирована в NetBox.

  2. Зайдите пользователем с ролью admin.

  3. Перейдите в раздел Администратор > Аутентификация > Группы.

  4. Отредактируйте группы и выставите им разрешения:

    1. Для групп с ролью security_auditor и reader укажите разрешение perm_ro.

    2. Для групп с ролью admin укажите разрешение perm_rw.

  5. Перенесите административные привилегии со встроенной учётной записи администратора NetBox на учетную запись администратора из каталога LDAP:

    1. Войдите в NetBox административным пользователем с ролью admin из каталога LDAP.

    2. Перейдите в раздел Администратор > Аутентификация > Пользователи.

    3. Откройте редактирование пользователя admin.

    4. Снимите с пользователя admin статусы Статус персонала и Статус суперпользователя.

    5. Перейдите в раздел Администратор > Аутентификация > Токены API.

    6. Удалите все токены, принадлежащие встроенному пользователю admin.

    7. Добавьте новый токен:

      1. Нажмите Добавить.

      2. Выберите текущего пользователя.

      3. Отметьте галочкой Запись включена.

    8. Скопируйте сгенерированный токен.

    9. Откройте веб-интерфейс сервиса Vault.

    10. Перейдите в директорию secret_v2 / deployments / <LCM FQDN> / secrets / accounts.

    11. Нажмите Create new для создания новой версии секрета.

    12. Замените значение NETBOX_TOKEN на скопированное.

Настройка ролевой модели в GitLab

  1. После инсталляции зайдите веб-интерфейс GitLab по адресу https://ks-lcm.cloud.itkey.com.

  2. Выберите вариант входа Standard и авторизуйтесь пользователем root.

  3. Перейдите в репозиторий project_k / services / gitlab-ldap-sync, откройте на редактирование файл gitlab-ldap-sync.conf:

    • В секции [gitlab] в строке groups= укажите названия ваших сопоставляемых LDAP-групп. Отредактируйте значения ключа ldap: для каждой группы. В строке maintenance_ldap_group укажите название LDAP-группы, которая сопоставляется с ролью admin. Руководствуйтесь назначением сопоставляемых групп, указанным в Описании ролевой модели.

    • В секции [ldap] в строке user_filter= укажите название LDAP-групп.

  4. Запустите пайплайн по умолчанию для первичной синхронизации пользователей из вашего сервиса LDAP. При запуске пайплайна убедитесь, что в переменной KEYSTACK_RELEASE указано актуальное значение релиза.

  5. В репозитории project_k / services / gitlab-ldap-sync в разделе Build > Pipeline schedules настройте периодичность запуска пайплайна.

Проверка настройки

  1. Войдите в веб-интерфейс NetBox и GitLab пользователями с разными ролями. При аутентификации выбирайте вариант входа LDAP. Вход должен быть успешным, доступные элементы соответствовать роли пользователя.