Установка через Installer#

В данном варианте установка дистрибутива производится автоматизированным способом через компонент Deploy tools (CDJE) продукта Platform V DevOps Tools (DOT) (или Installer).

Пререквизиты#

Перед установкой IDMX необходимо установить все обязательные и выбранные опциональные зависимости из списка ПО в разделе Системные требования. Установка и настройка ПО производится согласно документации на эти продукты.

Поддерживаемой системой приложений-контейнеров является Kubernetes (использование OpenShift — опционально), в инструкциях по настройке в именах переменных и параметрах системы могут встречаться названия систем контейнеризации, которые одинаковы и применимы для обоих сред контейнеризации.

Сборка образов IDMX#

Перед установкой необходимо собрать Docker-образы всех модулей IDMX и поместить их в Registry. Сборка образов производится из компонентов дистрибутива IDMX при помощи инструментов продукта Platform V DevOps Tools (рекомендовано) либо инструментами Docker (опционально) согласно стандартной инструкции использования этих инструментов.

Убедитесь, что базовый образ, на основе которого собираются Docker-образы IDMX, содержит все нужное системное ПО:

  • ОС (рекомендуется ОС Альт 8 СП);

  • Java-машина (рекомендуется OpenJDK);

  • Утилита для распаковки zip-архивов (рекомендуется UnZip).

Требуемые версии системного ПО смотрите в разделе Системные требования.

Подготовка системной БД#

Подготовку системной БД можно сделать одним из двух способов: вручную или автоматически при помощи Liquibase скриптов.

Подготовка системной БД вручную#

Перед запуском установки IDMX также необходимо установить и настроить СУБД, которая будет использоваться для управления системной БД IDMX. Установка производится согласно документации на выбранную СУБД (Platform V Pangolin SE или PostgreSQL). Для подготовки системной БД IDMX:

  1. Войдите в СУБД под пользователем postgres и выполните следующие команды:

    • Создание пользователя:

      CREATE USER idm_user WITH PASSWORD 'password' LOGIN NOSUPERUSER NOCREATEDB NOCREATEROLE;

      , где password — пароль, сформированный с учетом рекомендаций по заданию стойких паролей (смотрите раздел Доступ к приложению Руководства оператора).

    • Создание БД:

      CREATE DATABASE idm_db WITH OWNER = idm_user ENCODING = 'UTF8' TABLESPACE = pg_default LC_COLLATE = 'en_US.UTF-8' LC_CTYPE = 'en_US.UTF-8' CONNECTION LIMIT = -1;

    Отдельный пользователь idm_user создается для того, чтобы IDMX мог корректно взаимодействовать с системной БД.

    При создании БД задаются параметры, при которых IDMX сможет корректно записывать и извлекать данные из таблиц.

    Подробнее о работе с пользователями и БД смотрите в документации на используемую СУБД (Platform V Pangolin SE или Postgres).

  2. Выйдите из УЗ postgres и войдите под созданным пользователем idm_user. Затем выполните для БД idm_db три скрипта подготовки БД в следующей последовательности:

    1. postgres-new.sql

    2. postgres-new-audit.sql

    3. postgres-new-quartz.sql

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

Скрипты подготовки БД находятся в дистрибутиве с бинарными артефактами в директории <distrib>/bh/idmx-db-init-<версия>-distrib.zip/sql/.

Подготовка БД вручную при отсутствии прав OWNER#

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

  1. Войдите в СУБД под пользователем postgres и выполните следующие команды:

    • Создание пользователя:

      CREATE USER idm_user WITH PASSWORD 'password' LOGIN NOSUPERUSER NOCREATEDB NOCREATEROLE;

      , где password — пароль, сформированный с учетом рекомендаций по заданию стойких паролей (смотрите раздел Доступ к приложению Руководства оператора).

    • Создание БД:

      CREATE DATABASE idm_db WITH OWNER = idm_user ENCODING = 'UTF8' TABLESPACE = pg_default LC_COLLATE = 'en_US.UTF-8' LC_CTYPE = 'en_US.UTF-8' CONNECTION LIMIT = -1;

    • Данный пункт может быть выполнен администраторами БД с необходимыми правами.

    Отдельный пользователь idm_user создается для того, чтобы IDMX мог корректно взаимодействовать с системной БД.

    При создании БД задаются параметры, при которых IDMX сможет корректно записывать и извлекать данные из таблиц.

    Подробнее о работе с пользователями и БД смотрите в документации на используемую СУБД (Platform V Pangolin SE или Postgres).

    В случае если у владельцев инсталляции IDMX не возможности выполнять действия по созданию БД и пользователей в СУБД (например, если требования информационной безопасности запрещают доступ к СУБД всем пользователям, кроме администраторов СУБД), данные действия следует выполнять пользователям или администраторам с соответствующими правами.

  2. Под пользователем postgres подключитесь к БД idm_db и выполните или убедитесь что данные схема и расширения есть в базе:

    CREATE SCHEMA IF NOT EXISTS idm_schema; (имя схемы может быть другим в зависимости от стенда и требований заказчика)

    CREATE EXTENSION IF NOT EXISTS intarray;

    CREATE EXTENSION IF NOT EXISTS pg_trgm;

    CREATE EXTENSION IF NOT EXISTS fuzzystrmatch;

    • Данный пункт может быть выполнен администраторами БД с необходимыми правами.

    Вышеуказанные схема и расширения необходимы для корректной записи данных IDMX в БД. При наличии прав OWNER эти команды выполняются в рамках скриптов подготовки БД. Соответственно, при отсутствии у владельцев инсталляции IDMX прав OWNER на СУБД, эти команды необходимо выполнить вручную при помощи администраторов СУБД или других пользователей с соответствующими правами.

  3. Под пользователем postgres выдайте или убедитесь что выданы необходимые права на БД:

    GRANT SELECT, INSERT, UPDATE, DELETE on ALL tables IN schema idm_schema TO idm_user;

    GRANT execute ON all FUNCTIONS in SCHEMA idm_schema TO idm_user;

    GRANT EXECUTE ON ALL PROCEDURES IN SCHEMA idm_schema TO idm_user;

    GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA idm_schema TO idm_user;

    • Данный пункт может быть выполнен администраторами БД с необходимыми правами.

    Аналогично предыдущему пункту, пользователю idm_user необходимы перечисленные права на созданную системную БД, чтобы IDMX мог корректно записывать и извлекать данные. И, так же аналогично, данные команды выполняются в рамках скриптов подготовки при наличии прав OWNER, и должны быть выполнены вручную пользователями с соответствующими правами, если права OWNER у владельцев IDMX отсутствуют.

  4. Выйдите из УЗ postgres и войдите под созданным пользователем idm_user. Затем выполните для БД idm_db три скрипта подготовки БД в следующей последовательности:

    1. postgres-new.sql

    Перед исполнением скрипта, удалите из файла строки 29, 30, 31, 32:

    CREATE SCHEMA IF NOT EXISTS …;

    CREATE EXTENSION IF NOT EXISTS intarray; -- support for indexing INTEGER[] columns

    CREATE EXTENSION IF NOT EXISTS pg_trgm; -- support for trigram indexes

    CREATE EXTENSION IF NOT EXISTS fuzzystrmatch; -- fuzzy string match (levenshtein, etc.)

    1. postgres-new-audit.sql

    Перед исполнением скрипта, удалите из файла строку 28:

    CREATE SCHEMA IF NOT EXISTS …;

    1. postgres-new-quartz.sql

    Исполните скрипт без изменений

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

    Изменения в скрипты необходимо внести из-за отсутствия у владельцев IDMX прав OWNER на СУБД. В строках, которые нужно удалить или изменить, используются команды, для выполнения которых нужны права OWNER. Соответственно, при отсутствии прав, применение скриптов будет прервано с ошибкой на этих строках.

Автоматическая настройка БД при помощи Liquibase скриптов#

Чтобы воспользоваться данной функциональностью Deploy job при установке IDMX, следует провести следующую подготовку:

  1. Создать БД (например, idm_db) и пользователя (например, idm_user) в используемой СУБД.

    Обратите внимание, пользователь должен иметь права OWNER для корректной установки!

  2. Если не используется SecMan:

    1. Если для подключения к БД не требуется mTLS:

      1. В стендозависимом конфигурационном файле common.conf.yml заполните конфигурационные параметры скриптов:

        • idmx_liquibase_repository_database_url — URL для подключения к системной БД IDMX, например: jdbc:postgresql://vm-idm-security-psql.my.domain:5432/dev_db?prepareThreshold=0;

        • idmx_liquibase_repository_database_schema— используемая схема в системной БД IDMX, например: my_idmx;

        • db_separated — будет ли использоваться функциональность хранения данных аудита в отдельной БД;

        • idmx_liquibase_repository_database_audit_url — URL для подключения к БД для хранения данных аудита, например: jdbc:postgresql://db_hostname:5432/db_name?prepareThreshold=0;

        • idmx_liquibase_repository_database_audit_schema — используемая схема в БД аудита, например: my_idmx_audit.

        • liquibase_loglevel_custom — уровень логирования при исполнении скриптов liquibase, например: INFO. Необязательный параметр.

      2. В файл _passwords.conf в репозитории конфигурации Deploy job добавьте credentials для доступа к БД:

        • idm_engine_repository_db_password= <пароль учетной записи пользователя, созданного на шаге 1>;

        • idm_engine_repository_db_username= <имя пользователя, созданного на шаге 1>.

      3. Отредактируйте environment.json:

        • "useSecretManagerForPipelineCreds": "false",
          "useSecretManagerForSecretFiles": "false"

      4. В файле common.conf.yml добавьте значение параметра idmx.liquibase.repository.database.schema: idm_schema.

    2. Если для подключения к БД требуется mTLS (смотрите раздел Защита соединения с БД по SSL и типы Service Mesh):

      1. В стендозависимом конфигурационном файле common.conf.yml заполните конфигурационные параметры скриптов:

        • idmx_liquibase_repository_database_url — URL для подключения к системной БД IDMX, например: jdbc:postgresql://vm-idm-security-psql.my.domain:5432/dev_db?prepareThreshold=0&ssl=true&sslmode=require&sslfactory=org.postgresql.ssl.DefaultJavaSSLFactory";

        • idmx_liquibase_repository_database_schema— используемая схема в системной БД IDMX, например: my_idmx;

        • db_separated — будет ли использоваться функциональность хранения данных аудита в отдельной БД;

        • idmx_liquibase_repository_database_audit_url — URL для подключения к БД для хранения данных аудита, например: jdbc:postgresql://db_hostname:5432/db_name?prepareThreshold=0&ssl=true&sslmode=require&sslfactory=org.postgresql.ssl.DefaultJavaSSLFactory";

        • idmx_liquibase_repository_database_audit_schema — используемая схема в БД аудита, например: my_idmx_audit.

        • liquibase_loglevel_custom — уровень логирования при исполнении скриптов liquibase, например: INFO. Необязательный параметр.

      2. Поместите сертификаты, необходимые для подключения к системной БД, в JKS хранилище сертификатов:

        1. Создайте хранилище из сертификатов:

          openssl pkcs12 -export -in СЕРТИФИКАТ.crt -inkey КЛЮЧ.key -out НАЗВАНИЕ_ХРАНИЛИЩА.p12 -name liquibase. Например, openssl pkcs12 -export -in idmx-dev-new-repo_client.crt -inkey idmx-dev-new-repo_client.key -out keystore.p12 -name liquibase_keystore.

        2. Конвертируйте хранилище в требуемый формат JKS:

          keytool -importkeystore -srckeystore СОЗДАННОЕ_РАНЕЕ_ХРАНИЛИЩЕ.p12 -srcstoretype pkcs12 -destkeystore КОНЕЧНОЕ_ХРАНИЛИЩЕ.jks-deststoretype JKS. Например, keytool -importkeystore -srckeystore keystore.p12 -srcstoretype pkcs12 -destkeystore KeyStore.jks -deststoretype JKS.

        3. Добавьте ЦА сертификат в JKS хранилище:

          keytool -import -trustcacerts -keystore KeyStore.jks -storepass пароль_который_был_указан_при_создании -alias yourAliasName -file path\to\my_CA.crt. Например, keytool -import -trustcacerts -keystore key1111.jks -storepass test123 -alias sbt_ca -file CERTIFICATES/my_CA.crt

      3. Поместите полученное JKS хранилище в common репозиторий по пути ansible/files/ssl/KeyStore.jks.

      4. В файл ssl.conf добавьте следующие параметры:

        • ssl.jdbc.KeyStoreFromFile=ansible/files/ssl/KeyStore.jks;

        • ssl.jdbc.TrustStoreFromFile=ansible/files/ssl/KeyStore.jks.

      5. В _passwords.conf добавьте пароли от JKS хранилища:

        • ssl.jdbc.keyStorePassword=password;

        • ssl.jdbc.trustStorePassword=password.

      6. Выполните действия в пунктах 2-5 для сертификатов, необходимых для подключения к БД аудита, в случае если используется функциональность раздельного хранения данных аудита.

      7. В файле custom_property.conf.yml в стендозависимой директории /conf/helm/application/ репозитория конфигурации добавьте значение параметра idmx.liquibase.repository.database.schema: idm_schema.

  3. Если используется SecMan:

    1. Если для подключения к БД не требуется mTLS:

      1. В стендозависимом конфигурационном файле common.conf.yml заполните конфигурационные параметры скриптов:

        • idmx_liquibase_repository_database_url — URL для подключения к системной БД IDMX, например: jdbc:postgresql://vm-idm-security-psql.my.domain:5432/dev_db?prepareThreshold=0;

        • idmx_liquibase_repository_database_schema— используемая схема в системной БД IDMX, например: my_idmx;

        • db_separated — будет ли использоваться функциональность хранения данных аудита в отдельной БД;

        • idmx_liquibase_repository_database_audit_url — URL для подключения к БД для хранения данных аудита, например: jdbc:postgresql://db_hostname:5432/db_name?prepareThreshold=0;

        • idmx_liquibase_repository_database_audit_schema — используемая схема в БД аудита, например: my_idmx_audit.

        • liquibase_loglevel_custom — уровень логирования при исполнении скриптов liquibase, например: INFO.

      2. Поместите в SecMan по пути <НУЖНОЕ>/<ПРОСТРАНСТВО>/<В>/<SECMAN>/passwords_conf два секрета (значения не в base64):

      • "idm_engine_repository_db_password": "<пароль учетной записи пользователя, созданного на шаге 1>";

      • "idm_engine_repository_db_username": "<имя пользователя, созданного на шаге 1>".

      1. Отредактируйте стендозависимый файл environment.json:

      • "useSecretManagerForPipelineCreds": "fail",
        "useSecretManagerForSecretFiles": "fail";

      1. В стендозависимом файле _global.hashicorp.conf заполните параметры для доступа к инсталляции Secret Management System:

        • global.hashicorp.hashiCorpTimeout — таймаут подключения к SecMan;

        • global.hashicorp.opsHashiCorpCred — имя credentials для доступа к SecMan;

        • global.hashicorp.opsHashiCorpNamespace — namespace, в котором расположен SecMan;

        • global.hashicorp.hashiCorpUrl — URL экземпляра SecMan;

        • global.hashicorp.hashiCorpUrlForSlave — URL для Jenkins Job для SecMan;

        • global.hashicorp.opsPath — путь до пространства с секретами из пункта 2.

      2. Чтобы получать секреты из vault во время исполнения скриптов, можно воспользоваться следующей конструкцией:

        {% set cred_id = lookup('custom_vars','global.hashicorp.opsHashiCorpCred') %}
{% set namespace_id = lookup('custom_vars','global.hashicorp.opsHashiCorpNamespace') %}

