Установка через 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) следующим образом:
Распакуйте дистрибутив IDM
idm-<version>-distrib.zipв отдельную директорию. Дальнейшие действия следует производить из этой директории.Для сборки понадобятся скрипты, которые находятся в
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.Сгенерируйте конфигурационный файл следующей командой:
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"]'При необходимости, определите в созданном конфигурационном файле
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переопределяются аналогично.Объедините (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Поместите собранные образы в Docker Registry.
Подготовка системной БД#
Подготовку системной БД можно сделать одним из двух способов: вручную или автоматически при помощи Liquibase скриптов.
Подготовка системной БД вручную#
Перед запуском установки IDMX также необходимо установить и настроить СУБД, которая будет использоваться для управления системной БД IDMX. Установка производится согласно документации на выбранную СУБД (Platform V Pangolin SE или PostgreSQL). Для подготовки системной БД IDMX:
Войдите в СУБД под пользователем
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).
Выйдите из УЗ
postgresи войдите под созданным пользователемidm_user. Затем выполните для БДidm_dbтри скрипта подготовки БД в следующей последовательности:postgres-new.sqlpostgres-new-audit.sqlpostgres-new-quartz.sql
Поскольку владельцем БД в СУБД является пользователь
idm_user, скрипты подготовки следует запускать из под его учетной записи. Скрипты проводят подготовку БД, включая создание нужных таблиц и настройку реляционных связей.
Скрипты подготовки БД расположены по пути <distrib>/idmx-dbinit-<версия>-distrib.zip/package/db/idmx-dbinit-engine.zip.
Подготовка БД вручную при отсутствии прав OWNER#
В случае, если требования информационной безопасности запрещают выдавать пользователям и администраторам системной БД IDMX права уровня OWNER, подготовку БД следует провести следующим образом:
Войдите в СУБД под пользователем
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 не возможности выполнять действия по созданию БД и пользователей в СУБД (например, если требования информационной безопасности запрещают доступ к СУБД всем пользователям, кроме администраторов СУБД), данные действия следует выполнять пользователям или администраторам с соответствующими правами.
Под пользователем
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 на СУБД, эти команды необходимо выполнить вручную при помощи администраторов СУБД или других пользователей с соответствующими правами.
Под пользователем
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 отсутствуют.Выйдите из УЗ
postgresи войдите под созданным пользователемidm_user. Затем выполните для БДidm_dbтри скрипта подготовки БД в следующей последовательности:postgres-new.sqlpostgres-new-audit.sqlpostgres-new-quartz.sql
Исполните скрипт без изменений
Поскольку владельцем БД в СУБД является пользователь
idm_user, скрипты подготовки следует запускать из под его учетной записи. Скрипты проводят подготовку БД, включая создание нужных таблиц и настройку реляционных связей.
Автоматическая настройка БД при помощи Liquibase скриптов#
Чтобы воспользоваться данной функциональностью Deploy job при установке IDMX, следует провести следующую подготовку:
Создать БД (например,
idm_db) и пользователя (например,idm_user) в используемой СУБД.Обратите внимание, пользователь должен иметь права OWNER для корректной установки.
Если не используется SecMan:
Если для подключения к БД не требуется mTLS:
В стендозависимом конфигурационном файле
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. Необязательный параметр.
В файл
_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>
Отредактируйте
environment.json:"useSecretManagerForPipelineCreds": "false","useSecretManagerForSecretFiles": "false"
В файле
common.conf.ymlдобавьте значение параметраidmx.liquibase.repository.database.schema: idm_schema.
Если для подключения к БД требуется mTLS (смотрите раздел Защита соединения с БД по SSL и типы Service Mesh):
В стендозависимом конфигурационном файле
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. Необязательный параметр.
Поместите сертификаты, необходимые для подключения к системной БД, в JKS хранилище сертификатов:
Создайте хранилище из сертификатов:
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.Конвертируйте хранилище в требуемый формат JKS:
keytool -importkeystore -srckeystore СОЗДАННОЕ_РАНЕЕ_ХРАНИЛИЩЕ.p12 -srcstoretype pkcs12 -destkeystore КОНЕЧНОЕ_ХРАНИЛИЩЕ.jks-deststoretype JKS. Например,keytool -importkeystore -srckeystore keystore.p12 -srcstoretype pkcs12 -destkeystore KeyStore.jks -deststoretype JKS.Добавьте ЦА сертификат в 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
Поместите полученное JKS хранилище в common репозиторий по пути
ansible/files/ssl/KeyStore.jks.В файл
ssl.confдобавьте следующие параметры:ssl.jdbc.KeyStoreFromFile=ansible/files/ssl/KeyStore.jks;ssl.jdbc.TrustStoreFromFile=ansible/files/ssl/KeyStore.jks.
В
_passwords.confдобавьте пароли от JKS хранилища:ssl.jdbc.keyStorePassword=password;ssl.jdbc.trustStorePassword=password.
Выполните действия в пунктах 2-5 для сертификатов, необходимых для подключения к БД аудита, в случае если используется функциональность раздельного хранения данных аудита.
В файле
custom_property.conf.ymlв стендозависимой директории/conf/helm/application/репозитория конфигурации добавьте значение параметраidmx.liquibase.repository.database.schema: idm_schema.
Если используется SecMan:
Если для подключения к БД не требуется mTLS:
В стендозависимом конфигурационном файле
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.
Поместите в 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>"
Отредактируйте стендозависимый файл
environment.json:
"useSecretManagerForPipelineCreds": "fail","useSecretManagerForSecretFiles": "fail";
В стендозависимом файле
_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.
Чтобы получать секреты из 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 %}В файле
common.conf.ymlдобавьте значение параметраidmx.liquibase.repository.database.schema: idm_schema.
Если для подключения к БД требуется mTLS (смотрите раздел Защита соединения с БД по SSL и типы Service Mesh):
В стендозависимом конфигурационном файле
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.
Поместите сертификаты, необходимые для подключения к БД, в JKS хранилище сертификатов:
Создайте хранилище из сертификатов:
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.Конвертируйте хранилище в требуемый формат JKS:
keytool -importkeystore -srckeystore СОЗДАННОЕ_РАНЕЕ_ХРАНИЛИЩЕ.p12 -srcstoretype pkcs12 -destkeystore КОНЕЧНОЕ_ХРАНИЛИЩЕ.jks-deststoretype JKS. Например,keytool -importkeystore -srckeystore keystore.p12 -srcstoretype pkcs12 -destkeystore KeyStore.jks -deststoretype JKS.Добавьте ЦА сертификат в 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
Поместите полученное JKS хранилище в SecMan в по пути
<НУЖНОЕ>/<ПРОСТРАНСТВО>/<В>/<SECMAN>/jdbc_keystore.jks(значение в base64):"secretFileBase64": "Полученное JKS хранилище, закодированное как строка формата base64"В SecMan в по пути
<НУЖНОЕ>/<ПРОСТРАНСТВО>/<В>/<SECMAN>/ssl.jdbc.keyStorePasswordдобавьте пароль от JKS хранилища ключей (значение не в base64):"ssl.jdbc.keyStorePassword": "пароль"В SecMan в по пути
<НУЖНОЕ>/<ПРОСТРАНСТВО>/<В>/<SECMAN>/ssl.jdbc.trustStorePasswordдобавьте пароль от доверенного JKS хранилища (truststore) (значение не в base64):"ssl.jdbc.trustStorePassword": "пароль"Выполните действия в пунктах 2-5 для сертификатов, необходимых для подключения к БД аудита, в случае если используется функциональность раздельного хранения данных аудита.
Отредактируйте стендозависимый файл
environment.json:"useSecretManagerForPipelineCreds": "fail","useSecretManagerForSecretFiles": "fail";
В стендозависимом файле
_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.
Чтобы получать секреты из 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 %}Чтобы получать сертификаты из 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' }}В файле
custom_property.conf.ymlв стендозависимой директории/conf/helm/application/репозитория конфигурации добавьте значение параметраidmx.liquibase.repository.database.schema: idm_schema.
Ручной запуск Liquibase скриптов для настройки БД#
Также Liquibase скрипты можно запустить вручную. Liquibase написан на Java, поэтому может быть запущен на машине с предустановленной JAVA (рекомендуется OpenJDK 11).
Для ручного запуска Liquibase скриптов:
Разархивируйте архив расположенный по пути:
idmx-bin-<версия>-distrib/db/idmx-db-liquibase-engine.zipВ директорию с разархивированными файлами необходимо добавить следующие файлы из дистрибутива:
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.Разместите все файлы в одной директории, чтобы получилось следующее:
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Выполните запуск скриптов следующей командой:
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 предоставляет возможность хранить данные аудита в отдельной БД.
Обратите внимание, для сайзинга отдельной БД для хранения данных аудита можно воспользоваться инструкцией в разделе Системные требования.
Чтобы перейти на использование раздельного хранения данных аудита следует:
Остановить
idmx-engineв пространстве имен IDMX.Создать и настроить новую БД:
Создать пользователя.
Создать схему (если треубется использовать не
public).Установить схему для пользователя (
ALTER ROLE <username> SET search_path TO <schema>;).
Перенести данные аудита из системной БД IDMX в новую БД. Для этого:
Получить и распаковать архив со скриптами переноса данных. Архив содержит в себе:
main.sh— скрипт переноса данных;env.properties— файл со свойствами, которые нужно заполнить;deleteAuditTables.sql— SQL скрипт удаления таблиц из старой базы;audit-4.7.sql— SQL скрипт создания таблиц аудита в новой базе.
Заполнить значения переменных среды в файле
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.Запустить на выполнение скрипт
main.sh. Скрипт выполнит следующие шаги:Создание полной резервной копии базы (на случай непредвиденных ситуаций).
Дамп таблиц аудита для переноса данных в новую базу.
Создание таблиц аудита в новой базе.
Загрузка данных аудита в новую базу.
Удаление таблиц аудита из старой базы (с подтверждением).
Обратите внимание, архивы с дампом БД не удаляются и не перезаписываются, чтобы предотвратить непреднамеренную потерю данных.
В стендозависмых параметрах стенда в файле
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
Добавить секреты в систему хранения секретов (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 к БД аудита.
Задеплоить
idmx-engineс новыми параметрами.
Данная инструкция также применима, если в пункте 6 будет происходить обновление IDMX с версии 1.0/1.1/1.2 на 1.4.
Также обратите внимание на раздел Работа с записями аудита
Настройка Secret Management System#
Secret Management System следует настраивать согласно документации на этот продукт. После установки и настройки Secret Management System следует провести его подготовку для использования с IDMX следующим образом:
Завести хранилище KV (key-value). Хранилище должно быть типа «KV хранилище».
Тип: «kv» — версия 1 модуля Key-Value, соответствует пути KV.
Пример пути:
ACC/IDMX/FH/KV.Получить роль, тенант (пространство имен).
Дать доступ роли из пространства имен контейнеризированной среды в Secret Management.
Загрузить секреты и сертификаты в Secret Management по пути из пункта 1 в подпапку
KEYSTORE(значения в кодировке Base64). Итоговый путь к расположению сертификатов в Secret Management System будет выглядеть, например, так:ACC/IDMX/FH/KV/KEYSTORE.Подробнее о кодировании в base64 и загрузке секретов и сертификатов будет рассказано в инструкции в разделе Установка.
Обратите внимание.
Для корректной работы автоматической ротации сертификатов при их выпуске через Secret Management System, требуется:
Настроить и выпустить корректные сертификаты, согласно документации на Secret Management System.
Заполнить в корневом файле конфигурации группу параметров
secman.pkiSecretsEngine.
Настройка логирования#
IDMX помимо ведения логирования собственными средствами, предоставляет возможность отправки записей журнала событий в несколько внешних систем. Для интеграции с ними следует:
Выбрать один или несколько сервисов, в которые будут отправляться сообщения: Kafka (например, оттуда забирает сообщения компонент LOGA продукта Platform V Monitor) или Loki.
Заполнить соответствующие атрибуты раздела
fluentкорневого конфигурационного файла (смотроите раздел Миграция конфигурационных файлов) корректными значениями.При использовании mTLS для защиты соединений, получите сертификаты для защищенного подключения:
logger_kafkaдля отправки сообщений в Platform V Monitor (или другой сервис, использующий брокеры Kafka), илиlogger_lokiдля отправки сообщений в Loki соответственно. Подробнее смотрите пункт 10 раздела Последовательность действий.
Последовательность действий#
Базовая установка IDM включает в себя установку основных модулей развертывания (engine, ui и опционально idmc-connectors). Установка всех модулей производится посредством инструмента Helm.
Перед установкой Helm chart, нужно создать необходимые Kubernetes Secrets:
Секрет для доступа в Docker Registry:
kubectl create secret docker-registry idm-regsitry \ --docker-server=docker_server \ --docker-username=docker_user \ --docker-password=some_passwordСекрет с хранилищем ключей IDMX:
Создаем само хранилище ключей:
keytool -genseckey -alias default -keystore keystore.jceks -storetype jceks -storepass changeit -keyalg AES -keysize 256 -keypass midpoint, гдеchangeit— пароль от хранилища ключей IDMX.Создаем Kubernetes Secret:
kubectl create secret generic idmx-secret --from-file=keystore.jceks
Секрет с чувствительными данными:
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 будет подключаться к системной БД.
Распакуйте дистрибутив с конфигурационными файлами IDMX (idmx-cfg) в отдельную директорию.
Заполните конфигурационные файлы соответствующими значениями. Для этого:
Перейдите в директорию
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, если самостоятельно значение не изменялось;
Установите IDMX в пространство имен. Для этого:
Откройте терминал (командную строку).
Подключитесь к пространству имен Kubernetes через утилиту kubectl.
Перейдите в директорию
package/conf/helm/application/idmx/распакованного дистрибутива с конфигурациями IDMX (в директорию с основнымvalues.yaml).В директории выполните команду
helm upgrade -i idmx . -f values-custom.yaml.Дождитесь окончания установки. Статус установки будет отображаться в сообщениях в терминале (командной строке).
Чтобы попасть в UI IDMX перейдите в UI Kubernetes, откройте пространство имен IDMX и на вкладке Networking -> Ingresses найдите Ingress для
ui. Скопируйте URL в поле host и перейдите по нему на новой вкладке браузера.
Проверка результата#
Установка IDMX можно считать успешной, если:
На сервере развернуто необходимое ПО из раздела Системные требования;
На том же сервере развернута и настроена БД Platform V Pangolin SE или PostgreSQL согласно документации на используемую СУБД. Также проведена предварительная подготовка БД к использованию IDMX, согласно инструкции из раздела Подготовка системной БД.
БД доступна по порту (по умолчанию 5432) из кластера системы оркестрации контейнеризированных приложений.
Созданы docker-образы
idmx-engine,idmx-ui,idmx-connector-server(подраздел Сборка образов IDMX).Выделен проект системы оркестрации контейнеризированных приложений.
Произведена настройка проекта системы оркестрации контейнеризированных приложений согласно документации на используемую систему оркестрации.
Произведена первоначальная настройка БД (подраздел Подготовка системной БД).
Подготовлено окружение.
Контейнеризированные компоненты IDMX установлены.
Для каждого из модулей IDM —
idmx-engine,idmx-ui,idmx-connector-server— readiness и liveness пробы используемой системы оркестрации контейнеризированных приложений возвращают статус Ready.Для каждой из используемых интеграций — проверить, что каждый компонент корректно установлен и сконфигурирован, согласно документации на компонент. Затем проверить, что интеграции корректно сконфигурированы на стороне IDMX (раздел Установка через Installer, подраздел Интеграции с платформенными зависимостями).
Проверить подключения к интеграциям. Для этого следует удостовериться, что:
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#
Подробная информация о настройке интеграции приведена в разделе Дополнительные инструкции.