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

В данном варианте установка дистрибутива производится полуавтоматизированным способом при помощи инструмента Helm.

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

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

Минимальным набором ПО будет:

  • Kubernetes 1.26+

  • Helm 3.8+

  • PostgreSQL 13.4+

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

Также для Kubernetes потребуется установить и настроить утилиту kubectl и сервис Ingress Controller.

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

Перед установкой необходимо получить Docker-образы всех компонентов IDM и поместить их в Docker Registry.

Если образы уже получены — данный раздел можно пропустить.

В случае, если образы не поставляются в дистрибутиве IDM, следует собрать образы из компонентов дистрибутива IDM при помощи Docker.

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

  • Для engine:

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

    • Утилита для распаковки архивов UnZip.

  • Для ui:

    • Сервер приложений (рекомендуется Platform V SynGX);

    • Утилита для распаковки архивов UnZip.

  • Для idmc-connectors:

    • Утилита для распаковки архивов UnZip.

Более подробно про требуемые версии системного ПО смотрите в разделе документации «Системные требования».

После подготовки базовых образов, соберите образы компонентов IDM (engine, ui и опционально idmc-connectors) следующим образом:

  1. Распакуйте дистрибутив IDM idm-<version>-distrib.zip в отдельную директорию. Дальнейшие действия следует производить из этой директории.

  2. Для сборки понадобятся скрипты, которые находятся в idm-<version>-owned-distrib/idmx-bin-<version>-distrib/package/scripts/delivery-lite. Также необходим python3 и пакеты из delivery-lite/requirements.txt. Для корректной работы скриптов, добавьте python модули в PYTHONPATH следующей командой: export PYTHONPATH=idm-<version>-owned-distrib/idmx-bin-<version>-distrib/package/scripts/delivery-lite.

  3. Сгенерируйте конфигурационный файл следующей командой:

       python3 idm-<version>-owned-distrib/idmx-bin-<version>-distrib/package/scripts/delivery-lite/src/scripts/generate_config.py \
             --owned_distrib idm-<version>-owned-distrib.zip \
             --docker_file_masks '["**/engine/Dockerfile", "**/ui/Dockerfile", "**/idmc-connectors-zip/Dockerfile"]'
    
  4. При необходимости, определите в созданном конфигурационном файле delivery-lite.yaml параметры для собираемого образа. Например, для engine:

       images:
          idmx-engine:sha256:
          image_name: registry_path/engine
          build:
             tags:
                - custom_tag
             build_args:
                BASE_IMAGE: base_image
          push: {}
    

    Параметры собираемых образов idmx-ui и idmc-connectors переопределяются аналогично.

  5. Объедините (merge) архивы и соберите Docker образы следующими командами:

       python3 idm-<version>-owned-distrib/idmx-bin-<version>-distrib/package/scripts/delivery-lite/src/scripts/build_product.py \
             --docker_tool 'docker' \
             --push_images false \
             --config_path delivery-lite.yaml \
             --docker_file_masks '["**/idmx-engine/Dockerfile", "**/idmx-ui/Dockerfile", "**/idmc-connectors-zip/Dockerfile"]' \
             --dependency_resolver_jar_path idm-<version>-owned-distrib/idmx-bin-<version>-distrib/package/scripts/delivery-lite/dependency-resolver-1.0.0.jar
    
  6. Поместите собранные образы в Docker Registry.

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

Подготовку системной БД можно сделать одним из двух способов: вручную или автоматически при помощи 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
    

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

При высокой нагрузке на 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 раздела Последовательность действий.

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