{% for secret_entry in lookup('community.hashi_vault.hashi_vault_list', lookup('custom_vars', 'global.hashicorp.opsPath'),namespace=namespace_id, token=lookup('custom_vars', cred_id)).split(',') %}
{% set results=lookup('community.hashi_vault.hashi_vault', 'secret=' + lookup('custom_vars', 'global.hashicorp.opsPath') + secret_entry, namespace=namespace_id, token=lookup('custom_vars', cred_id)) %}
{% for key, value in results.items() %}
{{ key }}={{ value }}
{% endfor %}
{% endfor %}

      3. В файле common.conf.yml добавьте значение параметра idmx.liquibase.repository.database.schema: idm_schema.

    2. Если для подключения к БД требуется mTLS (смотрите раздел Защита соединения с БД по SSL и типы Service Mesh):

      1. В стендозависимом конфигурационном файле common.conf.yml заполните конфигурационные параметры скриптов:

        • idmx_liquibase_repository_database_url — URL для подключения к системной БД IDMX, например: jdbc:postgresql://vm-idm-security-psql.my.domain:5432/dev_db?prepareThreshold=0&ssl=true&sslmode=require&sslfactory=org.postgresql.ssl.DefaultJavaSSLFactory";

        • idmx_liquibase_repository_database_schema— используемая схема в системной БД IDMX, например: my_idmx;

        • db_separated — будет ли использоваться функциональность хранения данных аудита в отдельной БД;

        • idmx_liquibase_repository_database_audit_url — URL для подключения к БД для хранения данных аудита, например: jdbc:postgresql://db_hostname:5432/db_name?prepareThreshold=0&ssl=true&sslmode=require&sslfactory=org.postgresql.ssl.DefaultJavaSSLFactory";

        • idmx_liquibase_repository_database_audit_schema — используемая схема в БД аудита, например: my_idmx_audit.

        • liquibase_loglevel_custom — уровень логирования при исполнении скриптов liquibase, например: INFO.

      2. Поместите сертификаты, необходимые для подключения к БД, в JKS хранилище сертификатов:

        1. Создайте хранилище из сертификатов:

          openssl pkcs12 -export -in СЕРТИФИКАТ.crt -inkey КЛЮЧ.key -out НАЗВАНИЕ_ХРАНИЛИЩА.p12 -name liquibase. Например, openssl pkcs12 -export -in idmx-dev-new-repo_client.crt -inkey idmx-dev-new-repo_client.key -out keystore.p12 -name liquibase_keystore.

        2. Конвертируйте хранилище в требуемый формат JKS:

          keytool -importkeystore -srckeystore СОЗДАННОЕ_РАНЕЕ_ХРАНИЛИЩЕ.p12 -srcstoretype pkcs12 -destkeystore КОНЕЧНОЕ_ХРАНИЛИЩЕ.jks-deststoretype JKS. Например, keytool -importkeystore -srckeystore keystore.p12 -srcstoretype pkcs12 -destkeystore KeyStore.jks -deststoretype JKS.

        3. Добавьте ЦА сертификат в JKS хранилище:

          keytool -import -trustcacerts -keystore KeyStore.jks -storepass пароль_который_был_указан_при_создании -alias yourAliasName -file path\to\my_CA.crt. Например, keytool -import -trustcacerts -keystore key1111.jks -storepass test123 -alias sbt_ca -file CERTIFICATES/my_CA.crt

      3. Поместите полученное JKS хранилище в SecMan в по пути <НУЖНОЕ>/<ПРОСТРАНСТВО>/<В>/<SECMAN>/jdbc_keystore.jks (значение в base64):

        "secretFileBase64": "Полученное JKS хранилище, закодированное как строка формата base64"

      4. В SecMan в по пути <НУЖНОЕ>/<ПРОСТРАНСТВО>/<В>/<SECMAN>/ssl.jdbc.keyStorePassword добавьте пароль от JKS хранилища ключей (значение не в base64):

        "ssl.jdbc.keyStorePassword": "пароль"

      5. В SecMan в по пути <НУЖНОЕ>/<ПРОСТРАНСТВО>/<В>/<SECMAN>/ssl.jdbc.trustStorePassword добавьте пароль от доверенного JKS хранилища (truststore) (значение не в base64):

        "ssl.jdbc.trustStorePassword": "пароль"

      6. Выполните действия в пунктах 2-5 для сертификатов, необходимых для подключения к БД аудита, в случае если используется функциональность раздельного хранения данных аудита.

      7. Отредактируйте стендозависимый файл environment.json:

        • "useSecretManagerForPipelineCreds": "fail",
          "useSecretManagerForSecretFiles": "fail";

      8. В стендозависимом файле _global.hashicorp.conf заполните параметры для доступа к инсталляции Secret Management System:

        • global.hashicorp.hashiCorpTimeout — таймаут подключения к SecMan;

        • global.hashicorp.opsHashiCorpCred — имя credentials для доступа к SecMan;

        • global.hashicorp.opsHashiCorpNamespace — namespace, в котором расположен SecMan;

        • global.hashicorp.hashiCorpUrl — URL экземпляра SecMan;

        • global.hashicorp.hashiCorpUrlForSlave — URL для Jenkins Job для SecMan;

        • global.hashicorp.opsPath — путь до пространства с секретами из пунктов 3-5.

      9. Чтобы получать секреты из vault во время исполнения скриптов, можно воспользоваться следующей конструкцией:

        {% set cred_id = lookup('custom_vars','global.hashicorp.opsHashiCorpCred') %}
{% set namespace_id = lookup('custom_vars','global.hashicorp.opsHashiCorpNamespace') %}

{% for secret_entry in lookup('community.hashi_vault.hashi_vault_list', lookup('custom_vars', 'global.hashicorp.opsPath'),namespace=namespace_id, token=lookup('custom_vars', cred_id)).split(',') %}
{% set results=lookup('community.hashi_vault.hashi_vault', 'secret=' + lookup('custom_vars', 'global.hashicorp.opsPath') + secret_entry, namespace=namespace_id, token=lookup('custom_vars', cred_id)) %}
{% for key, value in results.items() %}
{{ key }}={{ value }}
{% endfor %}
{% endfor %}

      10. Чтобы получать сертификаты из vault во время исполнения скриптов, можно воспользоваться следующей конструкцией:

        {% set cred_id = lookup('custom_vars','global.hashicorp.opsHashiCorpCred') %}
{% set namespace_id = lookup('custom_vars','global.hashicorp.opsHashiCorpNamespace') %}
{% set content = lookup('community.hashi_vault.hashi_vault', lookup('custom_vars', 'global.hashicorp.opsPath') + 'liquibase.jks',namespace=namespace_id, token=lookup('custom_vars', cred_id)).secretFileBase64 | b64decode | b64encode %}
ssl.jdbc.KeyStoreFromFile={{ lookup('pipe', 'echo ' + content  + ' | base64 -d > ' + 'liquibase.jks' + '; pwd') + '/' + 'liquibase.jks' }}
ssl.jdbc.TrustStoreFromFile={{ lookup('pipe', 'echo ' + content  + ' | base64 -d > ' + 'liquibase.jks' + '; pwd') + '/' + 'liquibase.jks' }}

      11. В файле custom_property.conf.yml в стендозависимой директории /conf/helm/application/ репозитория конфигурации добавьте значение параметра idmx.liquibase.repository.database.schema: idm_schema.

Настройка раздельного хранения данных аудита#

При высокой нагрузке на IDMX и большом количестве выполняемых операций данные аудита могут требовать большого количества памяти для хранения. Чтобы снизить нагрузку и требования к дисковому пространству для системной БД, IDMX предоставляет возможность хранить данные аудита в отдельной БД.

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

Чтобы перейти на использование раздельного хранения данных аудита следует:

  1. Остановить idmx-engine в namespace IDMX.

  2. Создать и настроить новую БД:

    1. Создать пользователя.

    2. Создать схему (если треубется использовать не public).

    3. Установить схему для пользователя (ALTER ROLE <username> SET search_path TO <schema>;).

  3. Перенести данные аудита из системной БД IDMX в новую БД. Для этого:

    1. Получить и распаковать архив со скриптами переноса данных. Архив содержит в себе:

      • main.sh — скрипт переноса данных;

      • env.properties — файл со свойствами, которые нужно заполнить;

      • deleteAuditTables.sql — SQL скрипт удаления таблиц из старой базы;

      • audit-4.7.sql — SQL скрипт создания таблиц аудита в новой базе.

    2. Заполнить значения переменных среды в файле env.properties:

      • SOURCE_DB_HOST — хост исходной БД (т.е. основной системной БД IDMX, из которой будут забираться данные аудита для переноса);

      • SOURCE_DB_PORT — порт исходной БД;

      • SOURCE_DB_NAME — название исходной БД;

      • SOURCE_DB_USERNAME — пользователь исходной БД;

      • SOURCE_DB_SCHEMA — схема в исходной БД;

      • TARGET_DB_HOST — хост целевой БД (т.е. БД, созданной на шаге 2, которая будет использоваться для хранения данных аудита);

      • TARGET_DB_PORT — порт целевой БД;

      • TARGET_DB_NAME — название целевой БД;

      • TARGET_DB_USERNAME — пользователь целевой БД;

      • TARGET_DB_SCHEMA — схема в целевой БД;

      • AUDIT_CREATE_SQL_FILE — путь до скрипта создания таблиц аудита;

      • RESUME_FROM_STEP — шаг скрипта, с которого нужно начать (шаги описаны ниже). При повторном запуске скрипта, он начнет работу с указанного шага. Используется для перезапуска скрипта в случае возникновения ошибок в ходе работы.

      Пароли для доступа к БД потребуется ввести в окне терминала во время выполнения скрипта main.sh.

    3. Запустить на выполнение скрипт main.sh. Скрипт выполнит следующие шаги:

      1. Создание полного backup базы (на случай непредвиденных ситуаций).

      2. Dump таблиц аудита для переноса данных в новую базу.

      3. Создание таблиц аудита в новой базе.

      4. Загрузка данных аудита в новую базу.

      5. Удаление таблиц аудита из старой базы (с подтверждением).

    Обратите внимание, архивы с dump БД не удаляются и не перезаписываются, чтобы предотвратить непреднамеренную потерю данных.

  4. В стендозависмых параметрах стенда в файле values.yaml заполнить значения следующих параметров:

    • repository.database.separated: true;

    • repository.database.differentHost: true;

    • repository.database.audit.mtls: true;

    • repository.database.audit.url: — данный параметр следует заполнять в зависимости от используемого типа Service Mesh.

      В случае использования RHSM: jdbc:postgresql://db-hostname:127.0.0.1:5432/db-name?prepareThreshold=0&ssl=true&sslmode=verify-full&sslcert=/vault/secrets/postgres-audit/postgres_audit_cert&sslkey=/vault/secrets/postgres-audit/postgres_audit_pk8&sslrootcert=/vault/secrets/postgres-audit/postgres_audit_ca

      В случае использования Synapse Service Mesh: jdbc:postgresql://db-hostname:127.0.0.1:5432/db-name?prepareThreshold=0&sslmode=disable

  5. Добавить секреты в систему хранения секретов (vault/Secret Management System или Kubernetes Secrets):

    • idm_engine_repository_db_audit_username — имя пользователя для доступа IDMX к БД аудита;

    • idm_engine_repository_db_audit_password — пароль для доступа IDMX к БД аудита;

    • postgres_audit_cert — сертификат для mTLS к БД аудита;

    • postgres_audit_pk8 (rhsm) или postgres_audit_key (synapse) — ключ для mTLS к БД аудита;

    • postgres_audit_ca — сертификат CA для mTLS к БД аудита.

  6. Задеплоить idmx-engine с новыми параметрами.

Данная инструкция также применима, если в пункте 6 будет происходить обновление IDMX с версии 1.0/1.1/1.2 на 1.4.

Также обратите внимание на раздел Работа с записями аудита

Настройка Secret Management System#

Secret Management System следует настраивать согласно документации на этот продукт. После установки и настройки Secret Management System следует провести его подготовку для использования с IDMX следующим образом:

  1. Завести хранилище KV (key-value). Хранилище должно быть типа "KV хранилище".

    Тип: "kv" — версия 1 движка Key-Value, соответствует пути KV.

    Пример пути: ACC/IDMX/FH/KV.

  2. Получить роль, тенант (namespace).

  3. Дать доступ роли из namespace контейнеризированной среды в Secret Management.

  4. Загрузить секреты и сертификаты в Secret Management по пути из пункта 1 в подпапку KEYSTORE (значения в кодировке Base64). Итоговый путь к расположению сертификатов в Secret Management System будет выглядеть, например, так: ACC/IDMX/FH/KV/KEYSTORE.

    Подробнее о кодировании в base64 и загрузке секретов и сертификатов будет рассказано в инструкции в разделе Установка.

Настройка логирования#

IDMX помимо ведения логирования собственными средствами, предоставляет возможность отправки записей журнала событий в несколько внешних систем. Для интеграции с ними следует:

  1. Выбрать один или несколько сервисов, в которые будут отправляться сообщения: Kafka (например, оттуда забирает сообщения компонент LOGA продукта Platform V Monitor) или Loki.

  2. Заполнить соответствующие атрибуты раздела fluent корневого конфигурационного файла (смотроите раздел Миграция конфигурационных файлов) корректными значениями.

  3. При использовании mTLS для защиты соединений, получите сертификаты для защищенного подключения: logger_kafka для отправки сообщений в Platform V Monitor (или другой сервис, использующий брокеры Kafka), или logger_loki для отправки сообщений в Loki соответственно. Подробнее смотрите пункт 10 раздела Установка IDMX.

Установка IDMX#

Установка IDMX включает в себя установку основных модулей развертывания (idmx-engine, idmx-ui и idmx-connector-server). Установка всех модулей производится посредством компонента Deploy tools (CDJE) продукта Platform V DevOps Tools (DOT).

