Установка через 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).

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

Настройка внешнего источника коннекторов IDMX для idmx-engine#

В IDM есть возможность подключить внешние коннекторы и схемы из заранее созданного образа контейнера.

Для создания образа с внешними коннекторами и схемой следует:

  1. Создать папку с произвольным названием, например, init-container:

    # mkdir init-container

  2. Создать в этой папке директорию files, а в ней директории connectors и schema:

    # cd init-container
# mkdir files
# cd files
# mkdir connectors schema

  3. Скопировать требуемую схему в папку init-container/files/schema, а коннекторы — в папку init-container/files/connectors.

  4. Создать dockerfile следующего содержания:

    FROM mydomain.ru/base/docker.io/busybox:1.36.1-uclibc

COPY --chmod=0644 ./files/connectors/*.jar /connectors/
COPY --chmod=0644 ./files/schema/* /schema/

    , где mydomain.ru/base/docker.io/busybox:1.36.1-uclibc — любой образ, содержащий минимальный набор утилит для запуска, например scratch или busybox.

  5. Собрать образ следующей командой:

    # docker build -t mydomain.ru/dev/<ВАША_ОБЛАСТЬ>/idmx-init-container:testing .

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

    Название и путь образа следует выбрать в зависимости от ваших областей в Nexus.

  6. Отправить (push) собранный образ в Docker Registry:

    # docker push mydomain.ru/dev/<ВАША_ОБЛАСТЬ>/idmx-init-container:testing

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

    idmx-engine:


initConnectorsLoad:
type: "container"
source: "mydomain.ru/dev/<ВАША_ОБЛАСТЬ>/idmx-init-container:testing"

    idmx-connector-server:



initConnectorsLoad:
type: "container"
source: "mydomain.ru/dev/<ВАША_ОБЛАСТЬ>/idmx-init-container:testing"

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

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

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

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

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

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

      CREATE USER idm_user WITH PASSWORD 'password' LOGIN SUPERUSER;

      , где 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>/idmx-dbinit-<версия>-distrib.zip/package/db/idmx-dbinit-engine.zip.

Подготовка БД вручную при отсутствии прав 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

    2. postgres-new-audit.sql

    3. postgres-new-quartz.sql

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

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

Автоматическая настройка БД при помощи 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>.

        • idm_engine_repository_db_audit_password = <пароль учетной записи пользователя, которая будет использоваться для записи данных аудита в отдельную БД, если используется db_separated>

        • idm_engine_repository_db_audit_username = <имя пользователя, который будет использоваться для записи данных аудита в отдельную БД, если используется db_separated>

      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>".

      • "idm_engine_repository_db_audit_password": "<пароль учетной записи пользователя, которая будет использоваться для записи данных аудита в отдельную БД, если используется db_separated>"

      • "idm_engine_repository_db_audit_username": "<имя пользователя, который будет использоваться для записи данных аудита в отдельную БД, если используется db_separated>"

      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 — пространство имен, в котором расположен 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 — пространство имен, в котором расположен 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.

Ручной запуск Liquibase скриптов для настройки БД#

Также Liquibase скрипты можно запустить вручную. Liquibase написан на Java, поэтому может быть запущен на машине с предустановленной JAVA (рекомендуется OpenJDK 11).

Для ручного запуска Liquibase скриптов:

  1. Разархивируйте архив расположенный по пути:

    idmx-bin-<версия>-distrib/db/idmx-db-liquibase-engine.zip

  2. В директорию с разархивированными файлами необходимо добавить следующие файлы из дистрибутива:

    • liquibase-core-4.8.0.jar - исполняемый файл Liquibase.

    • picocli-4.7.5.jar - необходимые для работы библиотеки.

    • postgresql-42.7.3.jar - драйвер postgresql.

    • snakeyaml-2.2.jar - необходимые для работы библиотеки.

    Их расположение можно определить в файле Report.json, расположенному по пути /idm-<версия>>-owned-distrib/Report.json.

  3. Разместите все файлы в одной директории, чтобы получилось следующее:

    0001_changelog.xml  
audit  
base  
liquibase-core-4.8.0.jar  
liquibase.properties  
picocli-4.7.5.jar  
postgresql-42.7.3.jar  
quartz  
README.md  
snakeyaml-2.2.jar

  4. Выполните запуск скриптов следующей командой:

     java -cp "liquibase-core-4.8.0.jar:picocli-4.7.5.jar:snakeyaml-2.2.jar:postgresql-42.7.3.jar" \
 liquibase.integration.commandline.LiquibaseCommandLine \
 --driver=org.postgresql.Driver \
 --url="jdbc:postgresql://mynamespace.mydomain.ru:1111/liquibase_test" <указать URL БД>\
 --username=idmx_user \
 --password=<пароль для доступа к БД> \
 --changeLogFile=0001_changelog.xml \
 --defaultSchemaName=idm_schema \
 update
Миграция с использованием Liquibase через Kubernetes job#

Миграцию БД также можно выполнить с помощью Kubernetes job.

Конфигурация задается в корневом файле конфигурации values.yaml в разделе liquibase. Параметры баз данных для миграции задаются в разделах engine.database и datapipe.database.

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

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

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

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

  1. Остановить idmx-engine в пространстве имен 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. Создание полной резервной копии базы (на случай непредвиденных ситуаций).

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

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

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

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

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

  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. Получить роль, тенант (пространство имен).

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

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

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

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

Для корректной работы автоматической ротации сертификатов при их выпуске через Secret Management System, требуется:

  1. Настроить и выпустить корректные сертификаты, согласно документации на Secret Management System.

  2. Заполнить в корневом файле конфигурации группу параметров secman.pkiSecretsEngine.

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

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

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

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

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

Последовательность действий#

Установка 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:

        • engine.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;

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

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

        • secman.enabled = true;

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

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

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

        • ``secman.hostиsecman.port= URL SecMan, например,»secman-hostname»и443` соответственно;

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

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

    Значение параметра engine.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.

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

    В параметре engine.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 параметр serviceMesh.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). Подробнее смотрите далее в инструкции.

    Генерируемый ключ в данном случае имеет алиас 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_connector_server_cert и istio_ingress_connector_server_key для idmx-connector-server;

      • istio_ingress_ui_cert и istio_ingress_ui_key для idmx-ui.

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

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

      • istio_ingress_engine_ca для idmx-engine;

      • istio_ingress_connector_server_ca для idmx-connector-server;

      • istio_ingress_ui_ca для idmx-ui.

  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=dGVzdF90b2tlbl8xMjM0NTY3OA==.

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

      • Сертификаты для интеграции с компонентом 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_connector_server_cert -in istio_ingress_connector_server_cert -inkey istio_ingress_connector_server_key -out istio_ingress_connector_server_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_connector_server_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_connector_server_ca -file istio_ingress_connector_server_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

      • Сертификаты для режима распределенного кластера (если используется, подробнее смотрите раздел Режим распределенного кластера):

        1. openssl pkcs12 -export -name istio_ingress_engine_cnb_cert -in istio_ingress_engine_cnb_cert -inkey istio_ingress_engine_cnb_key -out istio_ingress_engine_cnb_p12

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

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

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

      Значения алиасов сертификатов и имя 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), переведите переменную serviceMesh.enabled в true.

Проверка результата#

Установку IDMX можно считать успешной, если:

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

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

  3. БД доступна по порту (по умолчанию 5432) из кластера системы оркестрации контейнеризированных приложений.

  4. Созданы docker-образы idmx-engine, idmx-ui, idmx-connector-server (раздел Установка через Installer, подраздел Сборка образов IDMX).

  5. Выделен проект системы оркестрации контейнеризированных приложений.

  6. Произведена настройка проекта системы оркестрации контейнеризированных приложений согласно документации на используемую систему оркестрации.

  7. Произведена первоначальная настройка БД (раздел Установка через Installer, подраздел Подготовка системной БД).

  8. Выпущены клиентские и/или серверные сертификаты для подключения к БД Platform V Pangolin SE по SSL при необходимости, согласно инструкции в разделе Последовательность действий.

  9. Подготовлено окружение в соответствии с типовой инструкцией по настройке Job [Deploy, Service] при установке через компонент Deploy tools (CDJE).

  10. Контейнеризированные компоненты IDMX установлены при помощи компонента Deploy tools (CDJE) (job завершен со статусом SUCCESS) (раздел Установка через Installer, подраздел Последовательность действий).

  11. Для каждого из модулей IDM — idmx-engine, idmx-ui, idmx-connector-server — readiness и liveness пробы используемой системы оркестрации контейнеризированных приложений возвращают статус Ready.

  12. Для каждой из используемых интеграций — проверить, что каждый компонент корректно установлен и сконфигурирован, согласно документации на компонент. Затем проверить, что интеграции корректно сконфигурированы на стороне IDMX (раздел Установка через Installer, подраздел Интеграции с платформенными зависимостями).

  13. Проверить подключения к интеграциям. Для этого следует удостовериться, что:

    • SecMan — Установка прошла корректно, IDMX может получать из SecMan хранимые в ней секреты.

    • Platform V SOWA — IDMX успешно подключается к ресурсам, расположенным в другом сегменте сети через Connector Server и шлюз SOWA.

    • Platform V Audit SE — В интерфейсе Platform V Audit SE отображаются записи о событиях безопасности, отправляемые IDMX (например, создание сессии).

    • Platform V Monitor — В дашборд компонента MONA отображаются метрики IDMX, публикуемые на эндпоинт Prometheus, в UI компонента LOGA отображаются записи системного журнала IDMX.

    • Platform V IAM SE — При авторизации в UI IDMX происходит перенаправление в UI IAM, где производится авторизация. При успешной авторизации браузер перенаправляется обратно в UI IDMX.

    • Platform V Synapse Service Mesh — IDMX успешно подключается к ресурсам, защищенным Platform V Synapse Service Mesh при наличии корректных сертификатов и настроек.

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

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

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

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

Интеграционный файл конфигурации#

Для корректной работы интеграции с компонентом CDJE продукта Platfrom V DevOps Tools, в конфигурации IDMX расположен файл idmx.conf, содержащий следующие параметры:

Имя

Описание

Требуемое значение

Возможные значения

Примечания

idmx_istio_enabled

Параметр определяет, используется ли интеграция с сервисом интеграции и оркестрации микросервисов в облаке

true/false

—

—

idmx_istio_type

Используемый сервис интеграции и оркестрации микросервисов в облаке

Код используемого сервиса

synapse, rhsm

—

idmx_multidc_enabled

Параметр определяет, будет ли использоваться режим мультиЦОД

true/false

—

—

idmx_repository_database_certs_deploy

Параметр определяет, будут ли создаваться Kubernetes Secret с сертификатами для доступа к системной БД IDMX

true/false

—

Данная функция выполняется компонентом CDJE, если для хранения секретов используется другая система — данный параметр рекомендуется оставить в false

idmx_repository_database_certs_audit_deploy

Параметр определяет, будут ли создаваться Kubernetes Secret с сертификатами для доступа к БД аудита IDMX

true/false

—

Данная функция выполняется компонентом CDJE, если для хранения секретов используется другая система — данный параметр рекомендуется оставить в false

idmx_datapipe_database_certs_deploy

Параметр определяет, будут ли создаваться Kubernetes Secret с сертификатами для доступа к БД сервиса передачи событий аудита IDMX

true/false

—

Данная функция выполняется компонентом CDJE, если для хранения секретов используется другая система — данный параметр рекомендуется оставить в false

idmx_datapipe_kafka_certs_deploy

Параметр определяет, будут ли создаваться Kubernetes Secret с сертификатами для доступа сервиса передачи событий аудита к Kafka внешнего журнала аудита (например, Platfrom V Audit SE)

true/false

—

Данная функция выполняется компонентом CDJE, если для хранения секретов используется другая система — данный параметр рекомендуется оставить в false

idmx_fluent_kafka_certs_deploy

Параметр определяет, будут ли создаваться Kubernetes Secret с сертификатами для доступа к Kafka журнала событий (например, компонента LOGA продукта Platform V Monitor)

true/false

—

Данная функция выполняется компонентом CDJE, если для хранения секретов используется другая система — данный параметр рекомендуется оставить в false

idmx_fluent_loki_certs_deploy

Параметр определяет, будут ли создаваться Kubernetes Secret с сертификатами для доступа к Loki

true/false

—

Данная функция выполняется компонентом CDJE, если для хранения секретов используется другая система — данный параметр рекомендуется оставить в false

idmx_audit_certs_deploy

Параметр определяет, будут ли создаваться Kubernetes Secret с сертификатами для доступа к внешнему журналу аудита (например, Platfrom V Audit SE)

true/false

—

Данная функция выполняется компонентом CDJE, если для хранения секретов используется другая система — данный параметр рекомендуется оставить в false

idmx_sowa_certs_deploy

Параметр определяет, будут ли создаваться Kubernetes Secret с сертификатами для доступа к шлюзу безопасности (Platform V SOWA)

true/false

—

Данная функция выполняется компонентом CDJE, если для хранения секретов используется другая система — данный параметр рекомендуется оставить в false

Также, при использовании компонента CDJE для развертывания IDMX, в конфигурационном репозитории будет расположен файл стендозависимой конфигурации common.conf.yml. Он содержит следующие параметры:

Имя

Описание

Требуемое значение

Возможные значения

Примечания

idmx_dbscripts_mode

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

Название варианта развертывания в кавычках, например "db_main_datapipe"

db_main — используется только основная база idmx-engine; db_main_datapipe — база idmx-engine + база idmx-datapipe; db_main_audit — база idmx-engine + база c аудитом; db_main_audit_datapipe — база idmx-engine + база idmx-datapipe + база c аудитом

—

idmx_liquibase_repository_database_url

URL адрес БД, на которой будут развернуты таблицы системной БД idmx-engine

Корректный URL адрес БД через порт JDBC

—

—

idmx_liquibase_repository_database_schema

Имя схемы системной БД idmx-engine

Строка, по умолчанию public

—

Не изменяйте данное значение

idmx_liquibase_repository_database_audit_url

URL адрес БД, на которой будут развернуты таблицы БД аудита idmx-engine, при включенном раздельном хранении записей аудита

Корректный URL адрес БД через порт JDBC

—

—

idmx_liquibase_repository_database_audit_schema

Имя схемы БД аудита idmx-engine

Строка, по умолчанию public

—

Не изменяйте данное значение

idmx_liquibase_datapipe_database_url

URL адрес БД, на которой будут развернуты таблицы БД сервиса передачи сообщений аудита idmx-datapipe

Корректный URL адрес БД через порт JDBC

—

—

idmx_liquibase_datapipe_database_schema

Имя схемы БД сервиса передачи сообщений idmx-datapipe

Строка, по умолчанию public

—

Не изменяйте данное значение

liquibase_loglevel_custom

Уровень логирования при исполнении конфигурационных скриптов Liquibase

Стандартный уровень логирования logback

ERROR, WARN, INFO, DEBUG, TRACE

Обратите внимание, не рекомендуется использовать уровни логирования DEBUG или TRACE в производтвенных средах.

DB_SCHEMA_SUFFIX

Суффикс имени схемы БД

Строка

—

—

db_separated

Параметр определяет, использовать ли режим раздельного хранения записей аудита

true/false

—

Данный параметр присутствует в файле для обратной совместимости. Рекомендуется задавать раздельное хранение в корневом файле конфигурации values.yaml

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

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

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

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

global:
  # Тип оркестратора контейнеров, используемого в кластере: kubernetes - k8s, openshift - ose
  orchestrator: "k8s"
  # Имя Service Account, которое будет использоваться для запуска модулей
  serviceAccountName: "default"
  # Автоматическое монтирование JWT токена сервисного аккаунта в контейнеры пода
  automountServiceAccountToken: true
  # Хост контейнерного реестра, используемого для хранения образов
  registry: "image-registry"
  # Параметр используется для указания секретов, которые необходимы для аутентификации при загрузке образов
  imagePullSecrets: []
    # - myRegistrySecretName

# Ядро IDM системы
engine:
  enabled: true
  # Аннотации для всех ресурсов сервиса (StatefulSet, Service, ConfigMap и т.д.). Применяются к metadata.annotations каждого ресурса
  annotations: {}
    # argocd.argoproj.io/sync-wave: '-2'
  # Аннотации для Pod. Применяются к spec.template.metadata.annotations в StatefulSet
  podAnnotations: {}
  # Наименование kubernetes secret, который будет использовать idmx-engine
  secretName: "idmx-secrets"
  # Количество реплик приложения idmx-engine
  replicas: 1
  # Настройка используемого образа idmx-engine
  image:
    # Адрес реестра с образами. Если не указан, используется значение переменной global.registry
    registry: ""
    # Название репозитория в реестре, где находится образ
    repository: ""
    # Тег образа
    tag: ""
    # Хэш образа, начинается с 'sha256:'. Если указан, имеет приоритет над тегом
    digest: ""

  # Настройка внешнего вида UI idmx-engine
  appearance:
    # Название окружения или проекта, отображаемое в UI (например, DEV, PROD, TEST).
    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-blue-light"
    # Ссылка на страницу документации
    help_url: ""

  # Подключение к БД idmx-engine
  database:
    enabled: true
    # Тип системной базы данных, используемой IDMX для хранения внутренних данных
    type: "postgresql"
    # Использовать mTLS при подключении к БД idmx-engine
    # При использовании MTLS без Service Mesh или с 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 (обязательно для работы с Service Mesh);
    # <DB_IP> — IP-адрес узла (обязательно для работы с Service Mesh);
    # <DB_EXTERNAL_PORT> — порт внешнего узла (сервера с системной БД).
    url: "jdbc:postgresql://db-hostname:127.0.0.1:5432/db-name?prepareThreshold=0&sslmode=disable"
    # Вынос логов аудита в отдельную БД
    audit:
      enabled: false
      # Параметр определяет, будет ли использоваться mTLS для подключения idmx-engine к БД с аудитом
      mtls: true
      # URL, по которому IDMX будет подключаться к БД с аудитом, заполняется аналогично с .Values.engine.database.url
      url: "jdbc:postgresql://db-hostname:127.0.0.1:5432/db-name?prepareThreshold=0&sslmode=disable"
    # Параметр определяет режим работы с lock в таблицах БД. Возможные значения:
    # jdbc - lock данные будут храниться в БД
    # default - lock данные будут храниться в памяти
    lockSystem: "jdbc"
    # Настройки пула подключений к БД
    # (полное описание см. в настройках HikariCP: https://github.com/brettwooldridge/HikariCP)
    hikariCP:
      # Минимальное количество соединений в пуле
      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
  ingress:
    enabled: true
    # Название Ingress Controller для маршрута idmx-engine, для Kubernetes >= 1.18, например nginx
    ingressClassName: ""
    # Аннотации ingress для маршрута idmx-engine
    annotations: {}
      # kubernetes.io/ingress.class: nginx
      # nginx.ingress.kubernetes.io/ssl-passthrough: 'true'
    # Доменное имя idmx-engine
    host: "engine-domain-name.ru"
    # Конфигурация TLS для маршрута idmx-engine
    tls: []
      # - secretName: idmx-engine-tls
      #     hosts:
      #       - engine-domain-name.ru

  # Настройка сессий
  session:
    #  Использовать префикс '__Host-' для названий кук
    cookieHostPrefix: false
    # Таймаут сессии в минутах
    timeout: 15
    # Ограничение количества сессий
    limitations:
      # Суммарное количество разрешенных сессий на одном поде (-1 - неограниченно, 0 - запрещено)
      maxSessions: -1
      # Суммарное количество разрешенных сессий для одного пользователя на одном поде (-1 - неограниченно, 0 - запрещено)
      maxSessionsPerUser: -1
      # Настройка количества сессий по каналам (ui (новый UI), rest, user(старый UI))
      channels:
        ui:
          maxSessions: -1
          maxSessionsPerUser: -1
        rest:
          maxSessions: -1
          maxSessionsPerUser: -1
        user:
          maxSessions: -1
          maxSessionsPerUser: -1

  # Настройка логирования
  logging:
    # Путь до директории, в которую будут записываться журналы логов
    path: "/app/idmx-engine/var/log"
    # Настройка режима отладки логов idmx-engine
    debug: false
    # Параметр определяет, можно ли вносить изменения в конфигурацию логирования через UI IDMX
    internalsAvoidLoggingChange: false

  # Настройка профилирования запуска приложения
  startupProfile:
    enabled: false

  # Настройка кластерного режима для idmx-engine
  cluster:
    enabled: true
    # Таймаут установления соединения между узлами кластера, в миллисекундах. 0 - неограниченно
    connectionTimeout: 30000
    # Таймаут получения ответа запросов между узлами кластера, в миллисекундах. 0 - неограниченно
    receiveTimeout: 60000
  # Настройка режима мультиЦОД
  multidc:
    # Флаг включения/выключения мультиЦОД
    enabled: false
    # Хосты idmx-engine и IP-адреса балансеров кластеров, входящих в мультиЦОД
    # Хосты не должны пересекаться с .Values.engine.ingress.host
    # Первым задается host и ip балансера кластера, куда производится установка helm chart
    # Далее указываются кластера, находящиеся в других неймспейсах
    cluster:
      - host: "engine-cnb-cluster-1-domain-name.ru"
        balancer: "cluster-1-ip-address"
      - host: "engine-cnb-cluster-2-domain-name.ru"
        balancer: "cluster-2-ip-address"
      - host: "engine-cnb-cluster-3-domain-name.ru"
        balancer: "cluster-3-ip-address"

  # HTTP-заголовок для виртуального сервера Tomcat
  tomcat:
    portHeader: "X-Forwarded-Port"
  # Дополнительные опции запуска для Java-машины
  javaOptsExtra: "-XX:NativeMemoryTracking=summary -XX:+AlwaysPreTouch -server -XX:InitialRAMPercentage=50.0 -XX:+UseContainerSupport -XX:MaxRAMPercentage=70.0 -XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:+ExitOnOutOfMemoryError"
  # Параметр отвечает за стратегию обновления коннекторов в кэше idmx-engine
  # true - в случае изменения коннекторов в одном из подов, idmx-engine отправит запрос на обновление кэша на все другие поды в кластере
  # false - коннекторы в кэше будут обновляться из БД, в соответствии с настройками обновления кэша
  cachingProfileConnectorsInvalidation: true
  # Параметр отвечает за стратегию обновления ресурсов в кэше idmx-engine
  # true - в случае изменения ресурсов в одном из подов, idmx-engine отправит запрос на обновление кэша на все другие поды в кластере
  # false - ресурсы в кэше будут обновляться из БД, в соответствии с настройками обновления кэша
  cachingProfileResourcesInvalidation: false
  # Параметр задает путь до основной директории idmx-engine
  basePath:

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

  # Настройки аутентификации через OpenID Connect
  # Не работает вместе с iam
  oidc:
    # Параметр включает аутентификацию через OIDC
    enabled: false
    # Параметр определяет FQDN узла провайдера OIDC, через который будет осуществляться авторизация на IDMX.
    host: "keycloak-hostname"
    # Параметр определяет IP узла провайдера OIDC, через который будет осуществляться авторизация на IDMX.
    ip: 127.0.0.1
    # Параметр определяет порт узла провайдера OIDC, через который будет осуществляться авторизация на IDMX.
    port: 8443
    # Путь к endpoint авторизации сервера OIDC
    authorizationPath: "/auth/realms/PlatformAuth/protocol/openid-connect/auth"
    # Путь к endpoint выпуска токена сервера OIDC
    tokenPath: "/auth/realms/PlatformAuth/protocol/openid-connect/token"
    # Путь к серверу OIDC
    issuerPath: "/auth/realms/PlatformAuth"
    # Уникальный идентификатор приложения (UUID)
    registrationId: ""
    # Уникальный идентификатор приложения (имя) для engine
    clientId: "idm-dev"
    # Уникальный идентификатор приложения (имя) для ui
    clientIdUi: "idm-dev-ui"

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

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

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

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

  # Массив дополнительных переменных, которые будут добавлены в configmap idmx-engine
  extraEnv: {}
  # Список дополнительных volumeMounts для контейнера idmx-engine
  extraVolumeMounts: []
  # Список дополнительных volumes для statefulset idmx-engine
  extraVolumes: []
  # Параметр задает список названий (alias) дополнительных сертификатов для монтирования
  # Задаются в формате строк, разделенных ',' например alias1,alias2,alias3
  # Используемые сертификаты должны быть загружены в SecMan, под именами в формате alias1_cert, alias1_key, alias1_ca
  extraCerts:
    enabled: false
    certs: "postgres_kis"

  # Настройка проверки готовности контейнера 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
  # Включение распределения экземпляров idmx-engine по разным узлам среды исполнения.
  # Если true - планировщик попытается распределить экземпляры idmx-engine по разным узлам.
  # При невозможности такого распределения, экземпляры все равно будут запланированы.
  selfAntiAffinity: false

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

  # Настройка внешнего источника коннекторов IDMX для idmx-engine
  initConnectorsLoad:
    # container - в случае использования init контейнер, download - в случае загрузки коннекторов из внешнего сервиса
    type: null
    # если type: download, указываем адрес внешнего ресурса
    source: null
    tries:
      # Количество попыток загрузить коннекторы из внешнего ресурса
      count: 15
      # Время ожидания в секундах, между попытками загрузить коннекторы из внешнего ресурса
      timeout: 3
    # Настройка используемого образа init контейнера
    image:
      # Адрес реестра с образами. Если не указан, используется значение переменной global.registry
      registry: ""
      # Название репозитория в реестре, где находится образ
      repository: ""
      # Тег образа
      tag: ""
      # Хэш образа, начинается с 'sha256:'. Если указан, имеет приоритет над тегом
      digest: ""
    # Вычислительные ресурсы, необходимые 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
    mesh:
      # Вычислительные ресурсы, необходимые sidecar контейнеру Service Mesh
      resources:
        requests:
          # Количество ядер процессора, которое будет запрошено для контейнера
          cpu: 200m
          # Минимальный объем оперативной памяти, который будет запрошен для контейнера
          memory: 512Mi
        limits:
          # Максимальное количество ядер процессора, которое будет выделено для контейнера
          cpu: 200m
          # Максимальный объем оперативной памяти, который будет выделен для контейнера
          memory: 1Gi

# Модуль, предоставляющий визуальный интерфейс для работы с ядром
ui:
  enabled: true
  # Аннотации для всех ресурсов сервиса (Deployment, Service, ConfigMap и т.д.). Применяются к metadata.annotations каждого ресурса
  annotations: {}
    # argocd.argoproj.io/sync-wave: '-1'
  # Аннотации для Pod. Применяются к spec.template.metadata.annotations в Deployment
  podAnnotations: {}
  # Количество реплик приложения idmx-ui
  replicas: 1
  # Настройка используемого образа idmx-ui
  image:
    # Адрес реестра с образами. Если не указан, используется значение переменной global.registry
    registry: ""
    # Название репозитория в реестре, где находится образ
    repository: ""
    # Тег образа
    tag: ""
    # Хэш образа, начинается с 'sha256:'. Если указан, имеет приоритет над тегом
    digest: ""

  # # Настройка внешнего вида UI idmx-ui
  appearance:
    # Название окружения или проекта, отображаемое в UI (например, DEV, PROD, TEST).
    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-blue-light"
    # Ссылка на страницу документации
    help_url: ""

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

  # Вычислительные ресурсы, необходимые контейнеру 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
  # Включение распределения экземпляров idmx-ui по разным узлам среды исполнения.
  # Если true - планировщик попытается распределить экземпляры idmx-ui по разным узлам.
  # При невозможности такого распределения, экземпляры все равно будут запланированы.
  selfAntiAffinity: false
  # Стратегия обновления, которая определяет, как заменяются старые поды новыми.
  strategy:
    # 'Recreate' — удаляет все существующие поды перед созданием новых.
    # 'RollingUpdate' — заменяет старые ReplicaSets на новые постепенно, уменьшая количество старых реплик и увеличивая новые.
    type: "RollingUpdate"
    # Параметры rolling-обновления. Присутствует только если type = RollingUpdate.
    rollingUpdate:
      # Параметр определяет, сколько подов может быть недоступно во время обновления.
      maxUnavailable: 0
      # Параметр определяет, насколько можно превысить желаемое число подов.
      maxSurge: 25%

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

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

# Модуль, предоставляющий возможность подключать различные коннекторы на основе ConnID для взаимодействия с информационными системами
connectorServer:
  enabled: false
  # Аннотации для всех ресурсов сервиса (Deployment, Service, ConfigMap и т.д.). Применяются к metadata.annotations каждого ресурса
  annotations: {}
    # argocd.argoproj.io/sync-wave: '-2'
  # Аннотации для Pod. Применяются к spec.template.metadata.annotations в Deployment
  podAnnotations: {}
  # Количество реплик приложения idmx-connector-server
  replicas: 1
  # Наименование kubernetes secret, который будет использоваться idmx-connector-server
  secretName: "idmx-secrets"
  # Настройка используемого образа idmx-connector-server
  image:
    # Адрес реестра с образами. Если не указан, используется значение переменной global.registry
    registry: ""
    # Название репозитория в реестре, где находится образ
    repository: ""
    # Тег образа
    tag: ""
    # Хэш образа, начинается с 'sha256:'. Если указан, имеет приоритет над тегом
    digest: ""

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

  # Настройка логирования
  logging:
    # Путь до директории, в которую будут записываться журналы логов
    path: "/app/idmx-connector-server/logs"
    # Уровень логирования для logback
    level: "INFO"

  # Дополнительные опции запуска для Java-машины
  javaOptsExtra: "-Xmx500m"
  # Протокол, по которому Connector Server будет принимать входящие запросы (TCP/WEB_SOCKET).
  # Обратите внимание, при изменении данного параметра потребуется также изменить конфигурацию connectorHost!
  protocol: "WEB_SOCKET"
  # Минимальное количество обработчиков запросов
  minWorkers: 10
  # Максимальное количество обработчиков запросов
  maxWorkers: 100
  # Максимальное количество одновременно открытых соединений
  maxConnections: 300
  # Время ожидания новых запросов обработчиками до их удаления
  keepAliveSec: 30
  # Размер очереди запросов, при заполнении которой будут создаваться новые обработчики
  waitingQueueSize: 2
  # Интервал между проверками соединения (только для WEB_SOCKET)
  connectionLostTimeoutSec: 60
  # Количество обработчиков входящих данных (только для WEB_SOCKET)
  # (они занимаются парсингом входящего трафика и передачей его в обработчики запросов)
  decodersCount: 1
  # Время ожидания штатного закрытия открытых соединений по WebSocket, перед их принудительным закрытием.
  gracefulShutdownTimeoutSec: 30
  # Настройка обновления секретов в рантайме (без перезапуска контейнера)
  secretsHotReload:
    enabled: true
    # Количество попыток считывания нового секрета после обновления (в случае ошибок считывания)
    maxReadAttempts: 3
    # Период между считываниями секрета в секундах
    pollingPeriodSec: 10
    # Поведение при неуспешном обновлении: FAIL_SAFE - продолжить работу со старыми секретами, FAIL_FAST - завершить работу с ошибкой
    hotReloadStrategy: "FAIL_SAFE"

  # Настройка режима, в котором в один неймспейс устанавливается несколько экземпляров Connector Server
  multics:
    # Флаг включения/выключения режима
    enabled: false
    # Список экземпляров Connector Server, которые будут созданы. Следует добавить столько строк, сколько требуется создать экземпляров.
    # В каждой строке следует указать уникальный name, который будет добавлен к имени экземпляра, и host экземпляра Connector Server.
    # Например, строка 'alpha' в списке добавит экземпляр Connector Server с именем idmx-connector-server-alpha.
    instances:
      - name: "alpha"
        host: "cs-alpha-domain-name.ru"
      - name: "beta"
        host: "cs-beta-domain-name.ru"
      - name: "gamma"
        host: "cs-gamma-domain-name.ru"

  # Настройка интеграции с 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

  # Список дополнительных volumeMounts для контейнера idmx-connector-server
  extraVolumeMounts: []
  # Список дополнительных volumes для deployment idmx-connector-server
  extraVolumes: []

  # Настройка проверки готовности контейнера 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
  # Включение распределения экземпляров idmx-connector-server по разным узлам среды исполнения.
  # Если true - планировщик попытается распределить экземпляры idmx-connector-server по разным узлам.
  # При невозможности такого распределения, экземпляры все равно будут запланированы.
  selfAntiAffinity: false
  # Стратегия обновления, которая определяет, как заменяются старые поды новыми.
  strategy:
    # 'Recreate' — удаляет все существующие поды перед созданием новых.
    # 'RollingUpdate' — заменяет старые ReplicaSets на новые постепенно, уменьшая количество старых реплик и увеличивая новые.
    type: "RollingUpdate"
    # Параметры rolling-обновления. Присутствует только если type = RollingUpdate.
    rollingUpdate:
      # Параметр определяет, сколько подов может быть недоступно во время обновления.
      maxUnavailable: 0
      # Параметр определяет, насколько можно превысить желаемое число подов.
      maxSurge: 25%

  # Настройка атрибутов безопасности
  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: download, указываем адрес внешнего ресурса
    source: null
    tries:
      # Количество попыток загрузить коннекторы из внешнего ресурса
      count: 15
      # Время ожидания в секундах, между попытками загрузить коннекторы из внешнего ресурса
      timeout: 3
    # Настройка используемого образа init контейнера
    image:
      # Адрес реестра с образами. Если не указан, используется значение переменной global.registry
      registry: ""
      # Название репозитория в реестре, где находится образ
      repository: ""
      # Тег образа
      tag: ""
      # Хэш образа, начинается с 'sha256:'. Если указан, имеет приоритет над тегом
      digest: ""
    # Вычислительные ресурсы, необходимые 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
    mesh:
      # Вычислительные ресурсы, необходимые sidecar контейнеру Service Mesh
      resources:
        requests:
          # Количество ядер процессора, которое будет запрошено для контейнера
          cpu: 200m
          # Минимальный объем оперативной памяти, который будет запрошен для контейнера
          memory: 512Mi
        limits:
          # Максимальное количество ядер процессора, которое будет выделено для контейнера
          cpu: 200m
          # Максимальный объем оперативной памяти, который будет выделен для контейнера
          memory: 1Gi

# Модуль, осуществляющий аггрегацию, обработку и отправку сообщений аудита при интеграции с внешними системами аудита
datapipe:
  enabled: false
  # Аннотации для всех ресурсов сервиса (Deployment, Service, ConfigMap и т.д.). Применяются к metadata.annotations каждого ресурса
  annotations: {}
    # argocd.argoproj.io/sync-wave: '-2'
  # Аннотации для Pod. Применяются к spec.template.metadata.annotations в Deployment
  podAnnotations: {}
  # Количество реплик приложения idmx-datapipe
  replicas: 1
  # Наименование kubernetes secret, который будет использовать idmx-datapipe
  secretName: "idmx-secrets"
  # Настройка используемого образа idmx-datapipe
  image:
    # Адрес реестра с образами. Если не указан, используется значение переменной global.registry
    registry: ""
    # Название репозитория в реестре, где находится образ
    repository: ""
    # Тег образа
    tag: ""
    # Хэш образа, начинается с 'sha256:'. Если указан, имеет приоритет над тегом
    digest: ""

  # Подключение к БД idmx-datapipe
  database:
    enabled: true
    # Использовать mTLS при подключении к БД idmx-datapipe
    # При использовании MTLS без Service Mesh или с 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-datapipe/postgres_datapipe_cert&sslkey=/vault/secrets/postgres-datapipe/postgres_datapipe_pk8&sslrootcert=/vault/secrets/postgres-datapipe/postgres_datapipe_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 (обязательно для работы с Service Mesh);
    # <DB_IP> — IP-адрес узла (обязательно для работы с Service Mesh);
    # <DB_EXTERNAL_PORT> — порт внешнего узла (сервера с системной БД).
    url: "jdbc:postgresql://db-hostname:127.0.0.1:5432/db-name?prepareThreshold=0&sslmode=disable"
    # # Настройки пула подключений к БД
    # (полное описание см. в настройках HikariCP: https://github.com/brettwooldridge/HikariCP)
    hikariCP:
      # Настройки подключения к БД idmx-datapipe
      datapipe:
        # Минимальное количество соединений в пуле
        minPoolSize: 2
        # Максимальное количество соединений в пуле
        maxPoolSize: 10
        # Максимальное время жизни соединения в пуле
        maxLifetime: 0
        # Время, в течение которого соединению разрешено простаивать в пуле
        idleTimeout: 600000
        # Как часто нужно посылать запросы (ping) через соединение, чтобы предотвратить его тайм-аут из-за базы данных или сетевой инфраструктуры (0 - отключено)
        keepaliveTime: 0
        # Время, в течение которого соединение может находиться вне пула, прежде чем будет зарегистрировано сообщение, указывающее на возможную утечку соединения (0 - отключено)
        leakDetectionThreshold: 0
        # Максимальное время, в течение которого клиент будет ждать соединения из пула
        connectionTimeout: 30000
        # Время, в течение которого соединение будет проверяться на работоспособность
        validationTimeout: 5000
        # Время, по истечению которого пул будет выходить из строя (fail-fast), если он не может быть успешно проинициализирован.
        initializationFailTimeout: 1
        # Максимальное время ожидания ответа от БД
        networkTimeout: 60000
        # Значение тайм-аута, используемое для операций чтения.
        socketTimeout: 30
      # Настройки подключения к основной БД idmx-engine
      main:
        # Минимальное количество соединений в пуле
        minPoolSize: 2
        # Максимальное количество соединений в пуле
        maxPoolSize: 10
        # Максимальное время жизни соединения в пуле
        maxLifetime: 0
        # Время, в течение которого соединению разрешено простаивать в пуле
        idleTimeout: 600000
        # Как часто нужно посылать запросы (ping) через соединение, чтобы предотвратить его тайм-аут из-за базы данных или сетевой инфраструктуры (0 - отключено)
        keepaliveTime: 0
        # Время, в течение которого соединение может находиться вне пула, прежде чем будет зарегистрировано сообщение, указывающее на возможную утечку соединения (0 - отключено)
        leakDetectionThreshold: 0
        # Максимальное время, в течение которого клиент будет ждать соединения из пула
        connectionTimeout: 30000
        # Время, в течение которого соединение будет проверяться на работоспособность
        validationTimeout: 5000
        # Время, по истечению которого пул будет выходить из строя (fail-fast), если он не может быть успешно проинициализирован.
        initializationFailTimeout: 1
        # Максимальное время ожидания ответа от БД
        networkTimeout: 60000
        # Значение тайм-аута, используемое для операций чтения.
        socketTimeout: 30
      # Настройки подключения к БД с аудитом idmx-datapipe, если аудит вынесен в отдельную БД
      audit:
        # Минимальное количество соединений в пуле
        minPoolSize: 2
        # Максимальное количество соединений в пуле
        maxPoolSize: 10
        # Максимальное время жизни соединения в пуле
        maxLifetime: 0
        # Время, в течение которого соединению разрешено простаивать в пуле
        idleTimeout: 600000
        # Как часто нужно посылать запросы (ping) через соединение, чтобы предотвратить его тайм-аут из-за базы данных или сетевой инфраструктуры (0 - отключено)
        keepaliveTime: 0
        # Время, в течение которого соединение может находиться вне пула, прежде чем будет зарегистрировано сообщение, указывающее на возможную утечку соединения (0 - отключено)
        leakDetectionThreshold: 0
        # Максимальное время, в течение которого клиент будет ждать соединения из пула
        connectionTimeout: 30000
        # Время, в течение которого соединение будет проверяться на работоспособность
        validationTimeout: 5000
        # Время, по истечению которого пул будет выходить из строя (fail-fast), если он не может быть успешно проинициализирован.
        initializationFailTimeout: 1
        # Максимальное время ожидания ответа от БД
        networkTimeout: 60000
        # Значение тайм-аута, используемое для операций чтения.
        socketTimeout: 30

  # Настройка отправки сообщений аудита в 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
    eventTopic: "event"
    # Параметр определяет топики Kafka для метамоделей
    metamodelTopic: "metamodel"
    # Максимальное время ожидания ответа от Kafka
    requestTimeoutMs: 10000
    # Максимальное время отправки сообщения в Kafka, включая время отправки, ожидание ответа и т.д.
    # Должно быть больше чем requestTimeoutMs
    deliveryTimeoutMs: 11000

  # Дополнительные опции запуска для Java-машины
  javaOptsExtra: "-XX:+AlwaysPreTouch -server -XX:InitialRAMPercentage=50.0 -XX:+UseContainerSupport -XX:MaxRAMPercentage=70.0 -XX:+UseG1GC -XX:MaxGCPauseMillis=100"
  # Параметр определяет периодичность запуска сущности инструмента Jenkins (Jenkins job)
  # Например, */10 * * * * * - запуск сущности инструмента Jenkins (Jenkins job) каждые 10 секунд
  cron: "*/10 * * * * *"
  # Время, с которого будут вычитываться события аудита при первом запуске
  # Возможные значения:
  # ZERO - все события из базы
  # NOW - события начиная с текущего момента
  # YYYY-MM-DD HH:MM:SS.sss +HHMM - события с определенной временной метки.
  # При указании таймзоны (+HHMM в значении параметра), необходимо указывать таймзону такую же, как и в БД событий аудита.
  # Например, можно взять значение из поля timestamp таблицы ma_audit_event и вставить его в значение параметра
  initReadFrom: "NOW"
  # Размер обрабатываемого блока событий
  chunkSize: 10
  # Количество событий считываемых из базы одним запросом
  auditReadPageSize: 80
  # Количество потоков, обрабатывающих события аудита
  workersPoolSize: 4
  # Период между проверкам доступности БД аудита
  dbHealthCheckPeriodMs: 10000
  # Максимальное время проверки доступности кафки
  kafkaHealthCheckTimeoutMs: 10000
  # Настройка политик повторов операций при возникновении ошибок
  retryPolicies:
    # Количество попыток на этапе чтения (1 - общее количество попыток, включая первую)
    readerMaxAttempts: 1
    # Количество попыток на этапе маппинга (1 - общее количество попыток, включая первую)
    processorMaxAttempts: 1
    # Количество попыток на этапе отправки в кафку (1 - общее количество попыток, включая первую)
    writerMaxAttempts: 1
  # Настройка обновления секретов в рантайме (без перезапуска контейнера)
  secretsHotReload:
    enabled: true
    # Количество попыток считывания нового секрета после обновления (в случае ошибок считывания)
    maxReadAttempts: 3
    # Период между повторными попытками считывания секрета (в случае ошибок)
    retryDelaySec: 10
    # Период между считываниями секрета в секундах
    pollingPeriodSec: 60
    # Поведение при неуспешном обновлении: FAIL_SAFE - продолжить работу со старыми секретами, FAIL_FAST - завершить работу с ошибкой
    hotReloadStrategy: "FAIL_SAFE"

  # Настройка включения кэширования объектов ResourceType, TaskType, ArchetypeType
  cache:
    enabled: true
    # Максимальное количество объектов в кэше
    maximumSize: 100
    # Время, после которого записи удаляются из кэша
    # Например, P2DT3H4M преобразуется в 2 дня, 3 часа и 4 минуты
    expireAfterWrite: "P1D"
    # Включение статистики кэша в метриках
    recordMetrics: true

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

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

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

  # Приоритет выполнения для idmx-datapipe в кластере
  priorityClassName: null
  # Включение распределения экземпляров idmx-datapipe по разным узлам среды исполнения.
  # Если true - планировщик попытается распределить экземпляры idmx-datapipe по разным узлам.
  # При невозможности такого распределения, экземпляры все равно будут запланированы.
  selfAntiAffinity: false
  # Стратегия обновления, которая определяет, как заменяются старые поды новыми.
  strategy:
    # 'Recreate' — удаляет все существующие поды перед созданием новых.
    # 'RollingUpdate' — заменяет старые ReplicaSets на новые постепенно, уменьшая количество старых реплик и увеличивая новые.
    type: "RollingUpdate"
    # Параметры rolling-обновления. Присутствует только если type = RollingUpdate.
    rollingUpdate:
      # Параметр определяет, сколько подов может быть недоступно во время обновления.
      maxUnavailable: 0
      # Параметр определяет, насколько можно превысить желаемое число подов.
      maxSurge: 25%

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

  # Настройка внешнего источника схемы IDMX для idmx-datapipe
  initConnectorsLoad:
    # container - в случае использования init контейнер, download - в случае загрузки схемы из внешнего сервиса
    type: null
    # если type: download, указываем адрес внешнего ресурса
    source: null
    tries:
      # Количество попыток загрузить коннекторы из внешнего ресурса
      count: 15
      # Время ожидания в секундах, между попытками загрузить коннекторы из внешнего ресурса
      timeout: 3
    # Настройка используемого образа init контейнера
    image:
      # Адрес реестра с образами. Если не указан, используется значение переменной global.registry
      registry: ""
      # Название репозитория в реестре, где находится образ
      repository: ""
      # Тег образа
      tag: ""
      # Хэш образа, начинается с 'sha256:'. Если указан, имеет приоритет над тегом
      digest: ""
    # Вычислительные ресурсы, необходимые 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-datapipe
  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
    mesh:
      # Вычислительные ресурсы, необходимые sidecar контейнеру Service Mesh
      resources:
        requests:
          # Количество ядер процессора, которое будет запрошено для контейнера
          cpu: 400m
          # Минимальный объем оперативной памяти, который будет запрошен для контейнера
          memory: 512Mi
        limits:
          # Максимальное количество ядер процессора, которое будет выделено для контейнера
          cpu: 400m
          # Максимальный объем оперативной памяти, который будет выделен для контейнера
          memory: 1Gi

