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

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

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

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

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

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

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

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

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

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

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

  • Для idmx-engine:

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

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

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

  • Для idmx-ui:

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

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

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

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

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

  1. Распакуйте дистрибутив с бинарными файлами IDMX в отдельную директорию.

  2. Откройте терминал (командную строку) и перейдите в директорию с Dockerfile для сборки соответствующего компонента. Например, package/docker/idmx-engine/ для сборки образа idmx-engine.

  3. Соберите образы компонентов idmx-engine и idmx-ui стандартными средствами Docker. При сборке укажите в команде сборки требуемый базовый образ при помощи аргумента --build-arg="BASE_IMAGE=<образ>" команды docker build. Например, --build-arg="BASE_IMAGE=image:123"

    Обратите внимание, при сборке образа потребуется указать ID пользователя. По умолчанию это 11111, заданный в строке Dockerfile RUN useradd -M -u 11111 -d /app -s /bin/bash app, однако при необходимости этот ID можно изменить. В случае изменения, сохраните новый ID, он понадобится в процессе установки.

  4. Поместите (push) собранные образы в Docker Repository.

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

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

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

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

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

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

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

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

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

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

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

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

    1. postgres-new.sql

    2. postgres-new-audit.sql

    3. postgres-new-quartz.sql

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    CREATE EXTENSION IF NOT EXISTS intarray;

    CREATE EXTENSION IF NOT EXISTS pg_trgm;

    CREATE EXTENSION IF NOT EXISTS fuzzystrmatch;

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

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

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

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

    GRANT execute ON all FUNCTIONS in SCHEMA idm_schema TO idm_user;

    GRANT EXECUTE ON ALL PROCEDURES IN SCHEMA idm_schema TO idm_user;

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

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

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

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

    1. postgres-new.sql

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

    CREATE SCHEMA IF NOT EXISTS …;

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

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

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

    1. postgres-new-audit.sql

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

    CREATE SCHEMA IF NOT EXISTS …;

    1. postgres-new-quartz.sql

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

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

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

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

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

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

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

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

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

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

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

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