При установке используется типовая инструкция для работы компонента Deploy tools (CDJE). Более подробную информацию можно найти в документации на компонент Deploy tools (CDJE), документ Руководство для операторов. Ниже приведена краткая инструкция:

  1. В веб-интерфейсе компонента Deploy tools (CDJE) нажмите кнопку Собрать с параметрами.

  2. На открывшейся странице с параметрами для сборки выберите:

    • DISTRIB_VERSION;

    • Выбрать OSE_CLUSTERS;

    • Выбрать версию платформы;

    • Выбрать сценарии запуска: MIGRATION_FP_CONF;

  3. Нажмите кнопку Cобрать.

  4. Проверьте и настройте конфигурационные файлы и файл паролей в репозитории с конфигурацией IDMX для компонента Deploy tools (CDJE) в соответствии с данными из подраздела Миграция конфигурационных файлов.

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

      1. Заполнить конфигурационные параметры для подключения к системной БД в values.yaml:

        • global.repository.database.url = например, jdbc:postgresql://pangolin.db.mycorp.ru:5432/idmx-1?prepareThreshold=0;

      2. Указать лимиты памяти, выделяемые Java-машине контейнера IDMX в values.yaml:

      3. Если планируется использовать кластерный режим IDMX — включить флаг и задать максимальное количество контейнеров в values.yaml:

      4. Указать путь к пространству с образами IDMX в Docker Registry. Для этого в файле values.yaml задайте значения следующих переменных:

        • global.registry: <имя хоста>, например registry.myserver.ru;

        • global.registryPath: <относительный путь до пространства с образами>, например /infra/idm.

      5. Если используется сервис Secret Management System — необходимо заполнить конфигурационные параметры в values.yaml:

        • global.secman.enabled = true;

        • global.secman.mountPath = например, auth/kubernetes;

        • global.secman.namespace = путь до namespace SecMan, например, DEV_IDMX;

        • global.secman.role = например, role-secman-idmx;

        • global.secman.url = URL SecMan, например, https://secman-hostname:443;

        • global.secman.key = например, A/DEV/IDMX/KV/DEV.

    Обратите внимание!

    Значение параметра global.repository.database.url (файл values.yaml) задается по следующему шаблону: jdbc:postgresql://<DB_HOST>:<DB_IP>:<DB_EXTERNAL_PORT>/<DB-NAME>?<VARIABLES>

    , где:

    • <DB_HOST> — FQDN узла, на котором расположена системная БД IDMX (обязательно для работы с istio);

    • <DB_IP> — IP-адрес узла (обязательно для работы с istio);

    • <DB_EXTERNAL_PORT> — порт внешнего узла (сервера с системной БД);

    • <DB-NAME> — имя системной БД на указанном сервере. Например, idmx-1;

    • <VARIABLES> — переменные для подключения JDBC. Например, prepareThreshold=0.

    Например, jdbc:postgresql://db-hostname:127.0.0.1:5432/idmx-1?prepareThreshold=0.

    Обратите внимение!

    В параметре global.repository.database.url (файл values.yaml) задается URL для доступа к системной БД IDMX. URL должен быть с указанием протокола JDBC, и, если для защиты подключения используется SSL — в URL должны быть указаны параметры и сертификаты для защиты подключения. Например:

    Без SSL: jdbc:postgresql://pangolin.db.mycorp.ru:5432/idmx-1?prepareThreshold=0

    С SSL: jdbc:postgresql://pangolin.db.mycorp.ru:5432/idmx-1?prepareThreshold=0&ssl=true&sslmode=verify-full&sslcert=/vault/secrets/postgres/postgres_cert&sslkey=/vault/secrets/postgres/postgres_pk8&sslrootcert=/vault/secrets/postgres/postgres_ca

    Если не требуется устанавливать Istio - в файле values.yaml параметр global.istio.enabled должен быть выставлен в значение false, остальные параметры при этом игнорируются и не требуют переопределения.

  5. Создайте хранилище ключей IDMX с ключом шифрования следующей командой:

    keytool -genseckey -alias default -keystore idmx-keystore.jceks -storetype jceks -storepass changeit -keyalg AES -keysize 256 -keypass midpoint

    , где changeit — пароль, сформированный с учетом рекомендаций по заданию стойких паролей (смотрите раздел Доступ к приложению Руководства оператора).

    Обратите внимание

    Пароль от хранилища (в данном примере — changeit) необходимо в дальнейшем указать в переменной idm_engine_keystore_password (в vault Secret Management System, либо в файле _passwords.conf). Подробнее смотрите далее в инструкции.

    Генерируемый ключ в данном случае имеет alias default, и всегда должен иметь пароль midpoint. Подробнее о ключе шифрования и работе с ним смотрите в разделе Ключ шифрования IDM.

  6. Добавьте в систему хранения секретов пароли, используемые IDMX для доступа к различным системам:

    • Если используется механизм компонента Deploy tools (CDJE) (Kubernetes Secrets):

      В common репозитории в файл _passwords.conf добавьте следующие секреты:

      • idm_engine_keystore_password — Пароль от хранилища ключей IDMX. Обязательно;

      • idm_engine_keystore_key_password — Пароль для сертификатов IDMX. Должен иметь значение midpoint. Обязательно;

      • idm_engine_repository_db_password — Пароль для подключения к системной БД IDMX (пароль от учетной записи idm_user, созданной на этапе подготовки БД). Обязательно.

      • idm_engine_repository_db_username — Имя пользователя, под которым IDMX будет подключаться к системной БД. Обязательно.

      • idm_engine_repository_db_audit_password — Пароль для подключения к выделенной БД аудита IDMX (). Необязательно.

      • idm_engine_repository_db_audit_username — Имя пользователя, под которым IDMX будет подключаться к выделенной БД аудита. Необязательно.

    • Если используется Secret Management System:

      В vault, в подпапку KEYSTORE (подробнее смотрите в пункте Настройка Secret Management System), добавьте следующие секреты, зашифрованные в base64:

      • idm_engine_keystore_password — Пароль от хранилища ключей IDMX. Обязательно;

      • idm_engine_keystore_key_password — Пароль для сертификатов IDMX. Должен иметь значение midpoint, зашифрованное в base64. Обязательно;

      • idm_engine_repository_db_password — Пароль для подключения к системной БД IDMX (пароль от учетной записи idm_user, созданной на этапе подготовки БД). Обязательно.

      • idm_engine_repository_db_username — Имя пользователя, под которым IDMX будет подключаться к системной БД. Обязательно.

      • idm_engine_repository_db_audit_password — Пароль для подключения к выделенной БД аудита IDMX (). Необязательно.

      • idm_engine_repository_db_audit_username — Имя пользователя, под которым IDMX будет подключаться к выделенной БД аудита. Необязательно.

      Для шифрования секретов в base64 можно воспользоваться любым подходящим инструментом, например, утилитой base64. Для шифрования секретов выполните в терминале или командной строке следующую команду:

      echo '<pass>' | base64, где <pass> — шифруемый пароль.

      Утилита вернет в терминале строку, которая и будет зашифрованным в base64 секретом. Эту строку затем необходимо вставить в поле Значение (value) при создании переменной в vault Secret Management System.

  7. Добавьте в систему хранения секретов хранилище ключей IDMX, созданное на шаге 5:

    • Если используется механизм компонента Deploy tools (CDJE) (Kubernetes Secrets):

      Поместите хранилище ключей IDMX (idmx-keystore.jceks) в common репозиторий в директорию idm_common_dev/<директория стенда>/ansible/files/ssl/.

    • Если используется Secret Management System:

      Зашифруйте в base64 и положите в хранилище (vault) хранилище ключей IDMX (idmx-keystore.jceks). Для этого:

      • Зашифруйте файл хранилища ключей IDMX idmx-keystore.jceks в base64 любым подходящим инструментом. Например, можно воспользоваться утилитой командной строки base64:

        base64 idmx-keystore.jceks

      • Утилита вернет в терминале строку, которая и будет зашифрованным в base64 хранилищем ключей IDMX.

      • Создайте в пространстве IDMX Secret Management System переменную с именем keystore, и вставьте полученную строку в поле Значение (value).

  8. Опционально — выпустите сертификаты для защиты подключения IDMX к системной БД IDMX через mTLS 1.2 и настройте защиту в зависимости от используемого Service Mesh. Подробнее смотрите в разделе Защита соединения с БД по SSL и типы Service Mesh.

  9. Опционально — выпустите сертификаты для интеграции IDMX с компонентом AUTH продукта Platform V IAM SE. Для этого:

    1. Получите у администраторов инсталляции компонента AUTH CA сертификат, которым подписаны сертификаты, используемые самим AUTH.

    2. Выпустите сертификат и ключ Istio Ingress для компонентов IDMX. Сертификаты должны иметь CN и/или SAN, равные Route контейнера соответствующего компонента в Kubernetes/Openshift:

      • istio_ingress_engine_cert и istio_ingress_engine_key для idmx-engine;

      • istio_ingress_ui_cert и istio_ingress_ui_key для idmx-ui.

      • istio_ingress_ssp_cert и istio_ingress_ssp_key для idmx-ssp.

      Обратите внимание, CA, которым подписываются выпускаемые сертификаты и ключи, должен быть в списке доверенных CA у компонента AUTH.

    3. Скопируйте полученный на подпункте 1 CA сертификат и переименуйте его для использования с компонентами IDMX:

      • istio_ingress_engine_ca для idmx-engine;

      • istio_ingress_ui_ca для idmx-ui.

      • istio_ingress_ssp_ca для idmx-ssp.

  10. Добавьте в систему хранения секретов сертификаты для защиты через SSL доступа IDMX к платформенным интеграциям и другим ресурсам. Данный шаг необязателен, сертификаты следует добавлять только в случае использования соответствующих интеграций и использования SSL для защиты подключения к ним.

    • Если используется механизм компонента Deploy tools (CDJE) (Kubernetes Secrets):

      Все сертификаты должны быть помещены в common репозиторий в JKS-хранилище idm_common_dev/<директория стенда>/ansible/files/ssl/certs.jks. Для этого необходимо:

      1. При помощи утилиты openssl поместить клиентские ключ и сертификат в хранилище типа pkcs12.

      2. При помощи утилиты keytool конвертировать хранилище в тип jks.

        1. При конвертации в JKS-хранилище certs.jks утилита потребует задать для JKS-хранилища пароль, который необходимо записать для дальнейших действий.

      3. Поместить в JKS-хранилище CA сертификат.

      4. Добавить пароль от JKS-хранилища certs.jks в переменную в файл _passwords.conf. Для этого:

        1. Добавьте в _passwords.conf переменную certs.jks.password, и укажите в значении переменной пароль от JKS-хранилища.

        2. Переопределите переменную в файле _global.resources.conf. Для этого добавьте в файл строку certs.jks.password=certs.jks.password.

      Далее будут приведены конкретные команды, которые необходимо выполнить для каждой из интеграций.

      • Сертификаты для интеграции с компонентом LOGA продукта Platform V Monitor (если используется):

        1. openssl pkcs12 -export -name logger_kafka -in logger_kafka -inkey logger_key -out logger_p12

        2. keytool -importkeystore -srckeystore logger_p12 -srcstoretype pkcs12 -destkeystore certs.jks -deststoretype JKS

        3. keytool -v -importcert -keystore certs.jks -alias logger_ca -file logger_ca

      • Сертификаты для Istio (Platform V Synapse Service Mesh) (если используется):

        1. openssl pkcs12 -export -name istio_egress_cert -in istio_egress_cert -inkey istio_egress_key -out istio_egress_p12

        2. openssl pkcs12 -export -name istio_ingress_engine_cert -in istio_ingress_engine_cert -inkey istio_ingress_engine_key -out istio_ingress_engine_p12

        3. openssl pkcs12 -export -name istio_ingress_ui_cert -in istio_ingress_ui_cert -inkey istio_ingress_ui_key -out istio_ingress_ui_p12

        4. openssl pkcs12 -export -name istio_ingress_ssp_cert -in istio_ingress_ssp_cert -inkey istio_ingress_ssp_key -out istio_ingress_ssp_p12

        5. keytool -importkeystore -srckeystore istio_egress_p12 -srcstoretype pkcs12 -destkeystore certs.jks -deststoretype JKS

        6. keytool -importkeystore -srckeystore istio_ingress_engine_p12 -srcstoretype pkcs12 -destkeystore certs.jks -deststoretype JKS

        7. keytool -importkeystore -srckeystore istio_ingress_ui_p12 -srcstoretype pkcs12 -destkeystore certs.jks -deststoretype JKS

        8. keytool -importkeystore -srckeystore istio_ingress_ssp_p12 -srcstoretype pkcs12 -destkeystore certs.jks -deststoretype JKS

        9. keytool -v -importcert -keystore certs.jks -alias istio_egress_ca -file istio_egress_ca

        10. keytool -v -importcert -keystore certs.jks -alias istio_ingress_engine_ca -file istio_ingress_engine_ca

        11. keytool -v -importcert -keystore certs.jks -alias istio_ingress_ui_ca -file istio_ingress_ui_ca

        12. keytool -v -importcert -keystore certs.jks -alias istio_ingress_ssp_ca -file istio_ingress_ssp_ca

      • Сертификаты для Platform V SOWA (если используется):

        1. openssl pkcs12 -export -name sowa_cert -in sowa_cert -inkey sowa_key -out sowa_p12

        2. keytool -importkeystore -srckeystore sowa_p12 -srcstoretype pkcs12 -destkeystore certs.jks -deststoretype JKS

        3. keytool -v -importcert -keystore certs.jks -alias sowa_ca -file sowa_ca

      • Сертификаты для Platform V Audit SE (если используется):

        1. openssl pkcs12 -export -name audit_cert -in audit_cert -inkey audit_key -out audit_p12

        2. keytool -importkeystore -srckeystore audit_p12 -srcstoretype pkcs12 -destkeystore certs.jks -deststoretype JKS

        3. keytool -v -importcert -keystore certs.jks -alias audit_ca -file audit_ca

      Обратите внимание!

      Значения alias сертификатов и имя JKS-хранилища certs.jks должны быть указаны так же как и в инструкции!

      Обратите внимание!

      Если в инсталляции IDMX используется Istio, но не используется SOWA, то все равно необходимо добавить в certs.jks сертификаты для компонента SOWA. Это связано с особенностями реализации интеграции IDMX с Istio.

      В случае отсутствия готовой инсталляции SOWA, вместо актуальных сертификатов SOWA можно подложить сертификаты для Egress, например, istio_egress_cert вместо sowa_cert, и т.д.

    • Если используется Secret Management System:

      При использовании Secret Management System следует зашифровать в base64 и положить в хранилище (vault) следующие сертификаты с такими названиями:

      • Сертификаты Istio (Platform V Synapse Service Mesh) (если используется):

        • istio_egress_ca — Сертификат CA для Egress;

        • istio_egress_cert— Клиентский сертификат для Egress;

        • istio_egress_key — Клиентский ключ для Egress;

      • Сертификаты Istio для интеграции с Platform V IAM SE (если используется, смотрите пункт 9):

        • istio_ingress_engine_ca — Сертификат CA для idmx-engine Ingress;

        • istio_ingress_engine_cert — Клиентский сертификат для idmx-engine Ingress;

        • istio_ingress_engine_key — Клиентский ключ для idmx-engine Ingress;

        • istio_ingress_ui_ca — Сертификат CA для idmx-ui Ingress;

        • istio_ingress_ui_cert — Клиентский сертификат для idmx-ui Ingress;

        • istio_ingress_ui_key — Клиентский ключ для idmx-ui Ingress;

      • Сертификаты для отправки логов IDMX во внешний компонент LOGA продукта Platform V Monitor (если используется):

        • logger_ca — Сертификат CA для Platform V Monitor;

        • logger_cert — Клиентский сертификат для Platform V Monitor;

        • logger_key — Клиентский ключ для Platform V Monitor;

      • Сертификаты для компонента SOWA продукта Platform V SOWA (если используется):

        • sowa_ca — Сертификат CA для Platform V SOWA;

        • sowa_cert — Клиентский сертификат для Platform V SOWA;

        • sowa_key — Клиентский ключ для Platform V SOWA;

      • Сертификаты для компонента AUDT продукта Platform V Audit SE (если используется):

        • audit_ca — Сертификат CA для Platform V Audit SE;

        • audit_cert — Клиентский сертификат для Platform V Audit SE;

        • audit_key — Клиентский ключ для Platform V Audit SE;

      Обратите внимание!

      Если в инсталляции IDMX используется Istio но не SOWA, то все равно необходимо добавить в vault сертификаты для компонента SOWA. Это связано с особенностями реализации интеграции IDMX с Istio.

      Если не имеется готовой инсталляции SOWA, то вместо актуальных сертификатов SOWA можно подложить сертификаты для Egress, например, в переменную sowa_cert в vault нужно положить зашифрованный в base64 клиентский сертификат для Egress, и т.д.

      Для шифрования сертификатов в base64 можно воспользоваться любым подходящим инструментом, например, утилитой base64. Для шифрования файлов перейдите в терминале или командной строке в директорию с файлами сертификатов, и выполните следующую команду:

      base64 <имя файла>, где <имя файла> — имя шифруемого файла.

      Утилита вернет в терминале строку, которая и будет зашифрованным в base64 сертификатом. Эту строку затем необходимо вставить в поле Значение (value) при создании переменной в vault Secret Management System.

  11. Запустите Deploy Job c параметрами FP_CONF_CHECK, HELM_DEPLOY. Если требуется автоматическая настройка системной БД — включите также парамтер DB_UPDATE.

  12. Если используется интеграция с Platform V Synapse Service Mesh (Istio), переведите переменные idmx-egress-gateway.enabled, idmx-ingress-gateway.enabled, globa.istio.enabled в true.

Примечания к процессу установки#

Расчет выделяемой памяти для Java машины#

Для корректной работы IDMX каждому контейнеру необходимо указать количество памяти, выделяемое для различных областей (heap, off-heap, metaspace и т.п.) Java-машины. Данные значения задаются через параметр idmx-engine.javaOptsExtra конфигурационного файла values.yaml.

Количество памяти для областей рассчитывается исходя из максимального количества памяти, выделяемого на один контейнер, и указывается в параметре как строка JVM-опций.

Необходимо рассчитать и указать следующие JVM-опции:

  • -XX:MaxMetaspaceSize — максимальный размер памяти для метаданных JVM.

    Рассчитывается по формуле <Максимальное количество RAM контейнера в мегабайтах>/5.

  • -XX:CompressedClassSpaceSize — размер памяти для данных классов Java в JVM.

    Рассчитывается по формуле <Максимальный размер памяти для метаданных>/5.

  • -XX:ReservedCodeCacheSize — размер кэша скомпилированного кода.

    Рассчитывается по формуле <Максимальный размер памяти для метаданных>/3

  • -XX:MaxDirectMemorySize — размер памяти, непосредственно доступной JVM

    Рассчитывается по формуле <Максимальный размер памяти для метаданных>/16

  • -Xms — начальный объем оперативной памяти (heap), выделяемый для JVM контейнера.

    Для вычисления размера heap памяти необходимо вычесть из максимального количества памяти для контейнера размер non-heap памяти. Non-heap память — сумма всех не heap областей памяти плюс некоторое количество памяти для системных и других нужд.

    Рассчитывается по следующим формулам:

    • Non-heap память: MaxMetaspaceSize + ReservedCodeCacheSize + MaxDirectMemorySize + (<Максимальное количество RAM контейнера в мегабайтах>/4).

    • Heap память: <Максимальное количество RAM контейнера в мегабайтах> - Non-heap.

  • -Xmx — максимальный объем heap, выделяемый для JVM. Укажите то же значение, что и для -Xms.

  • -Xss — размер стэка Java потоков. Всегда выставляется в размере 1МБ.

Например: Если для контейнера IDMX выделено 3 CPU и 6 RAM, параметр idmx-engine.javaOptsExtra необходимо заполнить следующим образом:

idmx-engine.javaOptsExtra = -Xms2895M -Xmx2895M -Xss1M -XX:MaxMetaspaceSize=1228M -XX:CompressedClassSpaceSize=245M -XX:ReservedCodeCacheSize=409M -XX:MaxDirectMemorySize=76M