# Настройка Service Mesh
serviceMesh:
  enabled: false
  # Аннотации для всех ресурсов сервиса (Deployment, Service, ConfigMap и т.д.). Применяются к metadata.annotations каждого ресурса
  annotations: {}
    # argocd.argoproj.io/sync-wave: '-4'
  # Аннотации для Pod. Применяются к spec.template.metadata.annotations в Deployment
  podAnnotations: {}
  # Тип используемого Service Mesh. Redhat Service Mesh - rhsm, Synapse Service Mesh - synapse
  type: "synapse"
  # Настройка используемого образа idmx-egress-gateway и idmx-ingress-gateway
  image:
    # Адрес реестра с образами. Если не указан, используется значение переменной global.registry
    registry: ""
    # Название репозитория в реестре, где находится образ
    repository: "service_mesh/proxyv2"
    # Тег образа
    tag: ""
    # Хэш образа, начинается с 'sha256:'. Если указан, имеет приоритет над тегом
    digest: ""
  # Параметр определяет имя экземпляра Service Mesh Control Plane для Ingress
  instance: "control-plane-instance"
  # Параметр определяет адрес Service Mesh Control Plane для Ingress
  discoveryAddress: "control-plane:15012"
  # Параметр определяет максимальное возможное количество реплик idmx-engine, необходим для маршрутов Service Mesh
  idmxEngineMaxReplicas: 30

  # Настройка исходящего трафика serivce mesh
  egressGateway:
    # Количество реплик приложения idmx-egress-gateway
    replicas: 1
    # Наименование kubernetes secret, который будет использоваться idmx-egress-gateway
    secretName: "idmx-secrets"

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

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

    # Настройка интеграции с 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"
      # Параметр включает сбор метрик путем опроса подов со стороны AC REFLEX
      scrape: false
      # Настройка сборов трассировок через OpenTelemetry
      openTelemetry:
        enabled: true
        # Тенант Reflex куда будут отправлены данные
        reflexTenant: standIFT
        # Маршрут к точке сбора трассировок Reflex в пределах кластера
        reflexRoute: ci01234567-reflex/route-reflex.ci01234567-reflex.svc.cluster.local
        # Метки для фильтрации в системе анализа трассировок, соответствующие данному стенду
        reflexOtelTag: CI01234567-stand-cluster

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

    # Настройка горизонтального масштабирования (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
    # Включение распределения экземпляров idmx-egress-gateway по разным узлам среды исполнения.
    # Если true - планировщик попытается распределить экземпляры idmx-egress-gateway по разным узлам.
    # При невозможности такого распределения, экземпляры все равно будут запланированы.
    selfAntiAffinity: false
    # Стратегия обновления, которая определяет, как заменяются старые поды новыми.
    strategy:
      # 'Recreate' — удаляет все существующие поды перед созданием новых.
      # 'RollingUpdate' — заменяет старые ReplicaSets на новые постепенно, уменьшая количество старых реплик и увеличивая новые.
      type: "RollingUpdate"
      # Параметры rolling-обновления. Присутствует только если type = RollingUpdate.
      rollingUpdate:
        # Параметр определяет, сколько подов может быть недоступно во время обновления.
        maxUnavailable: 0
        # Параметр определяет, насколько можно превысить желаемое число подов.
        maxSurge: 25%

    # Настройка атрибутов безопасности
    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

  # Настройка входящего трафика serivce mesh
  ingressGateway:
    # Количество реплик приложения idmx-ingress-gateway
    replicas: 1
    # Наименование kubernetes secret, который будет использоваться idmx-ingress-gateway
    secretName: "idmx-secrets"

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

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

    # Настройка геобалансировщика
    geoBalancer:
      # Включает создание дополнительного маршрута для геобалансировки
      enabled: false
      # Доменное имя геобалансировщика для idmx-engine
      hostEngine: "engine-geo.ru"
      # Доменное имя геобалансировщика для idmx-ui
      hostUi: "ui-geo.ru"
      # Доменное имя геобалансировщика для idmx-connector-server. В случае использования multics порядок списка доменных имен должен совпадать с указанным в разделе multics
      hostConnServ:
        - host: "cs-geo.ru"
      # Включает создание маршрута для healthcheck со стороны внешнего балансировщика
      healthChecks: true

    # Вычислительные ресурсы, необходимые контейнеру 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
    # Включение распределения экземпляров idmx-ingress-gateway по разным узлам среды исполнения.
    # Если true - планировщик попытается распределить экземпляры idmx-ingress-gateway по разным узлам.
    # При невозможности такого распределения, экземпляры все равно будут запланированы.
    selfAntiAffinity: false
    # Стратегия обновления, которая определяет, как заменяются старые поды новыми.
    strategy:
      # 'Recreate' — удаляет все существующие поды перед созданием новых.
      # 'RollingUpdate' — заменяет старые ReplicaSets на новые постепенно, уменьшая количество старых реплик и увеличивая новые.
      type: "RollingUpdate"
      # Параметры rolling-обновления. Присутствует только если type = RollingUpdate.
      rollingUpdate:
        # Параметр определяет, сколько подов может быть недоступно во время обновления.
        maxUnavailable: 0
        # Параметр определяет, насколько можно превысить желаемое число подов.
        maxSurge: 25%

    # Настройка атрибутов безопасности
    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