Базовая установка IDM включает в себя установку основных модулей развертывания (engine, ui и опционально idmc-connectors). Установка всех модулей производится посредством инструмента Helm.

  1. Перед установкой Helm chart, нужно создать необходимые Kubernetes Secrets:

    1. Секрет для доступа в Docker Registry:

         kubectl create secret docker-registry idm-regsitry \
               --docker-server=docker_server \
               --docker-username=docker_user \
               --docker-password=some_password
      
    2. Секрет с хранилищем ключей IDMX:

      1. Создаем само хранилище ключей:

        keytool -genseckey -alias default -keystore keystore.jceks -storetype jceks -storepass changeit -keyalg AES -keysize 256 -keypass midpoint, где changeit — пароль от хранилища ключей IDMX.

      2. Создаем Kubernetes Secret:

        kubectl create secret generic idmx-secret --from-file=keystore.jceks

    3. Секрет с чувствительными данными:

         kubectl create secret generic secret-idm.2 \
               --from-literal=idm_engine_repository_db_username=admin \
               --from-literal=idm_engine_repository_db_password='pass' \
               --from-literal=idm_engine_keystore_password='pass'
      

      , где

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

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

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

  2. Распакуйте дистрибутив с конфигурационными файлами IDMX (idmx-cfg) в отдельную директорию.

  3. Заполните конфигурационные файлы соответствующими значениями. Для этого:

    1. Перейдите в директорию package/conf/helm/application/idmx/, создайте и откройте в текстовом редакторе файл values-custom.yaml. В этом файле определите конфигурацию для конкретной инсталляции IDM. Задайте для его параметров требуемые значения.

      global:

      • global.imagePullSecrets — секрет для доступа в Docker Registry;

      Для engine:

      • engine.image.registry - адрес реестра с образами;

      • engine.image.repository - название репозитория в реестре, где находится образ;

      • engine.image.tag - тег образа. Чтобы использовать тег, нужно определить для sha пустое значение «»;

      • engine.image.digest - хеш образа, начинается с „sha256:“. Если указан, имеет приоритет над тегом;

      • engine.database.url - URL, по которому IDMX будет подключаться к системной БД. Например, jdbc:postgresql://pangolin.db.mycorp.ru:5432/idmx-1?prepareThreshold=0;

      • engine.database.mtls - используется ли mTLS при подключении к БД. В рамках данной инструкции следует указать false. Подробнее о подключении mTLS за защиты соединения с БД IDM смотрите в подразделе Защита соединения с БД по SSL и типы Service Mesh.

      • engine.ingress.ingressClassName - название Ingress Controller, например, nginx;

      • engine.ingress.annotations - аннотации для Ingress Controller, например, для nginx: nginx.ingress.kubernetes.io/ssl-passthrough: 'false';

      • engine.ingress.host - доменное имя для engine;

      • engine.securityContext.runAsUser: <ID пользователя>, например 11111 — ID пользователя, который был задан на этапе сборки образа компонента. По умолчанию следует задавать 11111, если самостоятельно значение не изменялось;

      • engine.securityContext.runAsGroup: <ID группы пользователя>, например 11111 — ID группы пользователя, который был задан на этапе сборки образа компонента. По умолчанию следует задавать 11111, если самостоятельно значение не изменялось;

      • engine.securityContext.fsGroup: <ID группы>, например 11111 — ID группы пользователей, задаваемой для всех файлов тома, монтируемого в контейнер engine. По умолчанию следует задавать 11111, если самостоятельно значение не изменялось;

      Для стартового контейнера (init-container) с коннекторами для engine (опционально):

      • engine.initConnectorsLoad.type - тип источника стартового контейнера. В рамках данной инструкции используется образ, поэтому следует указать "container";

      • engine.initConnectorsLoad.image.registry - адрес реестра с образами;

      • engine.initConnectorsLoad.image.repository - название репозитория в реестре, где находится образ;

      • engine.initConnectorsLoad.image.tag - тег образа;

      • engine.initConnectorsLoad.image.digest - хеш образа, начинается с „sha256:“. Если указан, имеет приоритет над тегом;

      • engine.initConnectorsLoad.runAsUser - <ID пользователя>, например 11111 — ID пользователя, который был задан на этапе сборки образа компонента. По умолчанию следует задавать 11111, если самостоятельно значение не изменялось;

      • engine.initConnectorsLoad.runAsGroup - <ID группы>, например 11111 — ID группы пользователей, задаваемой для всех файлов тома, монтируемого в контейнер engine. По умолчанию следует задавать 11111, если самостоятельно значение не изменялось;

      Для ui:

      • ui.image.registry - адрес реестра с образами;

      • ui.image.repository - название репозитория в реестре, где находится образ;

      • ui.image.tag - тег образа. Чтобы использовать тег, нужно определить для sha пустое значение «»;

      • ui.image.sha - хеш образа, начинается с „sha256:“. Если указан, имеет приоритет над тегом;

      • ui.ingress.host - доменное имя для ui;

      • ui.ingress.ingressClassName - название Ingress Controller для ui, например, nginx;

      • ui.ingress.annotations - аннотации для Ingress Controller, например, для nginx: nginx.ingress.kubernetes.io/ssl-passthrough: 'false';

      • ui.securityContext.runAsUser: <ID пользователя>, например 11111 — ID пользователя, который был задан на этапе сборки образа компонента. По умолчанию следует задавать 11111, если самостоятельно значение не изменялось;

      • ui.securityContext.runAsGroup: <ID группы пользователя>, например 11111 — ID группы пользователя, который был задан на этапе сборки образа компонента. По умолчанию следует задавать 11111, если самостоятельно значение не изменялось;

      • ui.securityContext.fsGroup: <ID группы>, например 11111 — ID группы пользователей, задаваемой для всех файлов тома, монтируемого в контейнер ui. По умолчанию следует задавать 11111, если самостоятельно значение не изменялось;

  4. Установите IDMX в пространство имен. Для этого:

    1. Откройте терминал (командную строку).

    2. Подключитесь к пространству имен Kubernetes через утилиту kubectl.

    3. Перейдите в директорию package/conf/helm/application/idmx/ распакованного дистрибутива с конфигурациями IDMX (в директорию с основным values.yaml).

    4. В директории выполните команду helm upgrade -i idmx . -f values-custom.yaml.

    5. Дождитесь окончания установки. Статус установки будет отображаться в сообщениях в терминале (командной строке).

  5. Чтобы попасть в UI IDMX перейдите в UI Kubernetes, откройте пространство имен IDMX и на вкладке Networking -> Ingresses найдите Ingress для ui. Скопируйте URL в поле host и перейдите по нему на новой вкладке браузера.

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

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

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

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

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

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

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

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

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

  8. Подготовлено окружение.

  9. Контейнеризированные компоненты IDMX установлены.

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

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

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

    • 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 при наличии корректных сертификатов и настроек.

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

Дополнительные инструкции к установке#

Дополнительные инструкции по установке и настройке различных элементов конфигурации IDM и интеграций приведены в разделе Дополнительные инструкции.

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

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

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

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

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

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

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

engine:
  enabled: true
  replicas: 2

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

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#

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