А для контейнера с 2 CPU и 4 RAM:

idmx-engine.javaOptsExtra = -Xms1929M -Xmx1929M -Xss1M -XX:MaxMetaspaceSize=819M -XX:CompressedClassSpaceSize=163M -XX:ReservedCodeCacheSize=273M -XX:MaxDirectMemorySize=51M

Обратите внимание

При использовании нескольких контейнеров (pod), ресурсы, указанные в параметре idmx-engine.javaOptsExtra будут выделяться для каждого пода. Убедитесь, что в namespace для IDMX выделено достаточно ресурсов.

Кластерный режим IDMX#

При включении кластерного режима работы (idmx-engine.cluster = true), IDMX также необходимо настроить на масштабирование и распределение нагрузки между контейнерами IDMX. Подробнее о настройке смотрите раздел Масштабирование задач документа Руководство оператора.

Также можно задать количество реплик (контейнеров), которое создается при запуске или установке IDMX. Для этого используется параметр idmx-engine.replicas файла values.yaml.

Например, если требуется создание трех контейнеров (pod) idmx-engine, то укажите значение параметра idmx-engine.replicas = 3. Также можно регулировать количество активных реплик idmx-engine вручную средствами среды оркестрации контейнеризированных приложений.

Обратите внимание

Если кластерный режим выключен, IDMX не будет утилизировать больше одного контейнера. Следовательно, устанавливать значение параметра idmx-engine.replicas больше 1 будет бессмысленно и будет излишней тратой ресурсов.

Защита соединения с БД по SSL и типы Service Mesh#

Для защиты входящего и исходящего трафика и соединений IDMX поддерживает работу с двумя типами Service Mesh — Platform V Synapse Service Mesh (рекомендовано) и Red Hat Service Mesh (опционально). В зависимости от используемой Service Mesh следует выполнять настройку IDMX по разному.

Если используется Red Hat Service Mesh или не используется никакой Service Mesh вообще:

  1. Убедитесь, что БД установлена с поддержкой SSL (согласно документации на используемую СУБД — Platform V Pangolin SE или PostgreSQL);

  2. Получите у администраторов используемой БД следующие комплекты сертификатов:

    • серверный сертификат и ключ;

    • сертификат клиента и ключ. Обратите внимание, ключ в данной паре сертификатов должен быть сгенерирован в формате DER;

    • CA сертификат.

  3. Добавьте серверный сертификат и ключ (при необходимости — также CA сертификат) в безопасное место хранения (рекомендуется Secret Management System), доступное СУБД:

    1. Если используется Secret Management System — поместите сертификаты и ключи под следующими именами в пространство Secret Management System, заведенное для инсталляции IDMX:

      • postgres_ca — Сертификат CA для системной БД IDMX;

      • postgres_cert — Клиентский сертификат для системной БД IDMX;

      • postgres_pk8 — Клиентский ключ для системной БД IDMX в формате DER (смотрите примечание ниже);

    2. Если Secret Management System не используется — поместите сертификаты и ключи в хранилище certs.jks репозитория конфигурации Deploy Tools, созданного для IDMX:

      1. openssl pkcs12 -export -name postgres_cert -in postgres_cert -inkey postgres_key -out postgres_p12

      2. keytool -importkeystore -srckeystore postgres_p12 -srcstoretype pkcs12 -destkeystore certs.jks -deststoretype JKS

      3. keytool -v -importcert -keystore certs.jks -alias postgres_ca -file postgres_ca

  4. Добавьте сертификаты и ключи в конфигурацию СУБД. Для этого:

    1. Внесите изменения в настройки СУБД (файлы postgresql.conf и pg_hba.conf), включив использование SSL и указав пути до сертификатов (подробные инструкции смотрите в документации на используемую СУБД);

    2. Сохраните изменения в настройках и перезагрузите СУБД.

  5. Измените следующие параметры в конфигурационных файлах IDMX:

    • global.repository.database.mtls в true;

    • global.repository.database.url — добавьте в данный URL пути до сертификатов, например:

    jdbc:postgresql://pangolin.db.mycorp.ru:5432/idmx-1?prepareThreshold=0&ssl=true&sslmode=verify-full&sslcert=/vault/secrets/postgres/postgres_cert&sslkey=/vault/secrets/postgres/postgres_pk8&sslrootcert=/vault/secrets/postgres/postgres_ca

    • global.istio.type в rhsm

    • global.istio.enabled в true (или, если Service Mesh не используется — false)

Обратите внимание

Поскольку для подключения IDMX к БД используется JDBC драйвер, ключ сертификата, указываемого в параметре global.repository.database.url, должен быть в формате DER, а не PEM, так как иначе драйвер не сможет его распознать, и не сможет подключиться к БД.

Для генерации или перекодировки ключа сертификата в DER можно воспользоваться утилитой OpenSSL и следующей командой:

openssl pkcs8 -topk8 -inform PEM -in postgresql.key -outform DER -out postgresql.pk8 -v1 PBE-MD5-DES -nocrypt

Если же используется Platform V Synapse Service Mesh, то:

  1. Убедитесь, что БД установлена с поддержкой SSL (согласно документации на используемую СУБД — Platform V Pangolin SE или PostgreSQL);

  2. Получите у администраторов используемой БД следующие комплекты сертификатов:

    • серверный сертификат и ключ;

    • сертификат клиента и ключ. Обратите внимание, ключ в данной паре сертификатов должен быть сгенерирован в формате DER;

    • CA сертификат.

  3. Добавьте серверный сертификат и ключ (при необходимости — также CA сертификат) в безопасное место хранения (рекомендуется Secret Management System), доступное СУБД:

    1. Если используется Secret Management System — поместите сертификаты и ключи под следующими именами в пространство Secret Management System, заведенное для инсталляции IDMX:

      • postgres_ca — Сертификат CA для системной БД IDMX;

      • postgres_cert — Клиентский сертификат для системной БД IDMX;

      • postgres_key — Клиентский ключ для системной БД IDMX;

    2. Если Secret Management System не используется — поместите сертификаты и ключи в хранилище certs.jks репозитория конфигурации Deploy Tools, созданного для IDMX:

      1. openssl pkcs12 -export -name postgres_cert -in postgres_cert -inkey postgres_key -out postgres_p12

      2. keytool -importkeystore -srckeystore postgres_p12 -srcstoretype pkcs12 -destkeystore certs.jks -deststoretype JKS

      3. keytool -v -importcert -keystore certs.jks -alias postgres_ca -file postgres_ca

  4. Добавьте сертификаты и ключи в конфигурацию СУБД. Для этого:

    1. Внесите изменения в настройки СУБД (файлы postgresql.conf и pg_hba.conf), включив использование SSL и указав пути до сертификатов (подробные инструкции смотрите в документации на используемую СУБД);

    2. Сохраните изменения в настройках и перезагрузите СУБД.

  5. Измените следующие параметры в конфигурационных файлах IDMX:

    • global.repository.database.mtls в true;

    • global.repository.database.url — URL до БД без указания сертификатов и с эксплицитным отключением SSL на стороне БД, например:

    jdbc:postgresql://pangolin.db.mycorp.ru:5432/idmx-1?prepareThreshold=0&sslmode=disable

    • global.istio.type в synapse

    • global.istio.enabled в true

Ключ шифрования IDM#

IDM по умолчанию шифрует данные, считающиеся чувствительными (например, пароли учетных карточек), перед помещением их в системную БД. Также администраторы могут указать другие данные как чувствительные при настройке конфигураций ресурсов.

Для шифрования используется Java библиотека java.security, алгоритм AES с 256-битным ключом. Первый ключ помещается в хранилище ключей idmx-keystore.jceks при первой установке IDMX (смотрите шаг 5 раздела Установка IDMX).

Обратите внимание!

Пароль любого ключа шифрования всегда должен быть midpoint, иначе IDM не сможет его прочитать из хранилища ключей!

Изменение ключа шифрования#

В зависимости от требований кибербезопасности, ключ шифрования IDM может потребоваться заменять с некоторой регулярностью (например, каждые 3 месяца). Для смены ключа:

  1. Остановите контейнеры с IDMX, для которых требуется сменить ключ.

  2. Загрузите idmx-keystore.jceks из системы хранения секретов, которая используется в инсталляции.

  3. Сгенерируйте новый ключ с помощью утилиты keytool и поместите его в скачанный idmx-keystore.jceks:

    keytool -genseckey -alias newkey -keystore /path/to/idmx-keystore.jceks -storetype jceks -storepass changeit -keyalg AES -keysize 256 -keypass midpoint

    , где:

    • newkey — alias нового ключа;

    • /path/to/idmx-keystore.jceks — путь к скачанному idmx-keystore.jceks относительно директории, которая открыта в командной строке;

    • changeit — пароль от хранилища ключей idmx-keystore.jceks, заданный на шаге 5 установки IDMX.

    Не изменяйте остальных значений в команде.

    Обратите внимание, пароль для нового ключа шифрования (параметр -keypass) всегда должен быть midpoint, иначе IDMX не сможет воспользоваться этим ключом.

  4. Загрузите хранилище ключей с новым ключом шифрования в систему хранения секретов, заменив им старое хранилище.

  5. Сконфигурируйте IDMX на использование нового ключа безопасности как основного ключа. Для этого в ConfigMap или в файле values.yaml в common репозитории добавьте в параметр idmx-engine.javaOptsExtra значение -Dmidpoint.keystore.encryptionKeyAlias=newkey, где newkey — alias нового ключа, сгенерированный на шаге 3 данной инструкции, и сохраните изменения.

  6. Если изменялись значения в файле values.yaml — запустите Deploy job с флагом HELM_DEPLOY для установки IDMX с новыми конфигурационными файлами.

    Если же изменялись параметры в ConfigMap — просто запустите контейнеры IDMX.

После смены ключа в БД IDMX останется некоторое количество данных, зашифрованных старым ключом, например, паролей. По мере устаревания паролей (согласно требованиям информационной безопасности) пароли будут изменяться пользователями, и, соответственно перешифровываться новым ключом шифрования. После того, как все чувствительные данные будут перешифрованы — старый ключ шифрования можно будет удалить из хранилища ключей.

Экстренная смена ключа шифрования#

В случае, если текущий ключ шифрования был компрометирован, процесс постепенной смены шифрования может быть слишком медленным. IDMX поддерживает возможность экстренной замены шифрования файлов:

  1. Обновите ключ шифрования согласно инструкции из раздела Изменение ключа шифрования.

  2. Создайте конфигурацию задачи (task) list-encryption-keys.xml, импортируйте ее в IDMX и запустите:

     <task xmlns="http://midpoint.evolveum.com/xml/ns/public/common/common-3"
      xmlns:s="http://midpoint.evolveum.com/xml/ns/public/model/scripting-3"
      xmlns:c="http://midpoint.evolveum.com/xml/ns/public/common/common-3"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      oid="b427848b-ea98-4da1-acba-c16cbb0e9c22">
    <name>List encryption keys</name>
    <extension xmlns:mext="http://midpoint.evolveum.com/xml/ns/public/model/extension-3"
               xmlns:scext="http://midpoint.evolveum.com/xml/ns/public/model/scripting/extension-3">
        <scext:executeScript>
            <s:action>
                <s:type>execute-script</s:type>
                <s:parameter>
                    <s:name>script</s:name>
                    <value xsi:type="c:ScriptExpressionEvaluatorType">
                        <c:code>
                            import com.evolveum.midpoint.common.crypto.CryptoUtil

                            midpoint.applyDefinition(input)
                            keys = CryptoUtil.getEncryptionKeyNames(input.asPrismObject())
                            clear = CryptoUtil.containsCleartext(input.asPrismObject())
                            hashed = CryptoUtil.containsHashedData(input.asPrismObject())
                            if (!keys.isEmpty() || clear || hashed) {
                                append = ""
                                if (clear) {
                                    append += " [CLEARTEXT]"
                                }
                                if (hashed) {
                                    append += " [HASHED]"
                                }
                                log.info(sprintf('Object: %-100s uses keys: %s%s', input, keys, append))
                            }
                        </c:code>
                    </value>
                </s:parameter>
                <s:parameter>
                    <s:name>quiet</s:name>
                    <value>true</value>
                </s:parameter>
            </s:action>
        </scext:executeScript>
        <mext:useRepositoryDirectly>true</mext:useRepositoryDirectly>
    </extension>
    <ownerRef oid="00000000-0000-0000-0000-000000000002"/>
    <executionStatus>runnable</executionStatus>
    <category>BulkActions</category>
    <handlerUri>http://midpoint.evolveum.com/xml/ns/public/model/iterative-scripting/handler-3</handlerUri>
    <recurrence>single</recurrence>
</task>

    Данная задача выведет в лог список объектов, содержащих зашифрованную информацию, и хэш ключа, которым они шифровались. Например:

    2018-10-16 18:06:02,665 [MODEL] [midPointScheduler_Worker-4] INFO (com.evolveum.midpoint.expression): Object: systemConfiguration:00000000-0000-0000-0000-000000000001(SystemConfiguration)                        uses keys: [A5yfWFgnD4euq3CgpdecmZPA/DE=]
2018-10-16 18:06:02,688 [MODEL] [midPointScheduler_Worker-4] INFO (com.evolveum.midpoint.expression): Object: user:00000000-0000-0000-0000-000000000002(administrator)                                             uses keys: [A5yfWFgnD4euq3CgpdecmZPA/DE=]
2018-10-16 18:06:02,972 [MODEL] [midPointScheduler_Worker-4] INFO (com.evolveum.midpoint.expression): Object: resource:62a63be7-a5fb-4168-a389-ef69f8982a85(Basic Localhost OpenDJ)                                uses keys: [A5yfWFgnD4euq3CgpdecmZPA/DE=]
2018-10-16 18:06:02,981 [MODEL] [midPointScheduler_Worker-4] INFO (com.evolveum.midpoint.expression): Object: user:bce98bd5-f8cd-4a6a-8488-4ae7ad369c0b(ivan)                                                       uses keys: [A5yfWFgnD4euq3CgpdecmZPA/DE=]
2018-10-16 18:06:02,984 [MODEL] [midPointScheduler_Worker-4] INFO (com.evolveum.midpoint.expression): Object: user:db052966-ce05-486e-97cf-60deea8e4af6(newuser1)                                                  uses keys: [ZxwccL30e4UxM5hSOxYkaYJsUUM=]
2018-10-16 18:06:03,007 [] [midPointScheduler_Worker-4] INFO (com.evolveum.midpoint.repo.common.task.AbstractSearchIterativeTaskHandler): Finished Execute script (Task(id:1539705731263-0-1, name:List encryption keys, oid:b427848b-ea98-4da1-acba-c16cbb0e9c22)). Processed 45 objects in 0 seconds, got 0 errors. Average time for one object: 18.622223 milliseconds (wall clock time average: 20.933332 ms).

    В примере выше ключ шифрования был уже обновлен, и учетная карточка newuser1 была создана после смены ключа. Это также видно по используемым ключам шифрования в лог-файле — только у newuser1 он отличается.

    Данная задача предназначена для предварительной проверки зашифрованных объектов, с целью определения тех объектов, которые нужно перешифровать новым ключом.

  3. После того как текущий статус зашифрованных объектов проверен, можно приступить к перешифровке тех, что были зашифрованы скомпрометированным ключом.

    Для этого создайте xml-файл с конфигурацией задачи для перешифрования и импортируйте ее в IDMX. Например:

    <task xmlns="http://midpoint.evolveum.com/xml/ns/public/common/common-3"
      xmlns:q="http://prism.evolveum.com/xml/ns/public/query-3"
      xmlns:s="http://midpoint.evolveum.com/xml/ns/public/model/scripting-3"
      oid="172b3d9f-66f8-4731-b023-0e2d8ca5cd6f">
    <name>Reencrypt selected objects</name>
    <extension xmlns:mext="http://midpoint.evolveum.com/xml/ns/public/model/extension-3"
               xmlns:scext="http://midpoint.evolveum.com/xml/ns/public/model/scripting/extension-3">
        <scext:executeScript>
            <s:pipeline>
                <s:action>
                    <s:type>apply-definition</s:type>   <!-- данный указатель типа требуется, чтобы задача обрабатывала объекты типа ResourceType и ShadowType -->
                </s:action>
                <s:action>
                    <s:type>reencrypt</s:type>
                    <!-- Данный блок параметров отвечает за режим dry run — тестовый прогон задачи. Укажите значение false, чтобы отключить режим. -->
                    <s:parameter>
                        <s:name>dryRun</s:name>
                        <value>true</value>
                    </s:parameter>
                </s:action>
            </s:pipeline>
        </scext:executeScript>
        <mext:useRepositoryDirectly>true</mext:useRepositoryDirectly>