# Настройка интеграции с Secret Management System
secman:
  enabled: false
  # В этом параметре указывается префикс для взаимодействие с API Secret Management
  mountPath: "auth/kubernetes"
  # Параметр задает пространство имен, в котором расположен экземпляр Secret Management System, используемый для IDMX
  namespace: "DEV_IDMX"
  # Путь к файлу токена JWT, используемого для аутентификации
  tokenPath: "/var/run/secrets/kubernetes.io/serviceaccount/token"
  # Параметр определяет роль для доступа к секретам IDMX в Secret Management System
  role: "role-ga-secman-idmx-dev"
  # Параметр определяет, будет ли использоваться mTLS для подключения к Secret Management System
  mtls: true
  # Параметр определяет host Secret Management
  host: "secman-hostname"
  # Параметр задает порт Secret Management
  port: 443
  # Параметр определяет путь до Key-Value хранилища с секретами IDMX в Secret Management System
  kvPath: "A/DEV/IDMX/KV/DEV"
  # Настройка получения сертификатов из PKI (Public Key Infrastructure) движка Secret Management System
  pkiSecretsEngine:
    enabled: false
    # Настройка получения ingress сертификатов для idmx-engine из PKI движка Secret Management System
    idmxEngine:
      # Путь до PKI движка
      pkiPath: "PKI/DEV"
      # Common name выпускаемого сертификата
      commonName: "idmx-engine-common-name"
      # Дополнительные имена к common name
      altNames: ""
      # Срок действия сертификата в часах (h), минутах (m) или секундах (s). Если не указан, будет использоваться значение ttl для PKI роли
      ttl: "2160h"
      # Настройка обогащения CA сертификатов из KV хранилища в Secret Management System
      enrichCA:
        enabled: false
        # Параметр определяет путь до Key-Value хранилища с расширением для списка доверенных сертификатов
        kvPath: "A/DEV/IDMX/KV/DEV"
        # Параметр определяет путь до ключа с расширением для списка доверенных сертификатов
        secretName: "extra_ca"
    # Настройка получения ingress сертификатов для режима мультиЦОД idmx-engine из PKI движка Secret Management System
    idmxEngineCnb:
      # Путь до PKI движка
      pkiPath: "PKI/DEV"
      # Common name выпускаемого сертификата
      commonName: "idmx-engine-common-name"
      # Дополнительные имена к common name
      altNames: ""
      # Срок действия сертификата в часах (h), минутах (m) или секундах (s). Если не указан, будет использоваться значение ttl для PKI роли
      ttl: "2160h"
      # Настройка обогащения CA сертификатов из KV хранилища в Secret Management System
      enrichCA:
        enabled: false
        # Параметр определяет путь до Key-Value хранилища с расширением для списка доверенных сертификатов
        kvPath: "A/DEV/IDMX/KV/DEV"
        # Параметр определяет путь до ключа с расширением для списка доверенных сертификатов
        secretName: "extra_ca"
    # Настройка получения ingress сертификатов для idmx-connector-server из PKI движка Secret Management System
    idmxConnectorServer:
      # Путь до PKI движка
      pkiPath: "PKI/DEV"
      # Common name выпускаемого сертификата
      commonName: "idmx-connector-server-common-name"
      # Дополнительные имена к common name
      altNames: ""
      # Срок действия сертификата в часах (h), минутах (m) или секундах (s). Если не указан, будет использоваться значение ttl для PKI роли
      ttl: "2160h"
      # Настройка обогащения CA сертификатов из KV хранилища в Secret Management System
      enrichCA:
        enabled: false
        # Параметр определяет путь до Key-Value хранилища с расширением для списка доверенных сертификатов
        kvPath: "A/DEV/IDMX/KV/DEV"
        # Параметр определяет путь до ключа с расширением для списка доверенных сертификатов
        secretName: "extra_ca"
    # Настройка получения ingress сертификатов для idmx-ui из PKI движка Secret Management System
    idmxUi:
      # Путь до PKI движка
      pkiPath: "PKI/DEV"
      # Common name выпускаемого сертификата
      commonName: "idmx-ui-common-name"
      # Дополнительные имена к common name
      altNames: ""
      # Срок действия сертификата в часах (h), минутах (m) или секундах (s). Если не указан, будет использоваться значение ttl для PKI роли
      ttl: "2160h"
      # Настройка обогащения CA сертификатов из KV хранилища в Secret Management System
      enrichCA:
        enabled: false
        # Параметр определяет путь до Key-Value хранилища с расширением для списка доверенных сертификатов
        kvPath: "A/DEV/IDMX/KV/DEV"
        # Параметр определяет путь до ключа с расширением для списка доверенных сертификатов
        secretName: "extra_ca"
    # Настройка получения сертификатов для idmx-egress-gateway из PKI движка Secret Management System
    idmxEgressGateway:
      # Путь до PKI движка
      pkiPath: "PKI/DEV"
      # Common name выпускаемого сертификата
      commonName: "idmx-egress-gateway-common-name"
      # Дополнительные имена к common name
      altNames: ""
      # Срок действия сертификата в часах (h), минутах (m) или секундах (s). Если не указан, будет использоваться значение ttl для PKI роли
      ttl: "2160h"
      # Настройка обогащения CA сертификатов из KV хранилища в Secret Management System
      enrichCA:
        enabled: false
        # Параметр определяет путь до Key-Value хранилища с расширением для списка доверенных сертификатов
        kvPath: "A/DEV/IDMX/KV/DEV"
        # Параметр определяет путь до ключа с расширением для списка доверенных сертификатов
        secretName: "extra_ca"
    # Настройка получения сертификатов для доступа к системной БД IDMX из PKI движка Secret Management System
    postgres:
      # Путь до PKI движка
      pkiPath: "PKI/DEV"
      # Common name выпускаемого сертификата
      commonName: "postgres-common-name"
      # Дополнительные имена к common name
      altNames: ""
      # Срок действия сертификата в часах (h), минутах (m) или секундах (s). Если не указан, будет использоваться значение ttl для PKI роли
      ttl: "2160h"
      # Настройка обогащения CA сертификатов из KV хранилища в Secret Management System
      enrichCA:
        enabled: false
        # Параметр определяет путь до Key-Value хранилища с расширением для списка доверенных сертификатов
        kvPath: "A/DEV/IDMX/KV/DEV"
        # Параметр определяет путь до ключа с расширением для списка доверенных сертификатов
        secretName: "extra_ca"
    # Настройка получения сертификатов для доступа к БД отдельного хранения данных аудита из PKI движка Secret Management System
    postgresAudit:
      # Путь до PKI движка
      pkiPath: "PKI/DEV"
      # Common name выпускаемого сертификата
      commonName: "postgres-audit-common-name"
      # Дополнительные имена к common name
      altNames: ""
      # Срок действия сертификата в часах (h), минутах (m) или секундах (s). Если не указан, будет использоваться значение ttl для PKI роли
      ttl: "2160h"
      # Настройка обогащения CA сертификатов из KV хранилища в Secret Management System
      enrichCA:
        enabled: false
        # Параметр определяет путь до Key-Value хранилища с расширением для списка доверенных сертификатов
        kvPath: "A/DEV/IDMX/KV/DEV"
        # Параметр определяет путь до ключа с расширением для списка доверенных сертификатов
        secretName: "extra_ca"
    # Настройка получения сертификатов для доступа к системной БД idmx-datapipe из PKI движка Secret Management System
    postgresDatapipe:
      # Путь до PKI движка
      pkiPath: "PKI/DEV"
      # Common name выпускаемого сертификата
      commonName: "postgres-datapipe-common-name"
      # Дополнительные имена к common name
      altNames: ""
      # Срок действия сертификата в часах (h), минутах (m) или секундах (s). Если не указан, будет использоваться значение ttl для PKI роли
      ttl: "2160h"
      # Настройка обогащения CA сертификатов из KV хранилища в Secret Management System
      enrichCA:
        enabled: false
        # Параметр определяет путь до Key-Value хранилища с расширением для списка доверенных сертификатов
        kvPath: "A/DEV/IDMX/KV/DEV"
        # Параметр определяет путь до ключа с расширением для списка доверенных сертификатов
        secretName: "extra_ca"
    # Настройка получения сертификатов для доступа к системной БД idmx-engine для idmx-datapipe из PKI движка Secret Management System
    postgresDatapipeEngine:
      # Путь до PKI движка
      pkiPath: "PKI/DEV"
      # Common name выпускаемого сертификата
      commonName: "postgres-datapipe-engine-common-name"
      # Дополнительные имена к common name
      altNames: ""
      # Срок действия сертификата в часах (h), минутах (m) или секундах (s). Если не указан, будет использоваться значение ttl для PKI роли
      ttl: "2160h"
      # Настройка обогащения CA сертификатов из KV хранилища в Secret Management System
      enrichCA:
        enabled: false
        # Параметр определяет путь до Key-Value хранилища с расширением для списка доверенных сертификатов
        kvPath: "A/DEV/IDMX/KV/DEV"
        # Параметр определяет путь до ключа с расширением для списка доверенных сертификатов
        secretName: "extra_ca"
    # Настройка получения сертификатов для доступа к системной БД отдельного хранения данных аудита для idmx-datapipe из PKI движка Secret Management System
    postgresDatapipeAudit:
      # Путь до PKI движка
      pkiPath: "PKI/DEV"
      # Common name выпускаемого сертификата
      commonName: "postgres-datapipe-audit-common-name"
      # Дополнительные имена к common name
      altNames: ""
      # Срок действия сертификата в часах (h), минутах (m) или секундах (s). Если не указан, будет использоваться значение ttl для PKI роли
      ttl: "2160h"
      # Настройка обогащения CA сертификатов из KV хранилища в Secret Management System
      enrichCA:
        enabled: false
        # Параметр определяет путь до Key-Value хранилища с расширением для списка доверенных сертификатов
        kvPath: "A/DEV/IDMX/KV/DEV"
        # Параметр определяет путь до ключа с расширением для списка доверенных сертификатов
        secretName: "extra_ca"
    # Настройка получения сертификатов для интеграции с сервисом Platform V Audit SE из PKI движка Secret Management System
    audit:
      # Путь до PKI движка
      pkiPath: "PKI/DEV"
      # Common name выпускаемого сертификата
      commonName: "audit-common-name"
      # Дополнительные имена к common name
      altNames: ""
      # Срок действия сертификата в часах (h), минутах (m) или секундах (s). Если не указан, будет использоваться значение ttl для PKI роли
      ttl: "2160h"
      # Настройка обогащения CA сертификатов из KV хранилища в Secret Management System
      enrichCA:
        enabled: false
        # Параметр определяет путь до Key-Value хранилища с расширением для списка доверенных сертификатов
        kvPath: "A/DEV/IDMX/KV/DEV"
        # Параметр определяет путь до ключа с расширением для списка доверенных сертификатов
        secretName: "extra_ca"
    # Настройка получения сертификатов для интеграции с компонентом LOGA продукта Platform V Monitor, либо другим журналом логирования на Kafka, из PKI движка Secret Management System, для отправки сообщений аудита
    datapipeKafka:
      # Путь до PKI движка
      pkiPath: "PKI/DEV"
      # Common name выпускаемого сертификата
      commonName: "datapipe-kafka-common-name"
      # Дополнительные имена к common name
      altNames: ""
      # Срок действия сертификата в часах (h), минутах (m) или секундах (s). Если не указан, будет использоваться значение ttl для PKI роли
      ttl: "2160h"
      # Настройка обогащения CA сертификатов из KV хранилища в Secret Management System
      enrichCA:
        enabled: false
        # Параметр определяет путь до Key-Value хранилища с расширением для списка доверенных сертификатов
        kvPath: "A/DEV/IDMX/KV/DEV"
        # Параметр определяет путь до ключа с расширением для списка доверенных сертификатов
        secretName: "extra_ca"
    # Настройка получения сертификатов для интеграции с компонентом LOGA продукта Platform V Monitor, либо другим журналом логирования на Kafka, из PKI движка Secret Management System
    kafka:
      # Путь до PKI движка
      pkiPath: "PKI/DEV"
      # Common name выпускаемого сертификата
      commonName: "kafka-common-name"
      # Дополнительные имена к common name
      altNames: ""
      # Срок действия сертификата в часах (h), минутах (m) или секундах (s). Если не указан, будет использоваться значение ttl для PKI роли
      ttl: "2160h"
      # Настройка обогащения CA сертификатов из KV хранилища в Secret Management System
      enrichCA:
        enabled: false
        # Параметр определяет путь до Key-Value хранилища с расширением для списка доверенных сертификатов
        kvPath: "A/DEV/IDMX/KV/DEV"
        # Параметр определяет путь до ключа с расширением для списка доверенных сертификатов
        secretName: "extra_ca"
    # Настройка получения сертификатов для интеграции с журналом логирования на Loki из PKI движка Secret Management System
    loki:
      # Путь до PKI движка
      pkiPath: "PKI/DEV"
      # Common name выпускаемого сертификата
      commonName: "loki-common-name"
      # Дополнительные имена к common name
      altNames: ""
      # Срок действия сертификата в часах (h), минутах (m) или секундах (s). Если не указан, будет использоваться значение ttl для PKI роли
      ttl: "2160h"
      # Настройка обогащения CA сертификатов из KV хранилища в Secret Management System
      enrichCA:
        enabled: false
        # Параметр определяет путь до Key-Value хранилища с расширением для списка доверенных сертификатов
        kvPath: "A/DEV/IDMX/KV/DEV"
        # Параметр определяет путь до ключа с расширением для списка доверенных сертификатов
        secretName: "extra_ca"
    # Настройка получения сертификатов для интеграции с Platform V SOWA из PKI движка Secret Management System
    sowa:
      # Путь до PKI движка
      pkiPath: "PKI/DEV"
      # Common name выпускаемого сертификата
      commonName: "sowa-common-name"
      # Дополнительные имена к common name
      altNames: ""
      # Срок действия сертификата в часах (h), минутах (m) или секундах (s). Если не указан, будет использоваться значение ttl для PKI роли
      ttl: "2160h"
      # Настройка обогащения CA сертификатов из KV хранилища в Secret Management System
      enrichCA:
        enabled: false
        # Параметр определяет путь до Key-Value хранилища с расширением для списка доверенных сертификатов
        kvPath: "A/DEV/IDMX/KV/DEV"
        # Параметр определяет путь до ключа с расширением для списка доверенных сертификатов
        secretName: "extra_ca"
    # Настройка получения сертификатов для интеграции с АС Reflex из PKI движка Secret Management System
    reflex:
      # Путь до PKI движка
      pkiPath: "PKI/DEV"
      # Common name выпускаемого сертификата
      commonName: "reflex-common-name"
      # Дополнительные имена к common name
      altNames: ""
      # Срок действия сертификата в часах (h), минутах (m) или секундах (s). Если не указан, будет использоваться значение ttl для PKI роли
      ttl: "2160h"
      # Настройка обогащения CA сертификатов из KV хранилища в Secret Management System
      enrichCA:
        enabled: false
        # Параметр определяет путь до Key-Value хранилища с расширением для списка доверенных сертификатов
        kvPath: "A/DEV/IDMX/KV/DEV"
        # Параметр определяет путь до ключа с расширением для списка доверенных сертификатов
        secretName: "extra_ca"

