Настройки параметров IDM#

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Важно

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

Оптимизация использования памяти контейнера при длительной работе GC#

В случае, если у контейнера idmx-engine возникают проблемы с выделяемыми ресурсами, связанные с излишне долгой работой GC (Garbage Collector), рекомендуется задать следующие параметры:

idmx-engine.javaOptsExtra = -XX:NativeMemoryTracking=summary -XX:+AlwaysPreTouch -server -XX:InitialRAMPercentage=50.0 -XX:+UseContainerSupport -XX:MaxRAMPercentage=70.0 -XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:+ExitOnOutOfMemoryError

Повышение безопасности механизма авторизации#

По умолчанию Platform V IDM хранит привилегии доступа пользователя в текущей сессии. При изменении привилегий, IDM помечает сессию как невалидную, и при следующем запросе в рамках сессии происходит перерасчет привилегий доступа. Такое поведение может привести к ситуациям, когда количество перерасчетов будет перегружать систему и предоставлять возможность воспользоваться устаревшими привилегиями.

Для повышения уровня безопасности механизма авторизации следует добавить следующий блок в systemConfiguration:

<internals>
    <sessions>
        <invalidateByTime>
            <enabled>true</enabled> <!--default - false-->
            <timeSec>60</timeSec>   <!--default - 60-->
        </invalidateByTime>
    </sessions>
</internals>

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

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

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

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

Важно

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

Режим распределенного кластера#

Platform V IDM также поддерживает возможность работы в режиме распределенного кластера (мультиЦОД), когда узлы кластера расположены в разных пространствах имен среды оркестрации контейнеризированных приложений (центрах обработки данных, или ЦОД). В таком случае, в каждом пространстве имен должна быть проведена полная инсталляция IDMX, и проведена дополнительная настройка:

  1. Перед запуском установки включите кластерный режим IDMX, заполнив все требуемые параметры.

  2. Заполните параметры группы multidc в корневом файле конфигурации следующим образом:

    • enabled — true;

    • cluster — данный блок следует заполнить массивами, содержащими домены и IP-адреса балансировщиков для каждого из узлов IDMX, включая узел, конфигурация которого заполняется.

      Например, для узлов idmx1 в домене namespace1, idmx2 в домене namespace2 и idmx3 в домене namespace3 блок cluster будет выглядеть следующим образом:

      cluster:
  - domain: namespace1-domainname.mycorp
    balancer: 111.111.111.111
  - domain: namespace2-domainname.mycorp
    balancer: 222.222.222.222
  - domain: namespace3-domainname.mycorp
    balancer: 121.212.121.212

    • maxReplicas.idmxEngine — укажите максимальное количество реплик контейнера idmx-engine для данного узла кластера.

  3. Получите от администраторов сервиса интеграции и оркестрации микросервисов в облаке (например, Platform V Synapse Service Mesh) сертификаты для установки защищенного соединения между узлами в разных ЦОД и поместите их в систему хранения секретов.

  4. Установите все сконфигурированные узлы IDMX.

  5. При необходимости, сконфигурируйте задачи, которые должны обрабатываться в кластерном режиме, согласно инструкции в разделе Масштабирование задач документа Руководство пользователя.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • engine.database.mtls в true;

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

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

    • serviceMesh.type в rhsm;

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

Важно

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • engine.database.mtls в true;

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

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

    • serviceMesh.type в synapse;

    • serviceMesh.enabled в true.

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

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

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

Важно

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

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

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

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

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

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

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

    , где:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Монтирование дополнительных файлов в файловую систему контейнеров#

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

Например, для добавления конфигурацию Kerberos в контейнер idmx-engine для настройки безопасного доступа следует:

  1. Создать ConfigMap kerberos-config c krb5.conf.

  2. Добавить монтирование в корневой файл конфигурации в секцию соответствующего модуля, к примеру, для idmx-engine:

    idmx-engine:
   enabled: true
   extraVolumes:
      - name: kerberos-volume
        configMap:
           name: kerberos-config
           items:
            - key: krb5.conf
              path: krb5.conf
   extraVolumeMounts:
      - name: kerberos-volume
        mountPath: /etc/config

Конфигурация выше смонтирует в контейнер idmx-engine конфигурацию krb5.conf по пути <корневой каталог>/etc/config.