<!-- Данный блок отвечает за более узкий выбор объектов для перешифровки. Раскомментируйте его, и укажите требуемые объекты или группы объектов с помощью блоков mext:objectType и mext:objectQuery. -->
<!--    <mext:objectType>UserType</mext:objectType>
        <mext:objectQuery>
            <q:filter>
                <q:equal>
                    <q:path>name</q:path>
                    <q:value>administrator</q:value>
                </q:equal>
            </q:filter>
        </mext:objectQuery>  -->
    </extension>
    <ownerRef oid="00000000-0000-0000-0000-000000000002"/>
    <executionStatus>runnable</executionStatus>
    <category>BulkActions</category>
    <handlerUri>http://midpoint.evolveum.com/xml/ns/public/model/iterative-scripting/handler-3</handlerUri>
    <recurrence>single</recurrence>
</task>

    Данная задача выполнит перешифровку файлов с помощью ключа шифрования, установленного как основной ключ (смотрите раздел Изменение ключа шифрования). Также можно сконфигурировать некоторые параметры задачи для большего удобства:

    1. Параметр dryRun, если установлен в значение true, перевевдет задачу в режим тестового прогона. В этом режиме задача после запуска не будет применять изменения к файлам, а лишь проанализирует объекты, зашифрованные не основным ключом и выведет список этих объектов и операции, которые будет к ним применять, в лог-файл.

    2. Блоки фильтрации <mext:objectType> и <mext:objectQuery> позволяют уточнить объекты или группы объектов, которые следует перешифровать. По умолчанию будут перешифрованы все объекты, зашифрованные не основным ключом, либо содержащие cleartext данные.

  4. Рекомендуется сначала запустить задачу перешифровки в режиме тестового прогона, чтобы убедиться, что будет перешифрованы требуемые объекты. Затем создайте новый файл конфигурации (либо измените уже импортированную задачу) с отключенным режимом тестового прогона и запустите ее, чтобы перешифровать файлы.

  5. Опционально можно запустить задачу из шага 2 еще раз, чтобы убедиться, что все требуемые объекты зашифрованы актуальным нескомпрометированным ключом.

Настройка mTLS к Platform V Audit SE#

IDMX поддерживает возможность защиты подключения к Platform V Audit SE при помощи mTLS 1.2. Включение такой защиты возможно только в ситуации, когда Istio отключен и для аудита используется Platform V Audit SE (global.audit.enabled = true, параметры группы global.audit заполнены корректно).

Для включения защиты:

  1. Получите ключ и сертификат (audit_key и audit_cert) для Platform V Audit SE. Если секреты уже помещены в хранилище сертификатов, их следует извлечь. Для этого можно воспользоваться командой, подобной примеру ниже:

    openssl pkcs12 -export -name audit_cert -in ../../DEV_PROFILE/keystoremanips/audit.crt -inkey ../../DEV_PROFILE/keystoremanips/audit.key -out audit_p12

  2. Поместите данные ключ и сертификат в idmx-keystore.jceks (смотрите пункт 5 раздела Установка IDMX). Для этого:

    1. Загрузите текущий idmx-keystore.jceks из используемого хранилища секретов. В случае, если для хранения секретов используется SecMan, потребуется также конвертировать полученную base64 строку в файл хранилища ключей. Для этого, например, можно воспользоваться утилитой base64:

      1. Сохраните полученную base64 строку как файл расширения .b64, например, следующей командой: cat keystore.b64 zs7Oz...MDk, где keystore.b64 — имя файла; zs7Oz...MDk — полученная из SecMan base64 строка, содержащая хранилище ключей.

      2. Конвертируйте .b64 файл в хранилище ключей формата .jceks при помощи утилиты, например, base64:

      base64 --decode -i keystore.b64 -o idmx-keystore.jceks

    2. Поместите в данное хранилище ключей полученные ключ и сертификат Platform V Audit SE. Например, при помощи утилиты keytool:

      keytool -importkeystore -srckeystore audit_p12 -srcstoretype pkcs12 -destkeystore idmx-keystore.jceks -deststoretype JCEKS -srcstorepass changeit -deststorepass changeit -destkeypass midpoint, где:

      • srckeystore — имя хранилища с полученными сертификатами Audit;

      • destkeystore — имя хранилищая ключей IDMX, полученного на предыдущем шаге;

      • srcstorepass и deststorepass — пароли от хранилища с сертификатами Audit и хранилища ключей IDMX соответственно;

      • destkeypass — пароль для ключа Audit. Всегда должен иметь значение midpoint.

    3. Добавьте в хранилище сертификатов certs.jks в common репозитории корневой сертификат Audit под alias audit_ca. Например:

    keytool -v -importcert -keystore certs.jks -alias audit_ca -file audit_ca 4. Загрузите дополненное хранилище ключей idmx-keystore.jceks обратно в хранилище секретов (Kubernetes Secrets или SecMan), заменяя предыдущее.

  3. Укажите для параметра global.audit.mtls (файл values.yaml) значение true.

Миграция конфигурационных файлов#

Конфигурационные файлы, содержащие параметры и их описания, расположены в подготовленных репозиториях для Deploy tools (CDJE) в директории /conf/helm/application/idmx/ дистрибутива. Перед установкой в среду системы оркестрации контейнеризированных приложений данные конфигурационные файлы следует мигрировать в репозиторий для конфигураций стендов согласно документации компонента Deploy tools (CDJE). Для этого в веб-интерфейсе компонента выберите и запустите шаг (playbook) Миграция конфигурационных файлов (MIGRATION_FP_CONF).

Файлы конфигураций названы values.yaml, и содержат параметры, описания параметров и примеры значений, которые можно задать. Ниже приведен список конфигурационных файлов с расположениями и дополнительными пояснениями:

Корневой файл конфигурации#

Основной values.yaml, расположен в директории /conf/helm/application/idmx/.

В данном файле задаются основные конфигурационные параметры для инсталляции IDMX. В нем включаются и настраиваются глобальные параметры, например, подключение к системной БД IDMX, а также интеграции с платформенными зависимостями, такими, как Platform V Audit.

Также основной конфигурационный файл позволяет задавать значения для конфигурационных файлов компонентов. Для этого требуемые параметры следует переопределить в разделе включения/выключения установки компонентов, добавив эти параметры и нужные значения под соответствующим компонентом.

Например, чтобы поднять количество реплик idmx-engine, запускаемых на старте, до 2, следует переопределить параметр replicas:

idmx-engine:
  enabled: true
  replicas: 2

Все параметры, доступные для переопределения, описаны в разделах ниже.

Список параметров:

# Включение/выключение установки сервисов
idmx-egress-gateway:
  enabled: true
idmx-ingress-gateway:
  enabled: true
idmx-engine:
  enabled: true
idmx-connector-server:
  enabled: true
idmx-ui:
  enabled: true


global:
  # Тип оркестратора контейнеров, используемого в кластере: kubernetes - k8s, openshift - ose
  orchestrator: ose
  # Имя Service Account, которое будет использоваться для запуска модулей
  serviceAccountName: default
  # Домен используемого кластера kubernetes/openshift
  clusterDomain: cluster-domain
  # Хост контейнерного реестра, используемого для хранения образов
  registry: registry-hostname
  # Путь к контейнерному реестру
  registryPath: registry-path


  # Настройка для отображения в UI(старый и новый)
  environment:
    # Контур/стенд (DEV/ПСИ/ПРОМ и т.д. для отображения в UI)
    name: DEV
    # Скин/тема UI:
    #  skin-blue, skin-blue-light, skin-yellow, skin-yellow-light,
    #  skin-green, skin-green-light, skin-purple, skin-purple-light,
    #  skin-red, skin-red-light, skin-black, skin-black-light
    skin: "skin-green"
    # Ссылка на страницу документации, для отображения в UI
    help_url: ""


  # Параметр задает путь до основной директории idmx-engine
  engine:
    basePath:


  # Параметр включает авторизацию через Platform V IAM
  iam:
    enabled: false


  # Настройка ingress
  ingress:
    # Создание маршрута для idmx-engine
    idmxEngine:
      enabled: true
      # Название Ingress Controller для маршрута idmx-engine, для Kubernetes >= 1.18, например nginx
      ingressClassName: ""
      # Аннотации ingress для маршрута idmx-engine
      annotations: {}
        # kubernetes.io/ingress.class: nginx
        # ingress.kubernetes.io/ssl-passthrough: 'true'
      # Конфигурация TLS для маршрута idmx-engine
      tls: []
        # - secretName: idmx-engine-tls
        #     hosts:
        #       - idmx-engine.domain.ru
    # Создание маршрута для idmx-connector-server
    idmxConnectorServer:
      enabled: false
      # Название Ingress Controller для маршрута idmx-connector-server, для Kubernetes >= 1.18, например nginx
      ingressClassName: ""
      # Аннотации ingress для маршрута idmx-connector-server
      annotations: {}
        # kubernetes.io/ingress.class: nginx
        # ingress.kubernetes.io/ssl-passthrough: 'true'
      # Конфигурация TLS для маршрута idmx-connector-server
      tls: []
        # - secretName: idmx-connector-server-tls
        #     hosts:
        #       - idmx-connector-server.domain.ru
    # Создание маршрута для idmx-ui
    idmxUi:
      enabled: true
      # Название Ingress Controller для маршрута idmx-ui, для Kubernetes >= 1.18, например nginx
      ingressClassName: ""
      # Аннотации ingress для маршрута idmx-ui
      annotations: {}
        # kubernetes.io/ingress.class: nginx
        # ingress.kubernetes.io/ssl-passthrough: 'true'
      # Конфигурация TLS для маршрута idmx-ui
      tls: []
        # - secretName: idmx-ui-tls
        #     hosts:
        #       - idmx-ui.domain.ru


  # Настройка системной БД idmx-engine
  repository:
    database:
      # Тип системной базы данных, используемой IDMX для хранения внутренних данных
      type: postgresql
      # Параметр определяет, будет ли использоваться mTLS для подключения idmx-engine к системной БД
      # При использовании MTLS без istio или с RedHat Service Mesh:
      # jdbc:postgresql://db-hostname:127.0.0.1:5432/db-name?prepareThreshold=0&ssl=true&sslmode=verify-full&sslcert=/vault/secrets/postgres/postgres_cert&sslkey=/vault/secrets/postgres/postgres_pk8&sslrootcert=/vault/secrets/postgres/postgres_ca
      # При использовании MTLS и Synapse Service Mesh:
      # jdbc:postgresql://db-hostname:127.0.0.1:5432/db-name?prepareThreshold=0&sslmode=disable
      mtls: true
      # URL, по которому IDMX будет подключаться к системной БД. <DB_EXTERNAL_PORT> указывается обязательно. Значения перечисляются через ',' в формате:
      # <DB_HOST>:<DB_IP>:<DB_EXTERNAL_PORT>, где:
      # <DB_HOST> — FQDN узла, на котором расположена системная БД IDMX (обязательно для работы с istio);
      # <DB_IP> — IP-адрес узла (обязательно для работы с istio);
      # <DB_EXTERNAL_PORT> — порт внешнего узла (сервера с системной БД).
      url: jdbc:postgresql://db-hostname:127.0.0.1:5432/db-name?prepareThreshold=0&sslmode=disable
      # Вынос логов аудита в отдельную БД
      separated: false
      # Вынос логов аудита в отдельную БД на отдельный узел
      differentHost: false
      audit:
        # Параметр определяет, будет ли использоваться mTLS для подключения idmx-engine к БД с аудитом
        mtls: true
        # URL, по которому IDMX будет подключаться к БД с аудитом, заполняется аналогично с .Values.global.repository.database.url
        # Зависит от параметров .Values.global.repository.database.separated и .Values.global.repository.database.differentHost
        url: jdbc:postgresql://db-hostname:127.0.0.1:5432/db-name?prepareThreshold=0&sslmode=disable


  # Параметр задает список названий (alias) дополнительных сертификатов для монтирования сертификатов к инсталляции IDMX
  # Задаются в формате строк, разделенных ',' например alias1,alias2,alias3
  # Используемые сертификаты должны быть загружены в SecMan, под именами в формате alias1_cert, alias1_key, alias1_ca
  extra:
    enabled: false
    certs: postgres_kis


  # Настройка интеграции с Istio Service Mesh
  istio:
    enabled: true
    # Тип используемого Service Mesh. Redhat Service Mesh - rhsm, Synapse Service Mesh - synapse
    type: synapse
    # Образ для idmx-egress-gateway и idmx-ingress-gateway
    image: istio-image
    # Параметр определяет имя экземпляра Istio Control Plane для Ingress
    instance: istio-instance
    # Параметр определяет адрес Istio Control Plane для Ingress
    discoveryAddress: istiod:15012


  # Настройка интеграции с Platform V Audit SE
  audit:
    enabled: true
    # Параметр определяет, будет ли использоваться защита соединения с Platform V Audit через mTLS
    mtls: true
    # Параметр задает host, по которому в клиент Platform V Audit SE будут отправляться сообщения аудита
    host: audit-hostname
    # Параметр задает IP-адрес клиента Platform V Audit SE
    ip: 127.0.0.1
    # Параметр задает порт клиента Platform V Audit SE
    port: 443
    # Параметр задает версию метамодели аудита IDMX для Platform V Audit SE
    metamodelVersion: 4


  # Настройка интеграции с Secret Management System
  secman:
    enabled: true
    # В этом параметре указывается префикс для взаимодействие с API Secret Management
    mountPath: auth/kubernetes
    # Параметр задает пространство имен, в котором расположен экземпляр Secret Management System, используемый для IDMX
    namespace: DEV_IDMX
    # Параметр определяет роль для доступа к секретам IDMX в Secret Management System
    role: role-ga-secman-idmx-dev
    # URL инсталляции Secret Management System
    url: https://secman-hostname:443
    # Параметр определяет ключ для доступа к секретам IDMX в Secret Management System
    key: A/DEV/IDMX/KV/DEV


  # Настройка интеграции с fluent-bit
  fluent:
    enabled: true
    # Образ для fluent-bit sidecars
    image: fluent-bit-image
    # Настройка отправки логов в Kafka
    kafka:
      enabled: true
      # Параметр определяет, будет ли использоваться mTLS для подключения к Kafka
      mtls: true
      # Параметр определяет брокеров Kafka, через которых будут отправляться журналы логов IDMX.
      # Если значение параметра не задано — журналы логов не будут отправляться.
      # Значения перечисляются через ',' в формате <HOST>:<IP>:<PORT>, где:
      # <HOST> — FQDN внешнего узла;
      # <IP> — IP-адрес внешнего узла;
      # <PORT> — порт внешнего узла.
      brokers: kafka-hostname:127.0.0.1:9093
      # Параметр определяет топики Kafka, в которых будут отправляться журналы логов IDMX
      topics: idmx.logs
      # Уровень логирования
      logLevel: 6
    # Настройка отправки логов в Loki
    loki:
      enabled: false
      # Параметр определяет, будет ли использоваться mTLS для подключения к Loki
      mtls: true
      # Параметр определяет host Loki
      host: loki-hostname
      # Параметр задает IP-адрес Loki
      ip: 127.0.0.1
      # Параметр задает порт Loki
      port: 3100


  # Настройка интеграции с AC REFLEX
  reflex:
    enabled: false
    # узел для подключения к системе мониторинга, собирается из: age-routing-${ENV_NAME}.${PROJECT_NAME}.apps.${CLUSTER_NAME}
    host: age-routing-env.project.apps.clustername.ru
    # Имя кластера АС в сети
    cluster: clustername.ru
    # Идентификатор среды АС
    environmentId: aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee
    # Версия агента АС
    agentVersion: '1.1'

Конфигурация idmx-engine#

Данный файл содержит параметры, относящиеся к idmx-engine. Файл расположен в директории /conf/helm/application/idmx/charts/idmx-engine/.

Список параметров:

# Количество реплик приложения idmx-engine
replicas: 1