Установка IDMX#

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

  1. Распакуйте дистрибутив с конфигурационными файлами IDMX в отдельную директорию.

  2. Подготовьте манифесты компонентов к установке:

    1. Для idmx-engine — откройте манифест объекта StatefulSet (package/conf/helm/application/idmx/charts/idmx-engine/templates/idmx-sts-engine.yaml) и в поле spec:template:spec:containers:image укажите путь до собранного на этапе подготовки пререквизитов образа компонента idmx-engine

    Обратите внимание, путь до образа задан с переменными. Скорректировать следует только часть пути вне переменных. Например, если в файле приведено значение вида:

    {{ .Values.global.registry }}{{ .Values.global.registryPath }}/idmx/idmx-engine@sha256:824d287749aa818b4c1a817

    Переменная {{ .Values.global.registry }} определяет хост Docker Registry, а переменная {{ .Values.global.registryPath }} — путь до каталога с образами, в который помещены образы компонентов IDMX. Значения обеих переменных задаются в конфигурационном файле далее в инструкции. На данном этапе следует задать только оставшуюся часть пути до образа idmx-engine, включая требуемые тэги. В примере это /idmx/idmx-engine@sha256:824d287749aa818b4c1a817.

    1. Для idmx-ui — аналогично предыдущему пункту укажите в манифесте объекта Deployment (package/conf/helm/application/idmx/charts/idmx-ui/templates/idmx-deploy-ui.yaml) в поле spec:template:spec:containers:image путь до собранного образа idmx-ui.

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

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

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

        1. Заполнить базовые параметры для развертывания IDMX:

          • global.orchestrator: <оркестратор> — используемая система оркестрации контейнеризированных приложений. Возможные варианты: k8s — Kubernetes, ose — OpenShift;

          • global.serviceAccountName: default` — имя Service Account, которое будет использоваться для запуска модулей;

          • global.clusterDomain: <домен namespace кластера>, например mydomain.ru — домен, на который настроена маршрутизация Ingress Controller для доступа к развернутым в namespace контейнерам. Используется для построения пути (URL) к развернутым контейнерам IDMX;

          • global.registry: <имя хоста>, например registry.myserver.ru — хост, по которому доступен Docker Registry;

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

          • `global.ingress: настроить ingress для разворачиваемых приложений, согласно установленному Ingress Controller.

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

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

          • global.repository.database.mtls = false.

        3. Отключить излишние интеграции:

          • idmx-egress-gateway.enabled: false;

          • idmx-ingress-gateway.enabled: false;

          • idmx-connector-server.enabled: false;

          • global.istio.enabled: false;

          • global.audit.enabled: false;

          • global.secman.enabled: false;

          • global.fluent.enabled: false;

          • global.reflex.enabled: false.

        4. Задать значения security-context для устанавливаемых компонентов IDMX. Для этого следует в основном values.yaml переопределить следующие параметры:

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

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

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

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

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

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

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

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

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

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

    idmx-engine:
  enabled: true
  replicas: 2

    Все параметры доступные для переопределения и их описание приведены в конфигурационных файлах values.yaml компонентов, расположенных в дистрибутиве по пути package/conf/helm/application/idmx/charts/<имя компонента>m

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

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

    , где:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • Если используется механизм Kubernetes Secrets:

      В Kubernetes перейдите в namespace IDMX и создайте Secret с названием secret-idm.1 и типом Opaque. Поместите в него следующие key-value пары. Обратите внимание, значения в полях value должны быть закодированы в формате base64.

      • idm_engine_keystore_password — Пароль от хранилища ключей IDMX (смотрите шаг 7). Обязательно;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • Если используется механизм Kubernetes Secrets:

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

        base64 --wrap=0 idmx-keystore.jceks

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

      2. Создайте в namespace IDMX Secret с именем idmx-secret и типом Opaque, и добавьте в него следующую key-value пару:

        • keystore.jceks = полученная после шифровки idmx-keystore.jceks в base64 строка.

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

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

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

        base64 idmx-keystore.jceks

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

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

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

  8. Создайте в namespace IDMX сервис-аккаунт (имя задается переменной global.serviceAccountName). Убедитесь, что данный сервис-аккаунт имеет роль, дающую ему права на создание и на изменение объектов.

  9. Создайте в namespace IDMX Secret, содержащий логин и пароль для доступа к Docker Repository. Привяжите данный секрет к сервис-аккаунту.

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

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

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

      • istio_ingress_engine_cert и istio_ingress_engine_key для idmx-engine;

      • istio_ingress_connector_server_cert и istio_ingress_connector_server_key для idmx-connector-server;

      • istio_ingress_ui_cert и istio_ingress_ui_key для idmx-ui.

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

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

      • istio_ingress_engine_ca для idmx-engine;

      • istio_ingress_connector_server_ca для idmx-connector-server;

      • istio_ingress_ui_ca для idmx-ui.

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

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

      Все сертификаты должны быть помещены в отдельные Kubernetes Secrets. Для этого необходимо:

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

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

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

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

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

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

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

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

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

        1. openssl pkcs12 -export -name logger_kafka_cert -in logger_kafka_cert -inkey logger_kafka_key -out logger_kafka_p12

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

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

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

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

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

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

        4. openssl pkcs12 -export -name istio_ingress_connector_server_cert -in istio_ingress_connector_server_cert -inkey istio_ingress_connector_server_key -out istio_ingress_connector_server_p12

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  12. Установите IDMX в namespace. Для этого:

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

  14. Подключитесь к namespace Kubernetes через утилиту kubectl.

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

  16. В директории выполните команду helm upgrade -i idmx ..

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    , где:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Установка:

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

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

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

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

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

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

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

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

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

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

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

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

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

    • connectorserver.protocol=WEB_SOCKET

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

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

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

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

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

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

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

      , где:

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

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

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

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

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

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

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

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

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

      , где:

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

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

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

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

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

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

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

    • connectorserver.usessl=true

    • connectorserver.protocol=WEB_SOCKET

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Запуск Connector Server#

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • На Windows 10:

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

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

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

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

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

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

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

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

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

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

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

</connectorHost>

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

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

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