# Настройка интеграции с fluent-bit
fluent:
  enabled: false
  # Настройка используемого образа fluent-bit sidecars
  image:
    # Адрес реестра с образами. Если не указан, используется значение переменной global.registry
    registry: ""
    # Название репозитория в реестре, где находится образ
    repository: "fluent/fluent-bit"
    # Тег образа
    tag: ""
    # Хэш образа, начинается с 'sha256:'. Если указан, имеет приоритет над тегом
    digest: ""
  # Настройка отправки логов в 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

# Запуск Liquibase скриптов для настройки БД
liquibase:
  enabled: false
  # Аннотации для всех ресурсов сервиса (Job, ConfigMap и т.д.). Применяются к metadata.annotations каждого ресурса
  annotations: {}
    # helm.sh/hook: "pre-install,pre-upgrade"
    # argocd.argoproj.io/sync-wave: '-3'
  # Аннотации для Pod. Применяются к spec.template.metadata.annotations в Job
  podAnnotations: {}
  # Устанавливает максимальное время выполнения всей задачи в секундах
  activeDeadlineSeconds: 360
  # Уровень логирования. Возможные значения: OFF, SEVERE, WARNING, INFO, FINE.
  logLevel: "SEVERE"
  # Liquibase properties
  engine:
    # Использование партиционирования при высоких нагрузках
    highload: "ON"
    # Схема хранения для установки расширений
    extension_schema: "ext"
    # Идентификатор-суффикс принадлежности к инсталляции
    dbSuffix: "pv"
    # Схема хранения
    schemaname: "public"
    # Режим создания индекса для таблицы. CONCURRENTLY - создание индекса без блокировки записей
    m_object_online: "CONCURRENTLY"
    # Режим компрессии. Возможные значения: lz4 и pglz
    m_object_compress: "pglz"
    # Значение CACHE sequence для таблицы ma_audit_event_id
    ma_audit_event_id_seq_cache: "50"
    # Значение CACHE sequence для таблицы ma_audit_ref_id
    ma_audit_ref_id_seq_cache: "50"
    # Значение CACHE sequence для таблицы m_uri_id
    m_uri_id_seq_cache: "50"
    # Значение CACHE sequence для таблицы m_ext_item_id
    m_ext_item_id_seq_cache: "50"
  datapipe:
    # Использование партиционирования при высоких нагрузках
    highload: "OFF"
    # Схема хранения для установки расширений
    extension_schema: "ext"
    # Идентификатор-суффикс принадлежности к инсталляции
    dbSuffix: "pv"
    # Схема хранения
    schemaname: "public"
    # Режим создания индекса для таблицы. CONCURRENTLY - создание индекса без блокировки записей
    batch_job_instance_online: "CONCURRENTLY"
    # Режим компрессии. Возможные значения: lz4 и pglz
    batch_job_instance_compress: "pglz"
    # Значение CACHE sequence для таблицы batch_step_execution
    batch_step_execution_seq_cache: "50"
    # Значение CACHE sequence для таблицы batch_job_execution
    batch_job_execution_seq_cache: "50"
    # Значение CACHE sequence для таблицы batch_job
    batch_job_seq_cache: "50"

  # Настройка используемого образа idmx-liquibase
  image:
    # Адрес реестра с образами. Если не указан, используется значение переменной global.registry
    registry: ""
    # Название репозитория в реестре, где находится образ
    repository: ""
    # Тег образа
    tag: ""
    # Хэш образа, начинается с 'sha256:'. Если указан, имеет приоритет над тегом
    digest: ""

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

  # Приоритет выполнения для idmx-liquibase в кластере
  priorityClassName: null
  # Включение распределения экземпляров idmx-liquibase по разным узлам среды исполнения.
  # Если true - планировщик попытается распределить экземпляры idmx-liquibase по разным узлам.
  # При невозможности такого распределения, экземпляры все равно будут запланированы.
  selfAntiAffinity: false
  # Стратегия обновления, которая определяет, как заменяются старые поды новыми.
  strategy:
    # 'Recreate' — удаляет все существующие поды перед созданием новых.
    # 'RollingUpdate' — заменяет старые ReplicaSets на новые постепенно, уменьшая количество старых реплик и увеличивая новые.
    type: "RollingUpdate"
    # Параметры rolling-обновления. Присутствует только если type = RollingUpdate.
    rollingUpdate:
      # Параметр определяет, сколько подов может быть недоступно во время обновления.
      maxUnavailable: 0
      # Параметр определяет, насколько можно превысить желаемое число подов.
      maxSurge: 25%

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

  # Настройка sidecars приложения idmx-liquibase
  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
    mesh:
      # Вычислительные ресурсы, необходимые sidecar контейнеру Service Mesh
      resources:
        requests:
          # Количество ядер процессора, которое будет запрошено для контейнера
          cpu: 400m
          # Минимальный объем оперативной памяти, который будет запрошен для контейнера
          memory: 512Mi
        limits:
          # Максимальное количество ядер процессора, которое будет выделено для контейнера
          cpu: 400m
          # Максимальный объем оперативной памяти, который будет выделен для контейнера
          memory: 1Gi

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

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

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

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

Компонент idmx-connector-server (далее Connector Server) предназначен для подключения IDMX к ресурсам, расположенным вне контура, в котором находится инсталляция IDMX. Подробнее смотрите в разделе Установка Connector Server.

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

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

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

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

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

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

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

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

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

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

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

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

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