# Настройки подключения к БД
# (полное описание см. в настройках HikariCP: https://github.com/brettwooldridge/HikariCP)
repository:
  # Минимальное количество соединений в пуле
  minPoolSize: 8
  # Максимальное количество соединений в пуле
  maxPoolSize: 40
  # Максимальное время жизни соединения в пуле
  maxLifetime: 1800000
  # Время, в течение которого соединению разрешено простаивать в пуле
  idleTimeout: 600000
  # Как часто нужно посылать запросы (ping) через соединение, чтобы предотвратить его тайм-аут из-за базы данных или сетевой инфраструктуры (0 - отключено)
  keepaliveTime: 0
  # Время, в течение которого соединение может находиться вне пула, прежде чем будет зарегистрировано сообщение, указывающее на возможную утечку соединения (0 - отключено)
  leakDetectionThreshold: 0
  # Максимальное время, в течение которого клиент будет ждать соединения из пула
  connectionTimeout: 30000
  # Время, в течение которого соединение будет проверяться на работоспособность
  validationTimeout: 5000
  # Время, по истечению которого пул будет выходить из строя (fail-fast), если он не может быть успешно проинициализирован.
  initializationFailTimeout: 60000


# Настройка кластерного режима для idmx-engine
cluster: true
# Путь до директории, в которую будут записываться журналы логов
logsPath: /app/idmx-engine/var/log
# Настройка режима отладки логов idmx-engine
debugLog: false
# HTTP-заголовок для виртуального сервера Tomcat
tomcat:
  portHeader: X-Forwarded-Port
# Параметр определяет, можно ли вносить изменения в конфигурацию логирования через UI IDMX
internalsAvoidLoggingChange: false
# Дополнительные опции запуска для Java-машины
javaOptsExtra: -Xms2895M -Xmx2895M -Xss1M -XX:MaxMetaspaceSize=1228M -XX:CompressedClassSpaceSize=245M -XX:ReservedCodeCacheSize=409M -XX:MaxDirectMemorySize=76M


# Настройка горизонтального масштабирования (Horizontal Pod Autoscaling - HPA) для приложения idmx-egress-gateway
hpa:
  enabled: false
  # Минимальное количество реплик (pod), которые должны быть запущены
  minReplicas: 1
  # Максимальное количество реплик (pod), которые горизонтальное масштабирование может создать
  maxReplicas: 2
  # Целевое значение использования CPU, в процентах. При превышении данного значения (повышении загрузки процессора), HPA будет увеличивать количество реплик
  targetCPUUtilizationPercentage: 80


# Настройка интеграции с Prometheus для idmx-engine
prometheus:
  # Параметр определяет, включен ли сбор данных Prometheus
  scrape: true
  # Порт, на котором Prometheus будет осуществлять сбор данных
  port: 8080
  # Путь, по которому Prometheus может получить данные
  path: /midpoint/actuator/prometheus


# Настройка интеграции idmx-engine с Platform V IAM SE
sp:
  # HTTP-заголовок, который будет использоваться при авторизации через Platform V IAM SE
  usernameHeader: iv-user
  # URL для выхода из учетной записи при авторизации через Platform V IAM SE
  logoutUrl: /openid-connect-auth/logout


# Вычислительные ресурсы, необходимые контейнеру idmx-engine
resources:
  requests:
    # Количество ядер процессора, которое будет запрошено для контейнера
    cpu: 1
    # Минимальный объем оперативной памяти, который будет запрошен для контейнера
    memory: 2Gi
    # Минимальный объем временного хранилища, который будет запрошен для контейнера
    ephemeral-storage: 512Mi
  limits:
    # Максимальное количество ядер процессора, которое будет выделено для контейнера
    cpu: 3
    # Максимальный объем оперативной памяти, который будет выделен для контейнера
    memory: 6Gi
    # Максимальный объем временного хранилища, который будет выделен для контейнера
    ephemeral-storage: 1Gi


# Настройка проверки готовности контейнера idmx-engine
readinessProbe:
  # Количество секунд, которое должно пройти после запуска контейнера, прежде чем начнется проверка готовности
  initialDelaySeconds: 30
  # Максимальное количество времени ожидания для каждой проверки готовности
  timeoutSeconds: 2
  # Интервал между последовательными проверками готовности
  periodSeconds: 10
  # Количество последовательных успешных проверок, необходимых для того, чтобы считать контейнер готовым
  successThreshold: 1
  # Количество последовательных неудачных проверок, после которых контейнер считается неготовым
  failureThreshold: 15
# Настройка проверки жизнеспособности контейнера idmx-engine
livenessProbe:
  # Количество секунд, которое должно пройти после запуска контейнера, прежде чем начнется проверка жизнеспособности
  initialDelaySeconds: 30
  # Максимальное количество времени ожидания для каждой проверки жизнеспособности
  timeoutSeconds: 2
  # Интервал между последовательными проверками жизнеспособности
  periodSeconds: 10
  # Количество последовательных успешных проверок, необходимых для того, чтобы считать контейнер активным
  successThreshold: 1
  # Количество последовательных неудачных проверок, после которых контейнер считается неактивным
  failureThreshold: 15


# Приоритет выполнения для idmx-engine в кластере
priorityClassName: null


# Настройка атрибутов безопасности
securityContext:
  # Устанавливает группу пользователей для всех файлов в томе, когда том монтируется в Pod
  fsGroup: null
  # UID, с которым будет запущен контейнер idmx-engine
  runAsUser: null
  # GID, с которым будет запущен контейнер idmx-engine
  runAsGroup: null


# Настройка внешнего источника коннекторов IDMX для idmx-engine
initConnectorsLoad:
  # container - в случае использования init контейнер, download - в случае загрузки коннекторов из внешнего сервиса
  type: null
  # если type: container, указываем образ init контейнер; если type: download, указываем адрес внешнего ресурса
  source: null
  tries:
    # Количество попыток загрузить коннекторы из внешнего ресурса
    count: 15
    # Время ожидания в секундах, между попытками загрузить коннекторы из внешнего ресурса
    timeout: 3
  # Вычислительные ресурсы, необходимые init контейнеру
  resources:
    requests:
      # Количество ядер процессора, которое будет запрошено для контейнера
      cpu: 100m
      # Минимальный объем оперативной памяти, который будет запрошен для контейнера
      memory: 128Mi
      # Минимальный объем временного хранилища, который будет запрошен для контейнера
      ephemeral-storage: 128Mi
    limits:
      # Максимальное количество ядер процессора, которое будет выделено для контейнера
      cpu: 200m
      # Максимальный объем оперативной памяти, который будет выделен для контейнера
      memory: 256Mi
      # Максимальный объем временного хранилища, который будет выделен для контейнера
      ephemeral-storage: 256Mi
  # Настройка атрибутов безопасности
  securityContext:
    # UID, с которым будет запущен init контейнер с коннекторами
    runAsUser: null
    # GID, с которым будет запущен init контейнер с коннекторами
    runAsGroup: null


# Настройка sidecars приложения idmx-engine
sidecars:
  secman:
    # Вычислительные ресурсы, необходимые sidecar контейнеру secman
    resources:
      requests:
        # Количество ядер процессора, которое будет запрошено для контейнера
        cpu: 50m
        # Минимальный объем оперативной памяти, который будет запрошен для контейнера
        memory: 64Mi
        # Минимальный объем временного хранилища, который будет запрошен для контейнера
        ephemeralStorage: 128Mi
      limits:
        # Максимальное количество ядер процессора, которое будет выделено для контейнера
        cpu: 100m
        # Максимальный объем оперативной памяти, который будет выделен для контейнера
        memory: 128Mi
        # Максимальный объем временного хранилища, который будет выделен для контейнера
        ephemeralStorage: 256Mi
    # Настройка атрибутов безопасности
    securityContext:
      # UID, с которым будет запущен sidecar контейнер secman
      runAsUser: null
      # GID, с которым будет запущен sidecar контейнер secman
      runAsGroup: null
  fluent:
    # Вычислительные ресурсы, необходимые sidecar контейнеру fluent-bit
    resources:
      requests:
        # Количество ядер процессора, которое будет запрошено для контейнера
        cpu: 100m
        # Минимальный объем оперативной памяти, который будет запрошен для контейнера
        memory: 128Mi
        # Минимальный объем временного хранилища, который будет запрошен для контейнера
        ephemeral-storage: 128Mi
      limits:
        # Максимальное количество ядер процессора, которое будет выделено для контейнера
        cpu: 200m
        # Максимальный объем оперативной памяти, который будет выделен для контейнера
        memory: 256Mi
        # Максимальный объем временного хранилища, который будет выделен для контейнера
        ephemeral-storage: 256Mi
    # Настройка проверки готовности sidecar контейнера fluent-bit
    readinessProbe:
      # Количество секунд, которое должно пройти после запуска контейнера, прежде чем начнется проверка готовности
      initialDelaySeconds: 10
      # Интервал между последовательными проверками готовности
      periodSeconds: 5
      # Максимальное количество времени ожидания для каждой проверки готовности
      timeoutSeconds: 3
      # Количество последовательных успешных проверок, необходимых для того, чтобы считать контейнер готовым
      successThreshold: 1
      # Количество последовательных неудачных проверок, после которых контейнер считается неготовым
      failureThreshold: 3
    # Настройка проверки жизнеспособности sidecar контейнера fluent-bit
    livenessProbe:
      # Количество секунд, которое должно пройти после запуска контейнера, прежде чем начнется проверка жизнеспособности
      initialDelaySeconds: 15
      # Интервал между последовательными проверками жизнеспособности
      periodSeconds: 10
      # Максимальное количество времени ожидания для каждой проверки жизнеспособности
      timeoutSeconds: 3
      # Количество последовательных успешных проверок, необходимых для того, чтобы считать контейнер активным
      successThreshold: 1
      # Количество последовательных неудачных проверок, после которых контейнер считается неактивным
      failureThreshold: 3
    # Настройка атрибутов безопасности
    securityContext:
      # UID, с которым будет запущен sidecar контейнер fluent-bit
      runAsUser: null
      # GID, с которым будет запущен sidecar контейнер fluent-bit
      runAsGroup: null
  istio:
    # Вычислительные ресурсы, необходимые sidecar контейнеру istio
    resources:
      requests:
        # Количество ядер процессора, которое будет запрошено для контейнера
        cpu: 200m
        # Минимальный объем оперативной памяти, который будет запрошен для контейнера
        memory: 512Mi
      limits:
        # Максимальное количество ядер процессора, которое будет выделено для контейнера
        cpu: 200m
        # Максимальный объем оперативной памяти, который будет выделен для контейнера
        memory: 1Gi

Конфигурация idmx-ui#

Данный файл содержит параметры, относящиеся к idmx-ui. Файл расположен в директории /conf/helm/application/idmx/charts/idmx-ui/.

Список параметров:

# Количество реплик приложения idmx-ui
replicas: 1


# Вычислительные ресурсы, необходимые контейнеру idmx-ui
resources:
  requests:
    # Количество ядер процессора, которое будет запрошено для контейнера
    cpu: 250m
    # Минимальный объем оперативной памяти, который будет запрошен для контейнера
    memory: 512Mi
    # Минимальный объем временного хранилища, который будет запрошен для контейнера
    ephemeral-storage: 512Mi
  limits:
    # Максимальное количество ядер процессора, которое будет выделено для контейнера
    cpu: 500m
    # Максимальный объем оперативной памяти, который будет выделен для контейнера
    memory: 1Gi
    # Максимальный объем временного хранилища, который будет выделен для контейнера
    ephemeral-storage: 1Gi


# Настройка проверки готовности контейнера idmx-ui
readinessProbe:
  # Количество секунд, которое должно пройти после запуска контейнера, прежде чем начнется проверка готовности
  initialDelaySeconds: 10
  # Максимальное количество времени ожидания для каждой проверки готовности
  timeoutSeconds: 2
  # Интервал между последовательными проверками готовности
  periodSeconds: 10
  # Количество последовательных успешных проверок, необходимых для того, чтобы считать контейнер готовым
  successThreshold: 1
  # Количество последовательных неудачных проверок, после которых контейнер считается неготовым
  failureThreshold: 5
# Настройка проверки жизнеспособности контейнера idmx-ui
livenessProbe:
  # Количество секунд, которое должно пройти после запуска контейнера, прежде чем начнется проверка жизнеспособности
  initialDelaySeconds: 10
  # Максимальное количество времени ожидания для каждой проверки жизнеспособности
  timeoutSeconds: 2
  # Интервал между последовательными проверками жизнеспособности
  periodSeconds: 10
  # Количество последовательных успешных проверок, необходимых для того, чтобы считать контейнер активным
  successThreshold: 1
  # Количество последовательных неудачных проверок, после которых контейнер считается неактивным
  failureThreshold: 5


# Приоритет выполнения для idmx-ui в кластере
priorityClassName: null


# Настройка атрибутов безопасности
securityContext:
  # Устанавливает группу пользователей для всех файлов в томе, когда том монтируется в Pod
  fsGroup: null
  # UID, с которым будет запущен контейнер idmx-ui
  runAsUser: null
  # GID, с которым будет запущен контейнер idmx-ui
  runAsGroup: null


# Настройка sidecars приложения idmx-ui
sidecars:
  istio:
    # Вычислительные ресурсы, необходимые sidecar контейнеру istio
    resources:
      requests:
        # Количество ядер процессора, которое будет запрошено для контейнера
        cpu: 200m
        # Минимальный объем оперативной памяти, который будет запрошен для контейнера
        memory: 512Mi
      limits:
        # Максимальное количество ядер процессора, которое будет выделено для контейнера
        cpu: 200m
        # Максимальный объем оперативной памяти, который будет выделен для контейнера
        memory: 1Gi

Конфигурация idmx-connector-server#

Данный файл содержит параметры, относящиеся к idmx-connector-server. Файл расположен в директории /conf/helm/application/idmx/charts/idmx-connector-server/.

Список параметров:

# Количество реплик приложения idmx-connector-server
replicas: 1


# Определение пользовательского пути классов (class path) в среде исполнения
customClassPath: lib/asm-analysis-9.1.jar:lib/asm-commons-9.1.jar:/lib/asm-tree-9.1.jar:lib/asm-util-9.1.jar:lib/nashorn-core-15.3.jar:lib/ojdbc8.jar
# Путь до директории, в которую будут записываться журналы логов
logsPath: /app/idmx-connector-server/logs
# Уровень логирования для logback
logback:
  logLevel: INFO
# Дополнительные опции запуска для Java-машины
javaOptsExtra: "-Xmx500m"


# Настройка интеграции с Prometheus для idmx-connector-server
prometheus:
  # Параметр определяет, включен ли сбор данных Prometheus
  scrape: true
  # Порт, на котором Prometheus будет осуществлять сбор данных
  port: 9090
  # Путь, по которому Prometheus может получить данные
  path: /metrics


# Вычислительные ресурсы, необходимые контейнеру idmx-connector-server
resources:
  requests:
    # Количество ядер процессора, которое будет запрошено для контейнера
    cpu: 250m
    # Минимальный объем оперативной памяти, который будет запрошен для контейнера
    memory: 512Mi
    # Минимальный объем временного хранилища, который будет запрошен для контейнера
    ephemeral-storage: 512Mi
  limits:
    # Максимальное количество ядер процессора, которое будет выделено для контейнера
    cpu: 500m
    # Максимальный объем оперативной памяти, который будет выделен для контейнера
    memory: 1Gi
    # Максимальный объем временного хранилища, который будет выделен для контейнера
    ephemeral-storage: 1Gi


# Настройка проверки готовности контейнера idmx-connector-server
readinessProbe:
  # Количество секунд, которое должно пройти после запуска контейнера, прежде чем начнется проверка готовности
  initialDelaySeconds: 10
  # Максимальное количество времени ожидания для каждой проверки готовности
  timeoutSeconds: 2
  # Интервал между последовательными проверками готовности
  periodSeconds: 10
  # Количество последовательных успешных проверок, необходимых для того, чтобы считать контейнер готовым
  successThreshold: 1
  # Количество последовательных неудачных проверок, после которых контейнер считается неготовым
  failureThreshold: 5
# Настройка проверки жизнеспособности контейнера idmx-connector-server
livenessProbe:
  # Количество секунд, которое должно пройти после запуска контейнера, прежде чем начнется проверка жизнеспособности
  initialDelaySeconds: 10
  # Максимальное количество времени ожидания для каждой проверки жизнеспособности
  timeoutSeconds: 2
  # Интервал между последовательными проверками жизнеспособности
  periodSeconds: 10
  # Количество последовательных успешных проверок, необходимых для того, чтобы считать контейнер активным
  successThreshold: 1
  # Количество последовательных неудачных проверок, после которых контейнер считается неактивным
  failureThreshold: 5


# Приоритет выполнения для idmx-connector-server в кластере
priorityClassName: null


# Настройка атрибутов безопасности
securityContext:
  # Устанавливает группу пользователей для всех файлов в томе, когда том монтируется в Pod
  fsGroup: null
  # UID, с которым будет запущен контейнер idmx-connector-server
  runAsUser: null
  # GID, с которым будет запущен контейнер idmx-connector-server
  runAsGroup: null


# Настройка внешнего источника коннекторов IDMX для idmx-connector-server
initConnectorsLoad:
  # container - в случае использования init контейнер, download - в случае загрузки коннекторов из внешнего сервиса
  type: null
  # если type: container, указываем образ init контейнер; если type: download, указываем адрес внешнего ресурса
  source: null
  tries:
    # Количество попыток загрузить коннекторы из внешнего ресурса
    count: 15
    # Время ожидания в секундах, между попытками загрузить коннекторы из внешнего ресурса
    timeout: 3
  # Вычислительные ресурсы, необходимые init контейнеру
  resources:
    requests:
      # Количество ядер процессора, которое будет запрошено для контейнера
      cpu: 100m
      # Минимальный объем оперативной памяти, который будет запрошен для контейнера
      memory: 128Mi
      # Минимальный объем временного хранилища, который будет запрошен для контейнера
      ephemeral-storage: 128Mi
    limits:
      # Максимальное количество ядер процессора, которое будет выделено для контейнера
      cpu: 200m
      # Максимальный объем оперативной памяти, который будет выделен для контейнера
      memory: 256Mi
      # Максимальный объем временного хранилища, который будет выделен для контейнера
      ephemeral-storage: 256Mi
  # Настройка атрибутов безопасности
  securityContext:
    # UID, с которым будет запущен init контейнер с коннекторами
    runAsUser: null
    # GID, с которым будет запущен init контейнер с коннекторами
    runAsGroup: null


# Настройка sidecars приложения idmx-connector-server
sidecars:
  secman:
    # Вычислительные ресурсы, необходимые sidecar контейнеру secman
    resources:
      requests:
        # Количество ядер процессора, которое будет запрошено для контейнера
        cpu: 50m
        # Минимальный объем оперативной памяти, который будет запрошен для контейнера
        memory: 64Mi
        # Минимальный объем временного хранилища, который будет запрошен для контейнера
        ephemeralStorage: 128Mi
      limits:
        # Максимальное количество ядер процессора, которое будет выделено для контейнера
        cpu: 100m
        # Максимальный объем оперативной памяти, который будет выделен для контейнера
        memory: 128Mi
        # Максимальный объем временного хранилища, который будет выделен для контейнера
        ephemeralStorage: 256Mi
    # Настройка атрибутов безопасности
    securityContext:
      # UID, с которым будет запущен sidecar контейнер secman
      runAsUser: null
      # GID, с которым будет запущен sidecar контейнер secman
      runAsGroup: null
  fluent:
    # Вычислительные ресурсы, необходимые sidecar контейнеру fluent-bit
    resources:
      requests:
        # Количество ядер процессора, которое будет запрошено для контейнера
        cpu: 100m
        # Минимальный объем оперативной памяти, который будет запрошен для контейнера
        memory: 128Mi
        # Минимальный объем временного хранилища, который будет запрошен для контейнера
        ephemeral-storage: 128Mi
      limits:
        # Максимальное количество ядер процессора, которое будет выделено для контейнера
        cpu: 200m
        # Максимальный объем оперативной памяти, который будет выделен для контейнера
        memory: 256Mi
        # Максимальный объем временного хранилища, который будет выделен для контейнера
        ephemeral-storage: 256Mi
    # Настройка проверки готовности sidecar контейнера fluent-bit
    readinessProbe:
      # Количество секунд, которое должно пройти после запуска контейнера, прежде чем начнется проверка готовности
      initialDelaySeconds: 10
      # Интервал между последовательными проверками готовности
      periodSeconds: 5
      # Максимальное количество времени ожидания для каждой проверки готовности
      timeoutSeconds: 3
      # Количество последовательных успешных проверок, необходимых для того, чтобы считать контейнер готовым
      successThreshold: 1
      # Количество последовательных неудачных проверок, после которых контейнер считается неготовым
      failureThreshold: 3
    # Настройка проверки жизнеспособности sidecar контейнера fluent-bit
    livenessProbe:
      # Количество секунд, которое должно пройти после запуска контейнера, прежде чем начнется проверка жизнеспособности
      initialDelaySeconds: 15
      # Интервал между последовательными проверками жизнеспособности
      periodSeconds: 10
      # Максимальное количество времени ожидания для каждой проверки жизнеспособности
      timeoutSeconds: 3
      # Количество последовательных успешных проверок, необходимых для того, чтобы считать контейнер активным
      successThreshold: 1
      # Количество последовательных неудачных проверок, после которых контейнер считается неактивным
      failureThreshold: 3
    # Настройка атрибутов безопасности
    securityContext:
      # UID, с которым будет запущен sidecar контейнер fluent-bit
      runAsUser: null
      # GID, с которым будет запущен sidecar контейнер fluent-bit
      runAsGroup: null
  istio:
    # Вычислительные ресурсы, необходимые sidecar контейнеру istio
    resources:
      requests:
        # Количество ядер процессора, которое будет запрошено для контейнера
        cpu: 200m
        # Минимальный объем оперативной памяти, который будет запрошен для контейнера
        memory: 512Mi
      limits:
        # Максимальное количество ядер процессора, которое будет выделено для контейнера
        cpu: 200m
        # Максимальный объем оперативной памяти, который будет выделен для контейнера
        memory: 1Gi

Конфигурация idmx-egress-gateway#

Данный файл содержит параметры, относящиеся к idmx-egress-gateway. Файл расположен в директории /conf/helm/application/idmx/charts/idmx-egress-gateway/.

Список параметров:

# Количество реплик приложения idmx-egress-gateway
replicas: 1


# Настройка маршрутов до системной БД idmx-engine, при использовании Istio
repository:
  database:
    # Тип определения FQDN узла системной БД
    resolution: DNS
    audit:
      # Тип определения FQDN узла системной БД с аудитом
      resolution: DNS


# Настройка маршрутов до Platform V SOWA, при использовании Istio
sowa:
  enabled: false
  # Имя хоста Platform V SOWA
  host: sowa-hostname
  # IP-адрес клиента Platform V SOWA
  ip: 127.0.0.1
  # Порт клиента Platform V SOWA
  port: 13409


# Настройка маршрутов до Secret Management, при использовании Istio
secman:
  # Имя хоста Secret Management
  host: secman-hostname
  # Порт Secret Management
  port: 443
  # Протокол общения с Secret Management
  protocol: TLS


# Настройка горизонтального масштабирования (Horizontal Pod Autoscaling - HPA) для приложения idmx-egress-gateway
hpa:
  enabled: false
  # Минимальное количество реплик (pod), которые должны быть запущены
  minReplicas: 1
  # Максимальное количество реплик (pod), которые горизонтальное масштабирование может создать
  maxReplicas: 2
  # Целевое значение использования CPU, в процентах. При превышении данного значения (повышении загрузки процессора), HPA будет увеличивать количество реплик
  targetCPUUtilizationPercentage: 80


# Вычислительные ресурсы, необходимые контейнеру idmx-egress-gateway
resources:
  requests:
    # Количество ядер процессора, которое будет запрошено для контейнера
    cpu: 200m
    # Минимальный объем оперативной памяти, который будет запрошен для контейнера
    memory: 256Mi
    # Минимальный объем временного хранилища, который будет запрошен для контейнера
    ephemeral-storage: 512Mi
  limits:
    # Максимальное количество ядер процессора, которое будет выделено для контейнера
    cpu: 400m
    # Максимальный объем оперативной памяти, который будет выделен для контейнера
    memory: 512Mi
    # Максимальный объем временного хранилища, который будет выделен для контейнера
    ephemeral-storage: 1Gi


# Настройка проверки готовности контейнера idmx-egress-gateway
readinessProbe:
  # Количество секунд, которое должно пройти после запуска контейнера, прежде чем начнется проверка готовности
  initialDelaySeconds: 1
  # Максимальное количество времени ожидания для каждой проверки готовности
  timeoutSeconds: 1
  # Интервал между последовательными проверками готовности
  periodSeconds: 2
  # Количество последовательных успешных проверок, необходимых для того, чтобы считать контейнер готовым
  successThreshold: 1
  # Количество последовательных неудачных проверок, после которых контейнер считается неготовым
  failureThreshold: 30
# Настройка проверки жизнеспособности контейнера idmx-egress-gateway
livenessProbe:
  # Количество секунд, которое должно пройти после запуска контейнера, прежде чем начнется проверка жизнеспособности
  initialDelaySeconds: 30
  # Максимальное количество времени ожидания для каждой проверки жизнеспособности
  timeoutSeconds: 1
  # Интервал между последовательными проверками жизнеспособности
  periodSeconds: 5
  # Количество последовательных успешных проверок, необходимых для того, чтобы считать контейнер активным
  successThreshold: 1
  # Количество последовательных неудачных проверок, после которых контейнер считается неактивным
  failureThreshold: 6


# Приоритет выполнения для idmx-egress-gateway в кластере
priorityClassName: null


# Настройка атрибутов безопасности
securityContext:
  # Устанавливает группу пользователей для всех файлов в томе, когда том монтируется в Pod
  fsGroup: null
  # UID, с которым будет запущен контейнер idmx-egress-gateway
  runAsUser: null
  # GID, с которым будет запущен контейнер idmx-egress-gateway
  runAsGroup: null


# Настройка sidecars приложения idmx-egress-gateway
sidecars:
  secman:
    # Вычислительные ресурсы, необходимые sidecar контейнеру secman
    resources:
      requests:
        # Количество ядер процессора, которое будет запрошено для контейнера
        cpu: 50m
        # Минимальный объем оперативной памяти, который будет запрошен для контейнера
        memory: 64Mi
        # Минимальный объем временного хранилища, который будет запрошен для контейнера
        ephemeralStorage: 128Mi
      limits:
        # Максимальное количество ядер процессора, которое будет выделено для контейнера
        cpu: 100m
        # Максимальный объем оперативной памяти, который будет выделен для контейнера
        memory: 128Mi
        # Максимальный объем временного хранилища, который будет выделен для контейнера
        ephemeralStorage: 256Mi
    # Настройка атрибутов безопасности
    securityContext:
      # UID, с которым будет запущен sidecar контейнер secman
      runAsUser: null
      # GID, с которым будет запущен sidecar контейнер secman
      runAsGroup: null

Конфигурация idmx-ingress-gateway#

Данный файл содержит параметры, относящиеся к idmx-ingress-gateway. Файл расположен в директории /conf/helm/application/idmx/charts/idmx-ingress-gateway/.

Список параметров:

# Количество реплик приложения idmx-ingress-gateway
replicas: 1


# Настройка входящих маршрутов
# Возможные режимы использования tlsmode:
# SIMPLE - TLS соединение с валидацией сертификата сервера, сертифкат клиента не запрашивается
# MUTUAL - TLS соединение с валидацией сертифката сервера и клиента
ingress:
  idmxEngine:
    # Определяет режим использования TLS для Ingress idmx-engine
    tlsmode: SIMPLE
  idmxConnectorServer:
    # Определяет режим использования TLS для Ingress idmx-connector-server
    tlsmode: SIMPLE
  idmxUi:
    # Определяет режим использования TLS для Ingress idmx-ui
    tlsmode: SIMPLE


# Настройка создания envoy filter для входящего трафика, которые будут использоваться для дополнения интеграции с Platform V IAM
envoyFilter:
  rbacFilter:
    # Включает или выключает создание фильтра с разграничением доступа к UI и API
    enabled: false
    # Строка в SAN сертификата, которая будет использоваться для предоставления доступа к API
    apiAccessCertString: .*apiaccesscert*
    # Строка в SAN сертификата, которая будет использоваться для предоставления доступа к UI
    uiAccessCertString: .*iamcert.*
    # Префикс для Ui
    uiPrefix: /idm
  ivUserFilter:
    # Включает или выключает создание фильтра с добавлением заголовка "x-client-subject" 
    enabled: false
    # Целевое значение HTTP-заголовка, которое используется Platform V IAM для аутентификации пользователей.
    # На его основе будет создан заголовок x-client-subject (с добавленной строкой "C:")
    httpHeader: iv-user


# Вычислительные ресурсы, необходимые контейнеру idmx-ingress-gateway
resources:
  requests:
    # Количество ядер процессора, которое будет запрошено для контейнера
    cpu: 200m
    # Минимальный объем оперативной памяти, который будет запрошен для контейнера
    memory: 256Mi
    # Минимальный объем временного хранилища, который будет запрошен для контейнера
    ephemeral-storage: 512Mi
  limits:
    # Максимальное количество ядер процессора, которое будет выделено для контейнера
    cpu: 400m
    # Максимальный объем оперативной памяти, который будет выделен для контейнера
    memory: 512Mi
    # Максимальный объем временного хранилища, который будет выделен для контейнера
    ephemeral-storage: 1Gi


# Настройка проверки готовности контейнера idmx-ingress-gateway
readinessProbe:
  # Количество секунд, которое должно пройти после запуска контейнера, прежде чем начнется проверка готовности
  initialDelaySeconds: 1
  # Максимальное количество времени ожидания для каждой проверки готовности
  timeoutSeconds: 1
  # Интервал между последовательными проверками готовности
  periodSeconds: 2
  # Количество последовательных успешных проверок, необходимых для того, чтобы считать контейнер готовым
  successThreshold: 1
  # Количество последовательных неудачных проверок, после которых контейнер считается неготовым
  failureThreshold: 30
# Настройка проверки жизнеспособности контейнера idmx-ingress-gateway
livenessProbe:
  # Количество секунд, которое должно пройти после запуска контейнера, прежде чем начнется проверка жизнеспособности
  initialDelaySeconds: 30
  # Максимальное количество времени ожидания для каждой проверки жизнеспособности
  timeoutSeconds: 1
  # Интервал между последовательными проверками жизнеспособности
  periodSeconds: 5
  # Количество последовательных успешных проверок, необходимых для того, чтобы считать контейнер активным
  successThreshold: 1
  # Количество последовательных неудачных проверок, после которых контейнер считается неактивным
  failureThreshold: 6


# Приоритет выполнения для idmx-ingress-gateway в кластере
priorityClassName: null


# Настройка атрибутов безопасности
securityContext:
  # Устанавливает группу пользователей для всех файлов в томе, когда том монтируется в Pod
  fsGroup: null
  # UID, с которым будет запущен контейнер idmx-ingress-gateway
  runAsUser: null
  # GID, с которым будет запущен контейнер idmx-ingress-gateway
  runAsGroup: null


# Настройка sidecars приложения idmx-ingress-gateway
sidecars:
  secman:
    # Вычислительные ресурсы, необходимые sidecar контейнеру secman
    resources:
      requests:
        # Количество ядер процессора, которое будет запрошено для контейнера
        cpu: 50m
        # Минимальный объем оперативной памяти, который будет запрошен для контейнера
        memory: 64Mi
        # Минимальный объем временного хранилища, который будет запрошен для контейнера
        ephemeralStorage: 128Mi
      limits:
        # Максимальное количество ядер процессора, которое будет выделено для контейнера
        cpu: 100m
        # Максимальный объем оперативной памяти, который будет выделен для контейнера
        memory: 128Mi
        # Максимальный объем временного хранилища, который будет выделен для контейнера
        ephemeralStorage: 256Mi
    # Настройка атрибутов безопасности
    securityContext:
      # UID, с которым будет запущен sidecar контейнер secman
      runAsUser: null
      # GID, с которым будет запущен sidecar контейнер secman
      runAsGroup: null

Установка Connector Server#

Обратите внимание!

Установка данного компонента необязательна. Он используется в ситуациях, когда по какой-либо причине idmx-engine не может напрямую подключаться к управляемым им ресурсам. Например, если idmx-engine находится в другом контуре сети, или требования информационной безопасности запрещают такое подключение.

В таких ситуациях можно установить и подключить компонент Connector Server в том сегменте сети, где расположены управляемые ресурсы, и производить подключение от idmx-engine к Connector Server для обеспечения безопасности или проксирования запроса между разными контурами.

Компонент idmx-connector-server (далее Connector Server) предназначен для подключения IDMX к ресурсам, расположенным вне контура, в котором находится инсталляция IDMX. Connector Server устанавливается на сервер или виртуальную машину с ОС на базе Linux (рекомендуется ОС Alt 8 СП), либо с ОС Windows 10 (опционально).

Пререквизиты:

  1. Установлен OpenJDK версии не ниже 11.

  2. В переменные среды добавлена переменная JAVA_HOME.

Установка:

  1. Скопируйте из дистрибутива с бинарными файлами IDMX на сервер файл idmx-connector-server.zip, расположенный в директории дистрибутива <distrib>/bh/.

  2. Разархивируйте скопированный архив idmx-connector-server.zip в директорию idmx-connector-server.

  3. Если в директории <server>/idmx-connector-server/connid-connector-server/lib/ есть файл connector-common-1.5.0.0.jar, удалите его.

  4. Откройте командную строку (консоль), перейдите в директорию connid-connector-server и выполните следующую команду:

    • Если ОС — Альт 8 СП или Linux: bin/ConnectorServer.sh -setKey -key <SECRET_KEY> -properties conf/connectorserver.properties;

    • Если ОС — Windows 10: .\bin\ConnectorServer.bat /setkey <SECRET_KEY> /properties .\conf\connectorserver.properties;

      , где <SECRET_KEY> — ключ доступа (пароль) для подключения IDMX к Connector Server. При выборе ключа доступа руководствуйтесь требованиями кибербезопасности к паролям. Рекомендуется избегать спецсимволов в ключе доступа, так как могут возникнуть проблемы с подключением.

После выполнения шагов выше, Connector Server будет установлен. Затем, перед использованием, необходимо провести его настройку.

Настройка Connector Server#

Connector Server поддерживает работу как по стандартному HTTP протоколу через Web Socket, так и по HTTPS с защитой через TLS 1.2.

Для настройки Connector Server следует:

  • Для работы по HTTP через Web Socket:

  1. Откройте файл <server>/idmx-connector-server/connid-connector-server/conf/connectorserver.propertiesи внесите следующие изменения:

    • connectorserver.protocol=WEB_SOCKET

    • connectorserver.port=<порт, по которому будет доступен Connector Server>

  2. Откройте файл <server>/idmx-connector-server/connid-connector-server/lib/logback.xml, найдите в нем строку <root level="debug">, замените значение параметра с debug на info и сохраните изменения.

  • Для работы по HTTP с защитой TLS 1.2:

  1. Получите от администраторов или создайте хранилище ключей с соответствующими требованиям кибербезопасности серверными сертификатами для подключения IDMX к Connector Server по TLS. Для создания хранилища вручную:

    1. Получите серверные сертификаты connectorserver.crt, connectorserver.key и rootCA.crt от администраторов удостоверяющего центра, отвечающих за сегмент сети, в котором расположена машина с Connector Server.

    2. Объедините сертификаты в единое хранилище ключей в формате pkcs12. Для сборки вам потребуется утилита openssl. Перейдите в командной строке в директорию с сертификатами и выполните команду:

      openssl pkcs12 -export -in connectorserver.crt -inkey connectorserver.key -out connectorserver.p12 -name connhost -CAfile rootCA.crt -caname root

      , где:

      -in — файл сертификата, добавляемого в хранилище;

      -inkey — файл приватного ключа сертификата, добавляемого в хранилище;

      -out — имя генерируемого хранилища в формате pkcs12;

      -name — краткое имя (alias) для пары сертификат-приватный ключ;

      -CAfile — файл корневого сертификата удостоверяющего центра (CA);

      -caname — краткое имя (alias) корневого сертификата.

    3. При генерации утилита запросит ввод пароля, например changeit, для защиты генерируемого хранилища. Запомните или запишите этот пароль. При формировании пароля учитывайте рекомендации по заданию стойких паролей (смотрите раздел Доступ к приложению Руководства оператора).

    4. Зашифруйте созданное хранилище при помощи утилиты keytool следующей командой:

      keytool -importkeystore -deststorepass changeit -destkeypass changeit -destkeystore connector.jks -srckeystore connectorserver.p12 -srcstoretype PKCS12 -srcstorepass changeit

      , где:

      -deststorepass — пароль от генерируемого зашифрованного хранилища;

      -destkeypass — пароль для доступа к приватному ключу (connectorserver.key) в генерируемом зашифрованном хранилище;

      -destkeystore — имя генерируемого зашифрованного хранилища;

      -srckeystore — имя хранилища в формате pkcs12, которое шифруется;

      -srcstoretype — тип (формат) хранилища, которое шифруется;

      -srcstorepass — пароль от хранилища в формате pkcs12, которое шифруется.

  2. Откройте файл <server>/idmx-connector-server/connid-connector-server/conf/connectorserver.properties и внесите следующие изменения:

    • connectorserver.usessl=true

    • connectorserver.protocol=WEB_SOCKET

    • connectorserver.port=<порт, по которому будет доступен Connector Server>

  3. Сохраните изменения в connectorserver.properties.

  4. В директории <server>/idmx-connector-server/connid-connector-server/ и скорректируйте файлы запуска:

    • Для Альт 8 СП (Linux): найдите файл ConnectorServer.sh и внесите в него следующие изменения:

      • В строке java -Xmx500m -Dlogback.configurationFile=lib/logback.xml -classpath "$CLASSPATH" \ добавьте в строку перед параметром -classpath "$CLASSPATH" \ переменные -Djavax.net.ssl.keyStore=bin\connector.jks -Djavax.net.ssl.keyStoreType=jks -Djavax.net.ssl.keyStorePassword=changeit, где:

        -Djavax.net.ssl.keyStore — путь к хранилищу ключей, используемом для TLS подключения, относительно директории connid-connector-server;

        -Djavax.net.ssl.keyStoreType — тип хранилища ключей (возможные варианты — jks, jceks);

        -Djavax.net.ssl.keyStorePassword — пароль для доступа к хранилищу ключей.

    • Для Windows 10: найдите файл ConnectorServer.bat и внесите в него следующие изменения:

      • В строке set JAVA_OPTS=-Xmx500m "-Djava.util.logging.config.file=conf\logging.properties" "-Dlogback.configurationFile=lib\logback.xml" добавьте в конец строки переменные "-Djavax.net.ssl.keyStore=bin\connector.jks" "-Djavax.net.ssl.keyStoreType=jks" "-Djavax.net.ssl.keyStorePassword=changeit", где:

        -Djavax.net.ssl.keyStore — путь к хранилищу ключей, используемом для TLS подключения, относительно директории connid-connector-server;

        -Djavax.net.ssl.keyStoreType — тип хранилища ключей (возможные варианты — jks, jceks);

        -Djavax.net.ssl.keyStorePassword — пароль для доступа к хранилищу ключей.

  5. Откройте файл <server>/idmx-connector-server/connid-connector-server/lib/logback.xml, найдите в нем строку <root level="debug">, замените значение параметра с debug на info и сохраните изменения.

Запуск Connector Server#

Для запуска Connector Server откройте командную строку, перейдите в директорию <server>/idmx-connector-server/connid-connector-server и выполните команду:

  • Если ОС — Альт 8 СП или Linux: bin/ConnectorServer.sh -run -properties conf/connectorserver.properties;

  • Если ОС — Windows 10: .\bin\ConnectorServer.bat /run /properties .\conf\connectorserver.properties.

Если запуск успешен, в консоли командной строки будет отражена строка вида o.i.f.s.tcp.ConnectorServerImpl - Connector Server started at <дата> <время>. После этого окно командной строки нельзя закрывать, так как это завершит работу Connector Server.

Проверка подключения по TLS#

Если Connector Server был сконфигурирован для подключения по TLS, следует проверить, что настройка была проведена корректно. Для этого:

  • На Альт 8 СП (Linux):

    1. На другой машине в сети, имеющей подключение к серверу с Connector Server, откройте коммандную строку (терминал), и выполните команду echo | openssl s_client -showcerts -connect connectorserver.mynet.ru:8759 2>/dev/null | openssl x509 -inform pem -noout -text, где:

      -connect — FQDN и порт, по которым доступен Connector Server.

    2. Команда сделает запрос к Connector Server и вернет информацию о сертификате, которым защищен Connector Server. Например:

      Certificate:
    Data:
        Version: 3 (0x2)
    Signature Algorithm: ecdsa-with-SHA256
        Issuer: O=my.org, CN=my.org Intermediate CA
        Validity
            Not Before: Nov 16 08:57:32 2022 GMT
            Not After : Nov 16 08:58:32 2023 GMT
        Subject: CN=connectorserver.mynet.ru
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)

    3. Настройка TLS будет корректной, если:

      1. От сервера с Connector Server был возвращен ответ;

      2. В ответ на команду сервер предлагает сертификат;

      3. CN, указанный в Certificate:Signature:Subject сертификате, равен FQDN сервера.

  • На Windows 10:

    1. Перейдите по адресу https://connectorserver.mynet.ru:8759 (URL и порт, на которых развернут Connector Server) в любом браузере.

    2. На вкладке должна открыться страница с фразой 404 WebSocket Upgrade Failure.

    3. Настройка TLS будет корректной, если:

      1. Средства браузера подтверждают, что подключение к данной странице защищено по протоколу TLS 1.2 (даже если выводится сообщение, что сертификат недоверенный).

      2. При просмотре сертификата инструментами браузера, удостоверяющий центр соответствует удостоверяющему центру, выдавшему сертификаты, использованные для создания keystore Connector Server.

Импорт конфигурации Connector Server в IDMX#

Чтобы IDMX мог использовать установленный и запущенный Connector Server, необходимо добавить конфигурацию этого компонента в IDMX. Для этого:

  1. Перейдите в любое IDE или текстовый редактор с возможностью создания xml-файлов.

  2. Создайте новый файл и вставьте в него следующий XML код, заменив соответствующие значения параметров значениями для своих стендов:

    <connectorHost xmlns="http://midpoint.evolveum.com/xml/ns/public/common/common-3" xmlns:t="http://prism.evolveum.com/xml/ns/public/types-3" xmlns:protocol="http://midpoint.evolveum.com/xml/ns/public/connector-host-protocol-extension" oid="d7c941c0-1cf4-4fe7-b231-32e1a1c40bcf">

    <name>My local connector</name> <!--- имя создаваемой конфигурации в IDMX -->
    <hostname>localhost</hostname> <!--- имя хоста на котором развернут Connector Server -->
    <port>9999</port> <!--- порт для подключения к Connector Server -->
    <sharedSecret>
        <t:clearValue>admin</t:clearValue> <!--- укажите здесь то же значение, которое было задано как ключ доступа к Connector Server во время установки -->
    </sharedSecret>
    <protectConnection>true</protectConnection> <!--- false, если для соединения не используется TLS -->
    <extension>
        <protocol:connectionProtocol>WEB_SOCKET</protocol:connectionProtocol>
        <protocol:path>/</protocol:path>
    </extension>

</connectorHost>

  3. Сохраните файл в файловую систему сервера.

  4. Войдите в UI установленной инсталляции IDMX.

  5. Импортируйте созданный файл согласно инструкции из документа Руководство оператора, раздел Параметры настройки, подраздел Импорт конфигурационных файлов.

Интеграции с платформенными зависимостями#

Интеграция с Secret Management System#

Secret Management System следует настраивать согласно документации на этот продукт. После установки и настройки SecMan следует провести его подготовку для использования с IDMX следующим образом:

  1. Завести хранилище KV (key-value). Хранилище должно быть типа "KV хранилище".

    Тип: "kv" — версия 1 движка Key-Value, соответствует пути KV.

    Пример пути: ACC/IDMX/FH/KV.

  2. Получить роль, тенант (namespace).

  3. Дать доступ роли из namespace контейнеризированной среды в Secret Management.

  4. Загрузить секреты и сертификаты в Secret Management по пути из пункта 1 в подпапку KEYSTORE (значения в кодировке Base64). Итоговый путь к расположению сертификатов в Secret Management будет выглядеть, например, так: ACC/IDMX/FH/KV/KEYSTORE.

    Подробнее о кодировании в base64 и загрузке секретов и сертификатов будет рассказано в инструкции в разделе Установка IDMX.

  5. Заполнить параметры в конфигурационном файле values.yaml

    • global.secman.enabled = true;

    • global.secman.mountPath = например, auth/kubernetes;

    • global.secman.namespace = путь до namespace SecMan, например, DEV_IDMX;

    • global.secman.role = например, role-secman-idmx;

    • global.secman.url = URL SecMan, например, https://secman-hostname:443;

    • global.secman.key = например, A/DEV/IDMX/KV/DEV.

Обратите внимание — настройки интеграции при использовании аналога SecMan — Hashicorp Vault — идентичны.

Интеграция с Platform V SOWA#

Продукт Platform V SOWA следует настраивать согласно документации на этот продукт. После установки и настройки компонента KMSS следует провести его подготовку для использования с IDMX следующим образом:

  1. Создать профиль через команду администрирования инсталляции SOWA. В заявке на создание профиля следует указать следующую информацию:

    • Протокол — WebSocket;

    • От — кластера IDMX;

    • До — Connector Server (в другом сегменте).

  2. В vault Secret Management System поместить необходимые сертификаты для SOWA (подробнее смотрите в разделе Установка IDMX).

Интеграция с Platform V Audit SE#

Продукт Platform V Audit SE следует настраивать согласно документации на этот продукт. После установки и настройки компонента KMSS следует провести его подготовку для использования с IDMX следующим образом:

  1. Получить URL эндпоинта Platform V Audit SE, на который следует отправлять сообщения.

  2. В конфигурационном файле values.yaml указать данный host в global.audit.host, ip в global.audit.ip, port в global.audit.port и выставить параметр global.audit.enabled в true (подробнее смотрите в разделе Установка IDMX).

Интеграция с Platform V Monitor#

Мониторинг#

Компонент MONA продукта Platform V Monitor следует настраивать согласно документации на этот продукт. После установки и настройки Secret Management System следует провести его подготовку для использования с IDMX следующим образом:

  1. Установить параметр idmx-engine.prometheus.scrape конфигурационного файла values.yaml IDMX в true.

  2. На стороне компонента MONA продукта Platform V Monitor настроить сбор метрик с эндпоинта IDMX. URL эндпоинта составляется из Route компонента idmx-engine, значения параметра idmx-engine.prometheus.path и порта из параметра idmx-engine.prometheus.port конфигурационного файла values.yaml. Например:

    https://idm.my-openshift-namespace.mydomain.ru//midpoint/actuator/prometheus:8080

  3. Для визуализации метрик, полученных с эндпоинта IDMX, необходимо создать dashboard Grafana, или другого инструмента визуализации, согласно документации на компонент MONA продукта Platform V Monitor.

Логирование#

Компонент LOGA продукта Platform V Monitor следует настраивать согласно документации на этот продукт. После установки и настройки компонента LOGA следует провести его подготовку для использования с IDMX следующим образом:

  1. Заполнить параметры связанные с интеграцией в конфигурационном файле values.yaml (параметры группы global.fluent);

  2. Для визуализации журналов, необходимо создать dashboard согласно документации на компонент LOGA продукта Platform V Monitor.

Интеграция с Platform V IAM SE#

Компонент AUTH продукта Platform V IAM SE следует настраивать согласно документации на этот продукт. После установки и настройки компонента AUTH следует провести его подготовку для использования с IDMX следующим образом:

  1. Согласно документации на Platform V IAM SE, необходимо прописать locations для переадресации системы авторизации.

  2. Выпустить корректные сертификаты Istio Ingress для компонентов IDMX, получить CA сертификат, используемый компонентом AUTH, и добавить все сертификаты в используемое хранилище секретов (смотрите пункты 9 и 10 инструкции по установке IDMX, раздел Установка IDMX)

  3. Убедиться, что CA, которым подписаны сертификаты Istio Ingress, используемые IDMX (istio_ingress_engine_cert, istio_ingress_engine_key, istio_ingress_ui_cert, istio_ingress_ui_key), является доверенным для компонента AUTH. При необходимости добавить данный CA в список доверенных для AUTH.

  4. В конфигурацонном файле values.yaml для параметра idmx-ingress-gateway.ingress.tlsmode укажите значение MUTUAL.

  5. Убедиться, что доступен настроенный согласно документации совместимый с компонентом AUTH провайдер аутентификации/авторизации (в тестировании использовался компонент KCSE продукта Platform V IAM SE).

  6. В компоненте KCSE создать требуемые учетные записи.

  7. В IDMX создать учетные карточки пользователей, котоыре будут аутентифицироваться в UI IDMX через Platform V IAM SE, с теми же логинами, что и у созданных в KCSE учетных записей.

  8. Импортировать в IDMX политику безопасности 004-security-policy.xml, которая включает интеграцию с Platform V IAM SE для аутентификации пользователей.

Интеграция с Platform V Synapse Service Mesh#

Для установки IDMX с интеграцией с Istio следует установить Platform V Synapse Mesh согласно документации на продукт SSM. Затем следует:

  1. Поместить все требуемые сертификаты в vault Secret Management System или в Kubernetes Secrets (подробнее смотрите в разделе Установка IDMX).

  2. Заполнить конфигурационный файл values.yaml корректными значениями.