Руководство по установке#

В руководстве приведены инструкции по установке компонента Поисковый движок (SRHX) продукта Platform V Search (SRH).

Расшифровку основных понятий смотрите в перечне Термины и определения.

Системные требования#

Настройки безопасности окружения и перечень платформенных (дополнительных внешних) продуктов, используемых для установки, настройки и контроля в конечной информационной системе (далее — ИС), выбираются при разработке конечной ИС, исходя из характера обрабатываемой в ней информации и иных требований информационной безопасности (далее — ИБ), предъявляемых к ней.

Системное программное обеспечение#

Ниже представлены категории системного программного обеспечения (далее — ПО), которые обязательны или опциональны для установки, настройки, контроля и функционирования компонента SRHX. В каждой категории перечислены все поддерживаемые продукты сторонних правообладателей. Отдельно обозначены варианты, которые рекомендует АО «СберТех» (маркировка «Рекомендовано» в столбце «Продукт, функциональная совместимость с которым подтверждена»). Клиенту необходимо выбрать один из продуктов в каждой категории, исходя из условий использования конечной ИС.

Примечание

*

• Да — категория ПО обязательна для функционирования сервиса (это означает, что сервис не может выполнять свои базовые функции без установки данной категории ПО).

• Нет — категория ПО необязательна для функционирования сервиса (это означает, что сервис может выполнять свои базовые функции без установки данной категории ПО).

**

• Рекомендовано — рекомендованный правообладателем АО «СберТех» продукт.

• Опционально — альтернативный по отношению к рекомендованному правообладателем АО «СберТех» продукт.

Платформенные зависимости#

Для настройки, контроля и функционирования компонента реализована интеграция с программными продуктами, правообладателем которых является АО «СберТех»:

Примечание

***

• Да — компонент или продукт необходим для функционирования сервиса (это означает, что сервис не может выполнять свои основные функции без установки данного компонента).

• Нет — необязательный для функционирования сервиса компонент или продукт (это означает, что сервис может выполнять свои основные функции без установки данного компонента).

**** Рекомендуется установка программного продукта, правообладателем которого является АО «СберТех», при этом не исключена возможность (допускается правообладателем) использования аналога других производителей. Аналоги, в отношении которых продукт успешно прошел испытания и подтвердил свою работоспособность, указаны в разделе «Системное программное обеспечение».

Аппаратные требования#

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

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

Требования к окружению для установки программного компонента#

Компонент SRHX не выдвигает требований к настройкам безопасности окружения.

Состав дистрибутива#

Выбор способа установки#

Единственным и целевым способом установки является ручной способ.

Подготовка окружения#

Создание пользователей на сервере#

1. Создайте пользователей:

• opensearch – для сервера opensearch;

• opensearch-dashboards – для сервера opensearch-dashboards, в том случае, если он будет устанавливаться на данном сервере.

2. Добавьте созданных пользователей в необходимые группы.

   Ниже представлен пример, когда пользователи созданы с таким же паролем, как и их имя. Возможно изменить значения после passwd -1 на необходимые:

   sudo useradd -p $(openssl passwd -1 opensearch) opensearch
   sudo useradd -p $(openssl passwd -1 opensearch-dashboards) opensearch-dashboards
   sudo usermod -aG opensearch-dashboards opensearch
   sudo usermod -aG opensearch opensearch-dashboards
   

Установка java#

Установите последнюю доступную в репозитории Java 17. Удалите директорию /usr/share/opensearch/jdk, если существует. Выполните symlink из /etc/alternatives/jre в /usr/share/opensearch/jdk.

ln -s /etc/alternatives/jre /usr/share/opensearch/jdk

Добавление переменных для работы компонента SRHX#

1. Пропишите системные переменные в файл .bashrc. Переменные пользователей, под которыми будет выполнен запуск компонента SRHX:

• OPENSEARCH_JAVA_HOME;

• OPENSEARCH_PATH_CONF;

• OSD_PATH_CONF.

2. Примените обновленный файл командой source.

   Ниже описан алгоритм для пользователей opensearch и opensearch-dashboards:

   sudo sh -c "echo -e 'export OPENSEARCH_JAVA_HOME=/usr/share/opensearch/jdk\nexport OPENSEARCH_PATH_CONF=/etc/opensearch\nexport OSD_PATH_CONF=/etc/opensearch-dashboards' >> /home/opensearch/.bashrc && source /home/opensearch/.bashrc"
   sudo sh -c "echo -e 'export OPENSEARCH_JAVA_HOME=/usr/share/opensearch/jdk\nexport OPENSEARCH_PATH_CONF=/etc/opensearch\nexport OSD_PATH_CONF=/etc/opensearch-dashboards' >> /home/opensearch-dashboards/.bashrc && source /home/opensearch-dashboards/.bashrc"
   

   • OPENSEARCH_JAVA_HOME – путь до JAVA, который будет использовать компонент SRHX. При использовании JAVA вместе с дистрибутивом, заранее укажите путь, где будет находиться Java, после распаковки дистрибутива.

   • OPENSEARCH_PATH_CONF и OSD_PATH_CONF – пути до каталога с конфигурационными файлами для сервера opensearch-dashboards.

Изменение параметров компонента SRHX#

1. Установите значение системных параметров vm.max_map_count = 262144 и vm.swappiness=0 в файле /etc/sysctl.conf.

2. Примените обновленные значения командой sysctl -p.

3. Отключите использование swap:

   sudo swapoff -a
   sudo sh -c "echo -e 'vm.swappiness=0\nvm.max_map_count=262144' >> /etc/sysctl.conf && sysctl -p"
   

Внимание!

Обязательно проверьте значения в данном файле. Если они уже присутствуют, то их необходимо изменить вручную. После применения команды, указанной выше, произойдет дублирование параметров, если они уже существуют. Команда swapoff -a работает только до перезагрузки.

4. Проверьте текущее значение или примененные изменения командой:

   cat /proc/sys/vm/max_map_count
   

Изменение лимитов пользователей#

Повысьте лимиты для пользователей, которые будут выполнять запуск компонента SRHX. Это позволит в дальнейшем запускать программы вручную и не получать ошибки от компонента SRHX.

1. Создайте файлы /etc/security/limits.d/opensearch.conf и /etc/security/limits.d/opensearch-dashboards.conf и внесите в них данные, используя следующие команды:

   #для создания файлов /etc/security/limits.d/opensearch.conf , /etc/security/limits.d/opensearch-dashboards.conf и установки лимитов SRHX
   sudo sh -c "echo -e 'opensearch      -       nproc   65535\nopensearch      -       nofile  500000\nopensearch      -       memlock unlimited' >> /etc/security/limits.d/opensearch.conf"
   sudo sh -c "echo -e 'opensearch-dashboards   -       nproc   8096\nopensearch-dashboards   -       nofile  8096' >> /etc/security/limits.d/opensearch-dashboards.conf"
   

   После исполнения команд файлы должны иметь вид:

   #для /etc/security/limits.d/opensearch.conf
   opensearch - nofile 500000
   opensearch - nproc 65535
   opensearch - memlock unlimited
   
   
   #для /etc/security/limits.d/opensearch-dashboards.conf
   opensearch-dashboards - nofile 8096
   opensearch-dashboards - nproc 8096
   

2. Проверьте, что параметр для пользователя задан верно и его значение равно установленному в предыдущем пункте. Проверка возможна только под пользователем, для которого применяли значение:

   sudo su opensearch -c 'ulimit -u -n -l'
   sudo su opensearch-dashboards -c 'ulimit -u -n'
   

3. Посмотрите полный список лимитов:

   sudo su opensearch -c 'ulimit -a'
   sudo su opensearch-dashboards -c 'ulimit -a'
   

Создание необходимых директорий#

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

sudo mkdir /usr/share/opensearch \
sudo mkdir -p /etc/opensearch/secman/certs \
sudo mkdir /etc/opensearch/usertoken \
sudo mkdir /var/log/opensearch \
sudo mkdir /var/lib/opensearch
 
#если на данную виртуальную машину устанавливается opensearch-dashboards
sudo mkdir /usr/share/opensearch-dashboards \
sudo mkdir -p /etc/opensearch-dashboards/secman/certs \
sudo mkdir /etc/opensearch-dashboards/usertoken \
sudo mkdir /var/log/opensearch-dashboards

Подробное описание директорий

Создайте пустые файлы для переменных компонента SRHX, которые он считывает при запуске. Ссылаться на эти файлы нужно в Unit service:

sudo touch /etc/sysconfig/opensearch
 
#если на данную виртуальную машину устанавливается opensearch-dashboards
sudo touch /etc/sysconfig/opensearch-dashboards

Повышение привилегий пользователя#

Выдайте права пользователю opensearch на управление unit-сервисом, который будет создан далее.

Примечание

Это может понадобиться только для удобства работы под пользователем opensearch.

sudo nano /etc/sudoers.d/opensearch

Добавьте:

opensearch ALL=(ALL) NOPASSWD: /bin/systemctl start opensearch.service, /bin/systemctl start opensearch
opensearch ALL=(ALL) NOPASSWD: /bin/systemctl restart opensearch.service, /bin/systemctl restart opensearch
opensearch ALL=(ALL) NOPASSWD: /bin/systemctl stop opensearch.service, /bin/systemctl stop opensearch
opensearch ALL=(ALL) NOPASSWD: /bin/systemctl enable opensearch.service, /bin/systemctl enable opensearch
opensearch ALL=(ALL) NOPASSWD: /bin/systemctl disable opensearch.service, /bin/systemctl disable opensearch
opensearch ALL=(ALL) NOPASSWD: /bin/systemctl start opensearch-dashboards.service, /bin/systemctl start opensearch-dashboards
opensearch ALL=(ALL) NOPASSWD: /bin/systemctl restart opensearch-dashboards.service, /bin/systemctl restart opensearch-dashboards
opensearch ALL=(ALL) NOPASSWD: /bin/systemctl stop opensearch-dashboards.service, /bin/systemctl stop opensearch-dashboards
opensearch ALL=(ALL) NOPASSWD: /bin/systemctl enable opensearch-dashboards.service, /bin/systemctl enable opensearch-dashboards
opensearch ALL=(ALL) NOPASSWD: /bin/systemctl disable opensearch-dashboards.service, /bin/systemctl disable opensearch-dashboards
opensearch ALL=(ALL) NOPASSWD: /bin/systemctl daemon-reload

Необходимый софт на сервере#

Внимание!

Установить:

node.js – требуется для работы и запуска dashboards; unzip (если не установлен по умолчанию в системе); nano (или любой другой редактор текста).

Установка#

Ручная установка сервиса#

Перед началом установки убедитесь, что выполнена подготовка окружения.

Распаковка дистрибутива#

Внимание!

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

1. Загрузите полученный дистрибутив на сервер, распакуйте его и перейдите в созданную директорию:

   unzip srhx-1.5.0-*-distrib.zip -d /tmp && cd /tmp/srhx/
   

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

   [user@vm-name srhx]$ pwd
   /tmp/srhx/
   [user@vm-name srhx]$ ls -l
   -rw-r--r-- 1 user     root     327821009 Mar  5 20:54 dashboard-1.5.0.zip
   -rw-r--r-- 1 root     root       2045982 Mar  5 20:47 index-management-dashboards-1.5.0.zip
   -rw-r--r-- 1 root     root        756487 Mar  5 20:45 notifications-dashboards-1.5.0.zip
   -rw-r--r-- 1 root     root      14842422 Mar  5 21:54 opensearch-index-management-1.5.0.zip
   -rw-r--r-- 1 root     root       9198790 Mar  5 22:04 opensearch-job-scheduler-1.5.0.zip
   -rw-r--r-- 1 root     root       4919467 Mar  5 21:59 opensearch-notifications-1.5.0.zip
   -rw-r--r-- 1 root     root      10896680 Mar  5 21:59 opensearch-notifications-core-1.5.0.zip
   -rw-r--r-- 1 root     root     101699727 Mar  5 21:40 opensearch-security-1.5.0.zip
   -rw-r--r-- 1 root     root      44754603 Mar  5 22:11 opensearch-sql-1.5.0.zip
   -rw-r--r-- 1 root     root      44754603 Mar  5 22:11 opensearch-knn-1.5.0.zip
   -rw-r--r-- 1 root     root        150311 Mar  5 22:07 prometheus-exporter-1.5.0.zip
   -rw-r--r-- 1 root     root       2700708 Mar  5 20:47 queryWorkbenchDashboards-1.5.0.zip
   -rw-r--r-- 1 root     root          7771 Mar  5 21:50 search-healthcheck-plugin-1.5.0.zip
   -rw-r--r-- 1 root     root     232892620 Mar  5 20:29 search-server-1.5.0.zip
   -rw-r--r-- 1 root     root       1170157 Mar  5 20:44 security-dashboards-1.5.0.zip
   -rw-r--r-- 1 root     root       1170157 Mar  5 20:44 opensearch-custom-codecs-1.5.0.zip
   

Краткое описание распакованных компонентов

Установка компонента SRHX#

Выполните команды для распаковки дистрибутива:

sudo unzip -q ./search-server-*.zip -d /usr/share/opensearch/
sudo mv /usr/share/opensearch/config/* /etc/opensearch/ && sudo rm -rf /usr/share/opensearch/config/
sudo sh -c "echo -e 'path.data: /var/lib/opensearch\npath.logs: /var/log/opensearch' >> /etc/opensearch/opensearch.yml"
sudo mv opensearch-security-*.zip opensearch-sql-*.zip opensearch-index-management-*.zip opensearch-job-scheduler-*.zip opensearch-notifications-*.zip opensearch-notifications-core-*.zip prometheus-exporter-*.zip search-healthcheck-plugin-*.zip opensearch-knn-*.zip opensearch-custom-codecs-*.zip /usr/share/opensearch/

Описание общего списка команд#

1. Распакуйте сервер в директорию /usr/share/opensearch:

   sudo unzip -q ./search-server-1.5.0.zip -d /usr/share/opensearch/
   

2. Переместите конфигурационные файлы из /usr/share/opensearch/config в заранее созданную директорию, для конфигурационных файлов компонента Поискового движка SRHX – /etc/opensearch и удалите пустую директорию /usr/share/opensearch/config:

   sudo mv /usr/share/opensearch/config/* /etc/opensearch/ && sudo rm -rf /usr/share/opensearch/config/
   

3. Укажите директории в конфигурационном файле OpenSearch, где он будет хранить данные кластера (path.data) и логи (path.logs). В примере ниже данные кластера будут храниться по пути /var/lib/opensearch, а логи в /var/log/opensearch, если требуется изменить места хранения, то укажите корректные директории в командах ниже.

   sudo sh -c "echo -e 'path.data: /var/lib/opensearch\npath.logs: /var/log/opensearch' >> /etc/opensearch/opensearch.yml"
   

4. Переместите плагины в домашнюю директорию компонента Поисковый движок (SRHX):

   sudo mv \
   opensearch-sql-*.zip \
   opensearch-security-*.zip \
   opensearch-index-management-*.zip \
   opensearch-job-scheduler-*.zip \
   opensearch-notifications-core-*.zip \
   opensearch-notifications-*.zip \
   prometheus-exporter-*.zip \
   opensearch-knn-*.zip \
   search-healthcheck-plugin-*.zip \
   opensearch-custom-codecs-*.zip \
   /usr/share/opensearch/
   

Установка Dashboards#

Примечание

Dashboards используется один на весь кластер. Не устанавливайте Dashboards на каждый сервер, где стоит компонент Поисковый движок SRHX.

Внимание!

Используйте команды ниже, только если требуется установить Dashboards на сервер, с которым работаете в данный момент.

Общий список выполняемых команд для распаковки дистрибутива:

sudo unzip -q ./dashboards-*.zip -d /usr/share/opensearch-dashboards/
sudo mv security-dashboards-*.zip queryWorkbenchDashboards-*.zip index-management-dashboards-*.zip notifications-dashboards-*.zip /usr/share/opensearch-dashboards/
sudo mv /usr/share/opensearch-dashboards/config/* /etc/opensearch-dashboards/ && sudo rm -rf /usr/share/opensearch-dashboards/config/

Описание общего списка команд выше#

1. Распакуйте сервер в директорию /usr/share/opensearch-dashboards:

   sudo unzip -q ./dashboards-1.5.0.zip -d /usr/share/opensearch-dashboards/
   

2. Переместите плагины для opensearch-dashboards к нему в домашнюю директорию:

   sudo mv security-dashboards-1.5.0.zip queryWorkbenchDashboards-1.5.0.zip index-management-dashboards-1.5.0.zip notifications-dashboards-1.5.0.zip /usr/share/opensearch-dashboards/
   

3. Переместите конфигурационные файлы /usr/share/opensearch-dashboards/config в заранее созданную директорию для конфигурационных файлов компонента Поискового движка SRHX - /etc/opensearch-dashboards и удалите пустую директорию /usr/share/opensearch-dashboards/config:

   sudo mv /usr/share/opensearch-dashboards/config/* /etc/opensearch-dashboards/ && sudo rm -rf /usr/share/opensearch-dashboards/config/
   

Установка прав. Наделение правами владельца#

После распаковки измените владельцев директорий и выставите необходимые права.

sudo chown -R opensearch:opensearch /usr/share/opensearch
sudo chown -R opensearch:opensearch /var/log/opensearch
sudo chown -R opensearch:opensearch /var/lib/opensearch
sudo chown -R opensearch:opensearch /etc/opensearch
sudo chown opensearch:opensearch /etc/sysconfig/opensearch

sudo chown -R opensearch-dashboards:opensearch-dashboards /usr/share/opensearch-dashboards
sudo chown -R opensearch-dashboards:opensearch-dashboards /var/log/opensearch-dashboards
sudo chown -R opensearch-dashboards:opensearch-dashboards /etc/opensearch-dashboards
sudo chown opensearch-dashboards:opensearch-dashboards /etc/sysconfig/opensearch-dashboards


sudo chmod 740 /var/lib/opensearch
sudo chmod 750 /usr/share/opensearch
sudo chmod 750 /usr/share/opensearch/logs
sudo chmod 750 -R /usr/share/opensearch/bin
sudo chmod 750 -R /usr/share/opensearch/plugins
sudo chmod 750 -R /var/log/opensearch
sudo chmod 750 /etc/opensearch
sudo chmod 0700 -R /etc/opensearch/secman
sudo chmod 770 -R /etc/opensearch/usertoken

sudo chmod 750 /usr/share/opensearch-dashboards
sudo chmod 750 -R /usr/share/opensearch-dashboards/bin
sudo chmod 750 -R /usr/share/opensearch-dashboards/plugins
sudo chmod 750 -R /var/log/opensearch-dashboards
sudo chmod 750 /etc/opensearch-dashboards
sudo chmod 0700 -R /etc/opensearch-dashboards/secman
sudo chmod 770 -R /etc/opensearch-dashboards/usertoken

Установка плагинов#

Команды по установке плагинов могут быть применены, только в том случае, если валидно заполнен файл opensearch.yml.

Установка плагинов от пользователя opensearch на opensearch-server#

1. При распаковке дистрибутива все плагины перемещены в корневую директорию программы /usr/share/opensearch/. Далее при установке плагинов будет использоваться указанный путь.

2. Если плагины находятся в другом месте, укажите полный путь до них и проверьте, имеется ли доступ туда у пользователя opensearch.

   Внимание!

   Установку плагинов выполните от пользователя, под которым запускается компонент SRHX. Для компонента Поисковый движок (SRHX) используйте пользователя – opensearch.(Не устанавливайте плагины из-под root!)

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

   sudo su - opensearch -c 'yes | /usr/share/opensearch/bin/opensearch-plugin install \
   file:///usr/share/opensearch/opensearch-knn-1.5.0.zip \
   file:///usr/share/opensearch/opensearch-custom-codecs-1.5.0.zip \
   file:///usr/share/opensearch/opensearch-sql-1.5.0.zip \
   file:///usr/share/opensearch/opensearch-security-1.5.0.zip \
   file:///usr/share/opensearch/opensearch-job-scheduler-1.5.0.zip \
   file:///usr/share/opensearch/opensearch-index-management-1.5.0.zip \
   file:///usr/share/opensearch/opensearch-notifications-core-1.5.0.zip \
   file:///usr/share/opensearch/opensearch-notifications-1.5.0.zip \
   file:///usr/share/opensearch/search-healthcheck-plugin-1.5.0.zip \
   file:///usr/share/opensearch/prometheus-exporter-1.5.0.zip'
   

   Возможна установка плагинов по одиночке:

   sudo su - opensearch -c 'yes | /usr/share/opensearch/bin/opensearch-plugin install file:///usr/share/opensearch/opensearch-security-1.5.0.zip'
   

3. После установки плагина безопасности появятся скрипты:

• securityadmin.sh;

• hash.sh;

• audit_config_migrater.sh,

которые находятся по пути /usr/share/opensearch/plugins/opensearch-security/tools. Необходимо сделать их исполняемыми.

sudo chmod +x \
/usr/share/opensearch/plugins/opensearch-security/tools/securityadmin.sh \
/usr/share/opensearch/plugins/opensearch-security/tools/hash.sh \
/usr/share/opensearch/plugins/opensearch-security/tools/audit_config_migrater.sh

4. После установки плагина безопасности потребуется настройка шифрования. Для тестового запуска можно временно отключить плагин безопасности и проверить работоспособность программы. Для этого в файл /etc/opensearch/opensearch.yml добавьте строку plugins.security.disabled: true.

   sudo sh -c "echo -e 'plugins.security.disabled: true' >> /etc/opensearch/opensearch.yml"
   

Установка плагинов от пользователя opensearch-dashboards на opensearch-dashboards#

1. При распаковке дистрибутива все плагины перемещены в корневую директорию программы usr/share/opensearch-dashboards/. Далее при установке плагинов будет использоваться указанный путь.

2. Если плагины находятся в другом месте, укажите полный путь до них и проверьте, имеется ли доступ туда у пользователя opensearch-dashboards.

   Внимание!

   Установку плагинов выполните от пользователя, под которым запускается компонент SRHX. Для компонента Поисковый движок (SRHX) используйте пользователя – opensearch-dashboards.(Не устанавливайте плагины из-под root!)

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

   sudo su - opensearch-dashboards -c 'yes | /usr/share/opensearch-dashboards/bin/opensearch-dashboards-plugin install file:///usr/share/opensearch-dashboards/security-dashboards-1.5.0.zip'
   sudo su - opensearch-dashboards -c 'yes | /usr/share/opensearch-dashboards/bin/opensearch-dashboards-plugin install file:///usr/share/opensearch-dashboards/notifications-dashboards-1.5.0.zip'
   sudo su - opensearch-dashboards -c 'yes | /usr/share/opensearch-dashboards/bin/opensearch-dashboards-plugin install file:///usr/share/opensearch-dashboards/index-management-dashboards-1.5.0.zip'
   sudo su - opensearch-dashboards -c 'yes | /usr/share/opensearch-dashboards/bin/opensearch-dashboards-plugin install file:///usr/share/opensearch-dashboards/queryWorkbenchDashboards-1.5.0.zip'
   

Создание Unit services и их запуск#

1. Убедитесь, что все пути указаны корректно.

2. Создайте точки монтирования в RAM для Server:

   sudo nano /etc/systemd/system/etc-opensearch-secman-secrets.mount
   

3. Добавьте:

   [Unit]
   Description=Mount /etc/opensearch/secman/secrets
   DefaultDependencies=no
   Before=shutdown.target reboot.target halt.target
   
   [Mount]
   What=tmpfs
   Where=/etc/opensearch/secman/secrets
   Type=tmpfs
   Options=mode=0700,uid=opensearch,gid=opensearch,size=100m
   ForceUnmount=true
   
   [Install]
   WantedBy=multi-user.target shutdown.target reboot.target halt.target
   

4. Создайте точки монтирования в RAM для Dashboards:

   sudo nano /etc/systemd/system/etc-opensearch\\x2ddashboards-secman-secrets.mount
   

5. Добавьте:

   [Unit]
   Description=Mount /etc/opensearch-dashboards/secman/secrets
   DefaultDependencies=no
   Before=shutdown.target reboot.target halt.target
   
   [Mount]
   What=tmpfs
   Where=/etc/opensearch-dashboards/secman/secrets
   Type=tmpfs
   Options=mode=0700,uid=opensearch-dashboards,gid=opensearch-dashboards,size=100m
   ForceUnmount=true
   
   [Install]
   WantedBy=multi-user.target shutdown.target reboot.target halt.target
   

6. Создайте Unit services для Server:

   sudo nano /etc/systemd/system/opensearch.service
   

7. Добавьте:

   [Unit]
   Description=Platform V Search
   Wants=network-online.target
   After=network-online.target etc-opensearch-secman-secrets.mount
   
   [Service]
   Type=forking
   RuntimeDirectory=opensearch
   PrivateTmp=true
   
   Environment=MAX_LOCKED_MEMORY=unlimited
   Environment=OPENSEARCH_PATH_CONF=/etc/opensearch
   EnvironmentFile=-/etc/sysconfig/opensearch
   Environment=PID_DIR=/var/run/opensearch
   Environment=KNN_LIB_DIR=/usr/share/opensearch/plugins/opensearch-knn/lib
   Environment=LD_LIBRARY_PATH=/usr/java/packages/lib:/usr/lib64:/lib64:/lib:/usr/lib:/usr/share/opensearch/plugins/opensearch-knn/lib
   
   WorkingDirectory=/usr/share/opensearch
   ExecStartPre=/usr/share/opensearch/bin/init_script.sh
   ExecStart=/usr/share/opensearch/bin/opensearch -d -p ${PID_DIR}/opensearch.pid
   ExecStopPost=/usr/share/opensearch/bin/saving-secman-data.sh
   
   User=opensearch
   Group=opensearch
   
   StandardOutput=journal
   StandardError=inherit
   
   # Service restart - 5 times with an interval of 30 seconds for 200 seconds
   Restart=on-failure
   RestartSec=30
   StartLimitInterval=200
   StartLimitBurst=5
   
   # Unlimited memory lock for service
   LimitMEMLOCK=infinity
   # Specifies the maximum file descriptor number that can be opened by this process
   LimitNOFILE=65535
   # Specifies the maximum number of processes
   LimitNPROC=4096
   # Specifies the maximum size of virtual memory
   LimitAS=infinity
   # Specifies the maximum file size
   LimitFSIZE=infinity
   # Disable timeout logic and wait until process is stopped
   TimeoutStopSec=0
   # SIGTERM signal is used to stop the Java process
   KillSignal=SIGTERM
   # Send the signal only to the JVM rather than its control group
   KillMode=process
   # Java process is never killed
   SendSIGKILL=no
   # When a JVM receives a SIGTERM signal it exits with code 143
   SuccessExitStatus=143
   # Allow a slow startup before the systemd notifier module kicks in to extend the timeout
   TimeoutStartSec=75
   
   [Install]
   WantedBy=multi-user.target
   

8. Создайте Unit services для Dashboards (Если на данном сервере установлен opensearch-dashboards):

   sudo nano /etc/systemd/system/opensearch-dashboards.service
   

9. Добавьте

   [Unit]
   Description=Platform V Search Dashboard
   Wants=network-online.target
   After=network-online.target etc-opensearch\\x2ddashboards-secman-secrets.mount  
   
   [Service]
   Type=simple
   User=opensearch-dashboards
   Group=opensearch-dashboards
   
   Environment=OSD_PATH_CONF=/etc/opensearch-dashboards
   EnvironmentFile=-/etc/sysconfig/opensearch-dashboards
   
   WorkingDirectory=/usr/share/opensearch-dashboards/
   ExecStartPre=/usr/share/opensearch-dashboards/bin/init_script.sh
   ExecStart=/bin/bash -c '/usr/share/opensearch-dashboards/bin/opensearch-dashboards &> /var/log/opensearch-dashboards/stdout.log'
   ExecStopPost=/usr/share/opensearch-dashboards/bin/saving-dashboards-secman-data.sh  
   
   StandardOutput=journal
   StandardError=inherit
   
   # Service restart - 5 times with an interval of 30 seconds for 200 seconds
   Restart=on-failure
   RestartSec=30
   StartLimitInterval=200
   StartLimitBurst=5 
   
   [Install]
   WantedBy=multi-user.target
   

10. Выполните перезагрузку systemd:

    sudo systemctl daemon-reload
    

11. Добавьте точку монтирования в автозагрузку и запустите:

    sudo systemctl enable etc-opensearch-secman-secrets.mount --now
    sudo systemctl enable etc-opensearch\\x2ddashboards-secman-secrets.mount --now
    

12. Добавьте opensearch-services в автозагрузку и запустите:

    sudo systemctl enable opensearch.service --now
    

13. Добавьте opensearch-dashboards-services в автозагрузку и запустите:

    sudo systemctl enable opensearch-dashboards.service --now
    

Настройка компонента SRHX#

Настройка параметров в opensearch.yml#

Большинство настроек компонента SRHX описываются в файле /etc/opensearch/opensearch.yml и считываются при запуске.

Внимание!

Для настройки кластера подготовьте два сертификата с разными CN и подписанные одним УЦ. Один сертификат используется для межкластерного шифрования и шифрования HTTP-уровня. Второй, сертификат администратора, для доступа с правами администратора.

Сертификаты администратора — это обычные клиентские сертификаты с повышенными правами внутри компонента SRHX, для выполнения административных задач. Сертификат администратора необходим для изменения конфигурации плагина безопасности с помощью plugins/opensearch-security/tools/securityadmin.sh или REST API. Сертификаты администратора настраиваются в opensearch.yml путем указания их DN:

plugins.security.authcz.admin_dn:
  - 'CN=<Common Name вашего сертификата администратора>, OU=<Подразделение организации>, O=<Наименование организации, выдавшей сертификат>, STREET=<Наименование улицы, на которой располагается организация>, L=<Населенный пункт, в котором расположена организация>, ST=<Наименование региона, в котором расположен сертификат>, C=<Наименование страны, в которой расположена организация>'

Сертификаты должны быть в формате PKCS#8. Замените все содержимое файла (удалите весь текст в существующем фале) /etc/opensearch/opensearch.yml.

### Шаблон безопасной конфигурации сервера.
### Подставьте необходимые значения там, где требуется.
### Символы < > указывают значения, которые требуется заменить. При подстановке необходимых значений символы < > использовать не нужно.

bootstrap.memory_lock: true

# Настройки хоста
network.host: <FQDN или IP текущего хоста>
http.port: `<Необходимо выбрать один любой порт выше 10000 (например:19200 )>`
transport.port: `<Необходимо выбрать один любой порт выше 10000 (например:19301)>`

# Настройки кластера
cluster.name: <ваше имя кластера>
node.name: <ваше имя текущей node>
node.roles:
  - cluster_manager
  - data
cluster.initial_cluster_manager_nodes:
  - <node.name node 1 в кластере>
  - <node.name node 2 в кластере>
  - <node.name node 3 в кластере>
discovery.seed_hosts:
  - <FQDN или IP node 1 в кластере>:<Значение указанное в параметре "transport.port">
  - <FQDN или IP node 2 в кластере>:<Значение указанное в параметре "transport.port">
  - <FQDN или IP node 3 в кластере>:<Значение указанное в параметре "transport.port">

# Настройки для хранения данных и логов текущей node
path.data: /var/lib/opensearch
path.logs: /var/log/opensearch

  # Настройки плагина Security

#############################################################
## Не отключаемые параметры.
plugins.security.disabled: false
plugins.security.secman.enabled: true
plugins.security.ssl.http.enabled: true
plugins.security.ssl.transport.enabled: true

plugins.security.ssl.http:
  keystore_filepath: "/etc/opensearch/secman/certs/http.jks"
  truststore_filepath: "/etc/opensearch/secman/certs/httptrust.jks"
  enabled_protocols: ["TLSv1.2", "TLSv1.3"]
  enabled_ciphers: ["TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384", "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"]
  clientauth_mode: REQUIRE

plugins.security.ssl.transport:
  keystore_filepath: "/etc/opensearch/secman/certs/transport.jks"
  truststore_filepath: "/etc/opensearch/secman/certs/transport.jks"
  enabled_protocols: ["TLSv1.2", "TLSv1.3"]
  enabled_ciphers: ["TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384", "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"]
  enforce_hostname_verification: true

plugins.security.authcz.admin_dn:
  - 'CN=<Common Name вашего сертификата администратора>, OU=<Подразделение организации>, O=<Наименование организации, выдавшей сертификат>, STREET=<Наименование улицы, на которой располагается организация>, L=<Населенный пункт, в котором расположена организация>, ST=<Наименование региона, в котором расположен сертификат>, C=<Наименование страны, в которой расположена организация>' 
plugins.security.nodes_dn:
  - 'CN=<Common Name межкластерного сертификата/Параметр указанный в plugins.security.secman.transport.cn>, OU=<Подразделение организации>, O=<Наименование организации, выдавшей сертификат>, STREET=<Наименование улицы, на которой располагается организация>, L=<Населенный пункт, в котором расположена организация>, ST=<Наименование региона, в котором расположен сертификат>, C=<Наименование страны, в которой расположена организация>'

plugins.security.audit.type: ru.sbt.audit.PlatformVAuditSink

plugins.security.allow_default_init_securityindex: true
plugins.security.restapi.roles_enabled: "all_access"
plugins.security.system_indices:
  enabled: true
  indices: [".plugins-ml-model", ".plugins-ml-task", ".opendistro-alerting-config", ".opendistro-alerting-alert*", ".opendistro-anomaly-results*", ".opendistro-anomaly-detector*", ".opendistro-anomaly-checkpoints", ".opendistro-anomaly-detection-state", ".opendistro-reports-*", ".opensearch-notifications-*", ".opensearch-notebooks", ".opensearch-observability", ".opendistro-asynchronous-search-response*", ".replication-metadata-store"]
plugins.security.cache.ttl_minutes: 120
## Не отключаемые параметры.
#############################################################

Описание всех параметров указанных в примере opensearch.yml приведены в таблице ниже.

Настройка JVM Heap Size параметров#

Для быстрой и стабильной работы рекомендуется выделять компоненту SRHX 50 процентов оперативной памяти сервера.

Для этого:

1. Unit services компонента SRHX в Linux должен содержать параметры: Environment=MAX_LOCKED_MEMORY=unlimited и LimitMEMLOCK=infinity (прописывается при создании unit service). В лимитах для пользователя opensearch – должен быть установлен параметр opensearch - memlock unlimited (описано в разделе Изменение лимитов пользователей данного документа).

2. В opensearch.yml должен быть прописан параметр bootstrap.memory_lock: со значением true.

Укажите нужное значение в параметрах Java. Для этого откройте файл /etc/opensearch/jvm.options, найдите параметры -Xms и -Xmx и укажите значение в гигабайтах, равное половине оперативной памяти текущего сервера, но не более 32766 Мб.

3. Узнайте размер оперативной памяти на текущем сервере с помощью команды:

   free -g | grep Mem: | awk '{print $2}'
   23
   

4. Отредактируйте параметры в файле с настройками JVM и укажите округленные значения, равные половине числа, полученного в предыдущей команде.

   sudo nano /etc/opensearch/jvm.options
   # JVM configuration
   
   ################################################################
   ## IMPORTANT: JVM heap size
   ################################################################
   
   
   # Xms represents the initial size of total heap space
   # Xmx represents the maximum size of total heap space
   
   -Xms11g
   -Xmx11g
   

Добавление параметров в opensearch-keystore#

Внимание!

Выполнение данного пункта для компонента Поисковый движок (SRHX) требуется для обеспечения работы при недоступности Secret Management System. Обратите внимание, что Dashboards имеет свой собственный Keystore – opensearch-dashboards-keystore. Его настройка отличается и описана в пункте Добавление параметров в opensearch-dashboards-keystore.

Создайте keystore с помощью параметра create.

#создайте хранилище, если оно еще не существует
sudo su - opensearch -c '/usr/share/opensearch/bin/opensearch-keystore create'

Внимание!

opensearch-keystore будет создан для пользователя linux, от которого будут запускаться команды. Не выполняйте команды из под root! Используйте для этого пользователя opensearch.

Opensearch-keystore используется для сохранения сертификатов на случай недоступности Secret Management System и для сокрытия чувствительных данных (например логин/пароль) в компоненте Поисковый движок (SRHX). Хранение логина и пароля выполняется в opensearch.yml.

Список часто используемых параметров

Настройка параметров в opensearch_dashboards.yml#

Большинство настроек компонента SRHX описываются в файле /etc/opensearch-dashboards/opensearch_dashboards.yml и считываются при запуске компонента SRHX.

Внимание!

Должны быть подготовлены сертификаты для межкластерного шифрования и шифрования HTTP-уровня. Здесь используются те же сертификаты, которые были установлены ранее.

Замените все содержимое файла (удалите весь текст в существующем файле) /etc/opensearch-dashboards/opensearch_dashboards.yml текстом указанным в готовом образце opensearch_dashboards.yml, изменив значения на необходимые.

Готовый образец opensearch_dashboards.yml

### Шаблон безопасной конфигурации dashboards.
### Подставьте необходимые значения там, где требуется.
### Символы < > указывают значения, которые требуется заменить. При подстановке необходимых значений символы < > использовать не нужно.
 
 
# Настройки для самого dashboards
server.host: "<FQDN или IP текущего хоста>"
server.port: 15601
server.ssl.enabled: true 
server.ssl.keystore.path: /etc/opensearch-dashboards/secman/certs/http.p12
server.ssl.truststore.path: /etc/opensearch-dashboards/secman/certs/trust.p12 

# Настройки для соединения dashboards с сервером OpenSearch
opensearch.hosts:
    - https://<FQDN или IP node 1 в кластере>:ХХХХХ
    - https://<FQDN или IP node 2 в кластере>:ХХХХХ
    - https://<FQDN или IP node 3 в кластере>:ХХХХХ
 
opensearch.ssl.alwaysPresentCertificate: true
opensearch.ssl.verificationMode: full
opensearch.ssl.keystore.path: /etc/opensearch-dashboards/secman/certs/transport.p12
opensearch.ssl.truststore.path: /etc/opensearch-dashboards/secman/certs/trust.p12  

opensearch.requestHeadersAllowlist:
  - authorization
  - securitytenant
 
# Настройки логирования
logging.dest: /var/log/opensearch-dashboards/opensearch-dashboards.log
logging.json: false
logging.verbose: true
 
# Настройки плагина Security
opensearch_security.auth.type: "basicauth"
opensearch_security.cookie.secure: true
opensearch_security.session.keepalive: true
 
# Указанны значения в миллисекундах
opensearch_security.cookie.ttl: 86400000
opensearch_security.session.ttl: 1200000
 
i18n.locale: "ru"

secman.enabled: true

#Настройка метрик в Dashboards
prometheus.metrics.job_name: opensearch_dashboards
prometheus.metrics.path: _prometheus/metrics

Описание всех параметров указанных в примере opensearch_dashboards.yml представлено в таблице ниже.

Добавление параметров в opensearch-dashboards-keystore#

Для сокрытия чувствительных данных (например логин/пароль) в компоненте SRHX существует opensearch-dashboards-keystore.

Внимание!

Выполнение данного пункта для Dashboards требуется для обеспечения работы при недоступности Secret Management System.

Для работы с opensearch-dashboards-keystore запустите /usr/share/opensearch-dashboards/bin/opensearch-dashboards-keystore <параметр> (--help, чтобы увидеть все доступные параметры).

Список часто используемых параметров

Для продолжения установки добавьте в opensearch-dashboards-keystore логин и пароль для соединения с компонентом SRHX, так же пароли от сертификатов. Это будут параметры:

Создайте keystore с помощью параметра create. Добавьте необходимые параметры при помощи параметра add.

Внимание!

opensearch-dashboards-keystore будет создан для пользователя, который будет запускать команды. Не выполняйте команды из-под root! Используйте для этого пользователя opensearch-dashboards.

#Создайте хранилище, если оно еще не существует
sudo su - opensearch-dashboards -c '/usr/share/opensearch-dashboards/bin/opensearch-dashboards-keystore create'

#После команды будет ожидать ввода данных
sudo su - opensearch-dashboards -c '/usr/share/opensearch-dashboards/bin/opensearch-dashboards-keystore add opensearch.username'
#После команды будет ожидать ввода данных
sudo su - opensearch-dashboards -c '/usr/share/opensearch-dashboards/bin/opensearch-dashboards-keystore add opensearch.password'

На этом настройка сервера может быть завершена. Для первого запуска можно использовать ролевую модель по умолчанию с пользователями из internal_users.yml.

Настройка методов аутентификации/авторизации и ролевой модели#

В разделе приведена информация для ознакомления с возможностями ролевой модели компонента SRHX.

1. Ролевая модель настраивается в файлах internal_users.yml, roles.yml, roles_mapping.yml, которые находятся в /etc/opensearch/opensearch-security/.

2. Методы аутентификации настраиваются в файле config.yml, который находится в /etc/opensearch/opensearch-security/.

При старте компонента SRHX в первый раз подгружаются данные из этих файлов. Поэтому на сервере уже будут стандартные пользователи из этих файлов и метод аутентификации basicauth, который указан в config.yml. Редактирование файлов выполняется при необходимости.

Создание шифрованного пароля для пользователя#

Все пароли в internal_users.yml хранятся в зашифрованном виде. Для шифрования пароля есть скрипт hash.sh.

1. Запустите скрипт от пользователя opensearch.

    sudo su - opensearch -c '/usr/share/opensearch/plugins/opensearch-security/tools/hash.sh'
   

2. После загрузки скрипта он будет ожидать ввода пароля, который будет зашифрован. В примере используйте пароль der_parol.

   **************************************************************************
   ** This tool will be deprecated in the next major release of OpenSearch **
   **************************************************************************
   [Password:]
   

3. После ввода данных и нажатия Enter, получите введенный пароль в зашифрованном виде.

   $2y$12$MnTVuoi0Ue.Bbn47Np.xFuPjNcGGrazvgAZDkfSDMzSSd69Y3H6SW
   

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

1. В файл internal_users.yml добавьте блок нового пользователя:

   sudo nano /etc/opensearch/opensearch-security/internal_users.yml
   

2. Добавьте, подставив необходимые данные:

   pvs_admin:
   hash: "$2y$12$MnTVuoi0Ue.Bbn47Np.xFuPjNcGGrazvgAZDkfSDMzSSd69Y3H6SW"
   reserved: false
   description: "Demo pvs_admin user, using internal role mapping`
   

Создание роли#

1. Создайте роль с возможностями администрирования в файле roles.yml.

   sudo nano /etc/opensearch/opensearch-security/roles.yml
   

2. Добавьте:

    super_administrator:
       cluster_permissions:
       - 'cluster:admin/*'
       - 'cluster:monitor/*'
       index_permissions:
       - index_patterns:
       - '*'
       allowed_actions:
       - 'indices:admin/*'
       - 'indices:data/*'
       - 'indices:monitor/*
   

Связывание созданной роли и пользователя#

1. Присвойте роль созданному пользователю в файле roles_mapping.yml.

   sudo nano /etc/opensearch/opensearch-security/roles_mapping.yml
   

2. Добавьте:

   super_administrator:
   reserved: false
   users:
   - "pvs_admin"
   description: "Maximum access to everything"
   

Применение данных к кластеру#

Внимание!

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

После редактирования данных в файлах примените их к кластеру.

Запустите скрипт securityadmin.sh, который находится по пути /usr/share/opensearch/plugins/opensearch-security/tools/securityadmin.sh.

При запуске этого скрипта укажите дополнительные параметры.

Параметры для работы с хранилищем сертификатов p12 или jks. Нельзя использовать вместе с параметрами для обычных сертификатов.

Пример запуска скрипта от пользователя opensearch:

sudo su - opensearch -c '/usr/share/opensearch/plugins/opensearch-security/tools/securityadmin.sh \
-icl \
-nhnv \
-cd /etc/opensearch/opensearch-security/ \
-h "<адрес вашего хоста, где запущен компонент SRHX>" \
-p "ХХХХХ" \
-cacert "/etc/opensearch/certs/<имя вашего корневого сертификата>" \
-cert "/etc/opensearch/certs/<имя вашего сертификата администратора>" \
-key "/etc/opensearch/certs/<имя вашего приватного ключа для сертификата администратора>" \
-keypass "<пароль от приватного ключа для сертификата администратора>"'

Пример вывода успешного выполнения скрипта. В конце должна быть надпись Done with success

Security Admin v7
Will connect to <адрес вашего хоста, где запущен SRHX>:ХХХХХ ... done
Connected as "CN=<CN вашего админ-сертификата>,O=<имя вашего УЦ>"
OpenSearch Version: 1.5.0
Contacting opensearch cluster 'opensearch' and wait for YELLOW clusterstate ...
Clustername: <название вашего кластера>
Clusterstate: GREEN
Number of nodes: 3
Number of data nodes: 3
.opendistro_security index already exists, so we do not need to create one.
Populate config from /etc/opensearch/opensearch-security/
Will update '/config' with /etc/opensearch/opensearch-security/config.yml
   SUCC: Configuration for 'config' created or updated
Will update '/roles' with /etc/opensearch/opensearch-security/roles.yml
   SUCC: Configuration for 'roles' created or updated
Will update '/rolesmapping' with /etc/opensearch/opensearch-security/roles_mapping.yml
   SUCC: Configuration for 'rolesmapping' created or updated
Will update '/internalusers' with /etc/opensearch/opensearch-security/internal_users.yml
   SUCC: Configuration for 'internalusers' created or updated
Will update '/actiongroups' with /etc/opensearch/opensearch-security/action_groups.yml
   SUCC: Configuration for 'actiongroups' created or updated
Will update '/tenants' with /etc/opensearch/opensearch-security/tenants.yml
   SUCC: Configuration for 'tenants' created or updated
Will update '/nodesdn' with /etc/opensearch/opensearch-security/nodes_dn.yml
   SUCC: Configuration for 'nodesdn' created or updated
Will update '/whitelist' with /etc/opensearch/opensearch-security/whitelist.yml
   SUCC: Configuration for 'whitelist' created or updated
Will update '/audit' with /etc/opensearch/opensearch-security/audit.yml
   SUCC: Configuration for 'audit' created or updated
Will update '/allowlist' with /etc/opensearch/opensearch-security/allowlist.yml
   SUCC: Configuration for 'allowlist' created or updated
SUCC: Expected 10 config types for node {"updated_config_types":["allowlist","tenants","rolesmapping","nodesdn","audit","roles","whitelist","internalusers","actiongroups","config"],"updated_config_size":10,"message":null} is 10 (["allowlist","tenants","rolesmapping","nodesdn","audit","roles","whitelist","internalusers","actiongroups","config"]) due to: null
Done with success

Установка Data Prepper#

Сборка Docker образа#

В директории с Data Prepper расположены следующие файлы:

• data-prepper-jdk-2.8.0-linux-x64.tar.gz – архив с Data Prepper;

• папка config – pipeline.yaml конфигурации по настройке pipeline обработки данных и data-prepper-config.yaml конфигурационный файл настройки сервера;

• Dockerfile – файл с описанием образа.

В данной директории соберите Dockerfile.

Ниже представлено описание Dockerfile:

FROM '<path-to-image>'

ARG PIPELINE_FILEPATH=/usr/share/data-prepper/pipelines
ARG CONFIG_FILEPATH=/usr/share/data-prepper/config
ARG ARCHIVE_NAME=opensearch-data-prepper-jdk-2.8.0-SNAPSHOT-linux-x64
ARG ARCHIVE_FILE=$ARCHIVE_NAME.tar.gz
ARG ARCHIVE_FILE_UNPACKED=$ARCHIVE_NAME

ENV DATA_PREPPER_PATH /usr/share/data-prepper
ENV ENV_CONFIG_FILEPATH=$CONFIG_FILEPATH/data-prepper-config.yaml
ENV ENV_PIPELINE_FILEPATH=$PIPELINE_FILEPATH/pipelines.yaml

RUN mkdir -p /var/log/data-prepper
ADD $ARCHIVE_FILE /usr/share
RUN mv /usr/share/$ARCHIVE_FILE_UNPACKED /usr/share/data-prepper

COPY config/data-prepper-config.yaml $ENV_CONFIG_FILEPATH
COPY config/pipeline.yaml $ENV_PIPELINE_FILEPATH

WORKDIR $DATA_PREPPER_PATH
CMD ["bin/data-prepper"]

1. Соберите образ с помощью команды и укажите тэг с registry.

    docker build -t `<path-to-registry>`/data-prepper:latest .
   

2. Загрузите образ в nexus.

    docker push `<path-to-registry>`/data-prepper:latest
   

После выполнения данных команд будет создан готовый образ Data Prepper.

Пример

pipelines.yaml: |
    main-pipeline:
       source:
         kafka:
           encryption:
             type: none
           bootstrap_servers:
             - your-server-host
           topics:
             - name: dataprepper
               group_id: dataprepperGroup
       buffer:
         bounded_blocking:
           buffer_size: 1024
           batch_size: 256
       processor:
         - parse_json:
             source: message
         - grok:
             grok_when: '(/fields != null and /fields != "") and contains(/fields/app_name, "merchant_profile")'
             match:
               message: [ '\[%{TIMESTAMP_ISO8601:timestamp}\] \[%{LOGLEVEL:level}\s?\] [-] UnPrs \[%{GREEDYDATA:unparsedMerchantName}\] \[%{GREEDYDATA:city}\] \[%{GREEDYDATA:country}\] \[%{GREEDYDATA:merchantId}\] \[%{GREEDYDATA:mccCode}\] \[%{GREEDYDATA:isCategoryParsed}\]' ]
         - add_entries:
             entries:
               - key: "uniqueMerchantNameStat"
                 value_expression: /unparsedMerchantName
                 add_when: '/timestamp != null'
         - grok:
             grok_when: '/timestamp == null'
             match:
               message: [ '\[%{TIMESTAMP_ISO8601:timestamp}\] \[%{LOGLEVEL:level}\s?\] [-] Prs \[%{GREEDYDATA:parsedMerchantName}\] \[%{GREEDYDATA:city}\] \[%{GREEDYDATA:country}\] \[%{GREEDYDATA:merchantId}\] \[%{GREEDYDATA:mccCode}\] \[%{GREEDYDATA:brandName}\] \[%{GREEDYDATA:logoFilename}\] \[%{GREEDYDATA:address}\] \[%{GREEDYDATA:location}\] \[%{GREEDYDATA:feedbackAllowed}\] \[%{GREEDYDATA:isCategoryLogo}\] \[%{GREEDYDATA:isCategoryParsed}\] \[%{GREEDYDATA:isFullSearchMatched}\]' ]
         - add_entries:
             entries:
               - key: "uniqueMerchantNameStat"
                 value_expression: /parsedMerchantName
                 add_when: '/timestamp != null'
         - grok:
             grok_when: '/timestamp == null'
             match:
               message: [ '\[%{TIMESTAMP_ISO8601:timestamp}\] \[%{LOGLEVEL:level}\s?\] [-] Prs \[%{GREEDYDATA:parsedMerchantName}\] \[%{GREEDYDATA:city}\] \[%{GREEDYDATA:country}\] \[%{GREEDYDATA:merchantId}\] \[%{GREEDYDATA:mccCode}\] \[%{GREEDYDATA:brandName}\] \[%{GREEDYDATA:logoFilename}\] \[%{GREEDYDATA:isCategoryLogo}\] \[%{GREEDYDATA:isCategoryParsed}\]' ]
         - add_entries:
             entries:
               - key: "uniqueMerchantNameStat"
                 value_expression: /parsedMerchantName
                 add_when: '/timestamp != null'
               - key: "address"
                 value_expression: "false"
                 add_when: '/timestamp != null'
               - key: "location"
                 value: "false"
                 add_when: '/timestamp != null'
               - key: "isFullSearchMatched"
                 value: "false"
                 add_when: '/timestamp != null'
         - grok:
             grok_when: '/timestamp == null'
             match:
               message: [ '\[%{TIMESTAMP_ISO8601:timestamp}\] \[%{LOGLEVEL:level}\s?\] [-] PrsDup \[%{GREEDYDATA:duplicateMerchantName}\] \[%{GREEDYDATA:city}\] \[%{GREEDYDATA:country}\] \[%{GREEDYDATA:merchantId}\] \[%{GREEDYDATA:mccCode}\] \[%{GREEDYDATA:brandName}\] \[%{GREEDYDATA:logoFilename}\] \[%{GREEDYDATA:isCategoryLogo}\] \[%{GREEDYDATA:isCategoryParsed}\]' ]
         - add_entries:
             entries:
               - key: "parsedMerchantName"
                 value_expression: /duplicateMerchantName
                 add_when: '/timestamp != null'
               - key: "address"
                 value: "false"
                 add_when: '/timestamp != null'
               - key: "location"
                 value: "false"
                 add_when: '/timestamp != null'
         - grok:
             grok_when: '/timestamp == null'
             match:
               message: [ '\[%{TIMESTAMP_ISO8601:timestamp}\] \[%{LOGLEVEL:level}\s?\] [-] PrsDupIn \[%{GREEDYDATA:parsedMerchantName}\] \[%{GREEDYDATA:city}\] \[%{GREEDYDATA:country}\] \[%{GREEDYDATA:merchantId}\] \[%{GREEDYDATA:mccCode}\] \[%{GREEDYDATA:brandName}\] \[%{GREEDYDATA:logoFilename}\] \[%{GREEDYDATA:isCategoryLogo}\] \[%{GREEDYDATA:isCategoryParsed}\]' ]
         - add_entries:
             entries:
               - key: "address"
                 value: "false"
                 add_when: '/timestamp != null'
               - key: "location"
                 value: "false"
                 add_when: '/timestamp != null'     
               - key: "isFullSearchMatched"
                 value: "false"
                 add_when: '/timestamp != null'         
       route:
         - alpha: '/fields/app_name != null and /fields/app_name != ""'
         - beta: '/level != null and /level == "INFO"'
       sink:
         - opensearch:
             routes:
               - alpha
             connection:
               insecure: true
             hosts: [ "your-opensearch-host-1" ]
             index: "logs-${/fields/app_name}-datastream"
             username: "{{ search_username }}"
             password: "{{ search_password }}"
         - opensearch:
             routes:
               - beta
             connection:
               insecure: true
             hosts: [ "your-opensearch-host-2" ]
             index: fallback
             username: "{{ search_username }}"
             password: "{{ search_password }}"
         - stdout:

Deploy приложения в DropApp#

1. Для deploy приложения понадобится создать 4 манифеста:

   • Config map для описания конфигурации приложения (data-prepper-config);

   • Service для приложения (data-prepper-server);

   • Service для метрик приложения (data-prepper-metrics);

   • Deployment для описания deploy приложения (data-prepper).

Создайте директорию k8s с помощью команды (выбор пути для создания директории опционален):

 mkdir -p /usr/share/k8s 

Перейдите в данную директорию:

 cd /usr/share/k8s

Создайте в ней файлы, представленные ниже.

Примеры манифестов:

В Config map можно переопределить pipeline.yaml и data-prepper-config.yaml. Config map монтируется в volume в разделе deployment.

• Config map для описания конфигурации приложения (cm-data-prepper.yml):

     apiVersion: v1
     kind: ConfigMap
     metadata:
     labels:
         app: data-prepper
     name: data-prepper-config
     data:
     pipelines.yaml: |
         simple-sample-pipeline:
         workers: 2 # the number of workers
         delay: 5000 # in milliseconds, how long workers wait between read attempts
         source:
             random:
         buffer:
             bounded_blocking:
             buffer_size: 1024 # max number of records the buffer accepts
             batch_size: 256 # max number of records the buffer drains after each read
         processor:
             - string_converter:
                 upper_case: true
         sink:
             - stdout:
     data-prepper-config.yaml: |
         ssl: false

- Service для приложения (svc-data-prepper-server.yml):

     apiVersion: v1
     kind: Service
     metadata:
     labels:
         app: data-prepper
     name: data-prepper-server
     spec:
     clusterIP: None
     ports:
         - name: "21890"
         port: 21890
         targetPort: 21890
     selector:
         app: data-prepper

- Service для метрик (svc-data-prepper-metrics.yml):

     apiVersion: v1
     kind: Service
     metadata:
     labels:
         app: data-prepper
     name: data-prepper-metrics
     spec:
     type: NodePort
     ports:
         - name: "4900"
         port: 4900
         targetPort: 4900
     selector:
         app: data-prepper

- Deployment для приложения (dc-data-prepper.yml)

     apiVersion: apps/v1
     kind: Deployment
     metadata:
     labels:
         app: data-prepper
     name: data-prepper
     spec:
     replicas: 1
     selector:
         matchLabels:
         app: data-prepper
     strategy:
         type: Recreate
     template:
         metadata:
         labels:
             app: data-prepper
         spec:
         containers:
             - args:
                 - bin/data-prepper
                 - /etc/data-prepper/pipelines.yaml
                 - /etc/data-prepper/data-prepper-config.yaml 
             image: `<path-to-registry>`/data-prepper:latest 
             name: data-prepper
             ports:
                 - containerPort: 2021
             resources: {}
             volumeMounts:
                 - mountPath: /etc/data-prepper
                 name: prepper-configmap-claim0
         imagePullSecrets:
             - name: nexuscred
         restartPolicy: Always
         serviceAccountName: ""
         volumes:
             - name: prepper-configmap-claim0
             configMap:
                 name: data-prepper-config

2. В директории k8s с манифестами примените команду:

    kubectl apply -f .
   

3. Проверьте корректность deploy.

В namespace в разделе workloads появится pod с data-prepper, в логах контейнера будут указаны сгенерированные сообщения.

Безопасная конфигурация Data Prepper в корпоративной среде#

Чтобы настроить mTLS между DataPrepper и внешними компонентами (далее в качестве примера будут рассмотрены Search и Kafka) выполните следующие действия:

1. В первую очередь на кластере Kubernetes установите Synapse Service Mesh или Istio.

2. Далее включите его в namespace, где размещен DataPrepper:

   apiVersion: v1
   kind: Namespace
   metadata:
     name: data-prepper
     labels:
       pod-security.kubernetes.io/enforce: restricted
       istio-injection: enabled
       istio.io/rev: istio-system
   

3. Создайте секрет для подключения к Kafka, где будут находиться клиентская пара сертификат-ключ и сертификат УЦ:

   kind: Secret
   apiVersion: v1
   metadata:
     name: kafka-secret
     namespace: data-prepper
   data:
     root.crt: <сертификат удостоверяющего центра в base64>
     tls.crt: <сертификат клиента в base64>
     tls.key: <ключ клиента в base64>
   type: Opaque
   

4. Создайте секрет для подключения к Search:

   kind: Secret
   apiVersion: v1
   metadata:
     name: pvs-secret
     namespace: data-prepper
   data:
     root.crt: <сертификат удостоверяющего центра в base64>
     tls.crt: <сертификат клиента в base64>
     tls.key: <ключ клиента в base64>
   type: Opaque
   

5. Cоздайте экземпляр istio-egressgateway в том же пространстве имен:

   kind: Deployment
   apiVersion: apps/v1
   metadata:
     name: istio-egressgateway
     namespace: data-prepper
     labels:
       app: istio-egressgateway
       istio: egressgateway
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: istio-egressgateway
         istio: egressgateway
     template:
       metadata:
         labels:
           app: istio-egressgateway
           istio: egressgateway
         annotations:
           istio.io/rev: istio-system
           sidecar.istio.io/inject: 'false'
       spec:
         restartPolicy: Always
         schedulerName: default-scheduler
         securityContext:
           runAsNonRoot: true
           runAsUser: 1002120000
           runAsGroup: 1002120000
           fsGroup: 1002120000
           seccompProfile:
             type: RuntimeDefault
         serviceAccountName: default
         terminationGracePeriodSeconds: 60
         containers:
           - resources:
               limits:
                 cpu: '2'
                 memory: 1Gi
               requests:
                 cpu: 100m
                 memory: 128Mi
             readinessProbe:
               httpGet:
                 path: /healthz/ready
                 port: 15021
                 scheme: HTTP
               initialDelaySeconds: 1
               timeoutSeconds: 1
               periodSeconds: 2
               successThreshold: 1
               failureThreshold: 30
             terminationMessagePath: /dev/termination-log
             name: istio-proxy
             env:
               - name: PROXY_CONFIG
                 value: >
                   {"discoveryAddress":"istiod-istio-system.istio-system.svc:15012","drainDuration":"61s","terminationDrainDuration":"59s"}
               - name: JWT_POLICY
                 value: third-party-jwt
               - name: PILOT_CERT_PROVIDER
                 value: istiod
               - name: CA_ADDR
                 value: 'istiod-istio-system.istio-system.svc:15012'
               - name: NODE_NAME
                 valueFrom:
                   fieldRef:
                     apiVersion: v1
                     fieldPath: spec.nodeName
               - name: POD_NAME
                 valueFrom:
                   fieldRef:
                     apiVersion: v1
                     fieldPath: metadata.name
               - name: POD_NAMESPACE
                 valueFrom:
                   fieldRef:
                     apiVersion: v1
                     fieldPath: metadata.namespace
               - name: INSTANCE_IP
                 valueFrom:
                   fieldRef:
                     apiVersion: v1
                     fieldPath: status.podIP
               - name: HOST_IP
                 valueFrom:
                   fieldRef:
                     apiVersion: v1
                     fieldPath: status.hostIP
               - name: ISTIO_CPU_LIMIT
                 valueFrom:
                   resourceFieldRef:
                     resource: limits.cpu
                     divisor: '0'
               - name: SERVICE_ACCOUNT
                 valueFrom:
                   fieldRef:
                     apiVersion: v1
                     fieldPath: spec.serviceAccountName
               - name: ISTIO_META_WORKLOAD_NAME
                 value: istio-egressgateway
               - name: ISTIO_META_OWNER
                 value: >-
                   kubernetes://apis/apps/v1/namespaces/data-prepper/deployments/istio-egressgateway
               - name: ISTIO_META_MESH_ID
                 value: cluster.local
               - name: TRUST_DOMAIN
                 value: cluster.local
               - name: ISTIO_META_UNPRIVILEGED_POD
                 value: 'true'
               - name: ISTIO_META_CLUSTER_ID
                 value: Kubernetes
               - name: ISTIO_META_NODE_NAME
                 valueFrom:
                   fieldRef:
                     apiVersion: v1
                     fieldPath: spec.nodeName
             securityContext:
               capabilities:
                 drop:
                   - ALL
               privileged: false
               readOnlyRootFilesystem: true
               runAsNonRoot: true
               runAsUser: 1002120000
               runAsGroup: 1002120000
               fsGroup: 1002120000
               allowPrivilegeEscalation: false
               seccompProfile:
                 type: RuntimeDefault
             ports:
               - containerPort: 15021
                 protocol: TCP
               - containerPort: 8080
                 protocol: TCP
               - containerPort: 8443
                 protocol: TCP
               - name: http-envoy-prom
                 containerPort: 15090
                 protocol: TCP
             imagePullPolicy: Always
             volumeMounts:
               - name: kafka-secret
                 mountPath: /etc/istio/kafka-secret
                 readOnly: true
               - name: pvs-secret
                 mountPath: /etc/istio/pvs-secret
                 readOnly: true
               - name: workload-socket
                 mountPath: /var/run/secrets/workload-spiffe-uds
               - name: credential-socket
                 mountPath: /var/run/secrets/credential-uds
               - name: workload-certs
                 mountPath: /var/run/secrets/workload-spiffe-credentials
               - name: istio-envoy
                 mountPath: /etc/istio/proxy
               - name: config-volume
                 mountPath: /etc/istio/config
               - name: istiod-ca-cert
                 mountPath: /var/run/secrets/istio
               - name: istio-token
                 readOnly: true
                 mountPath: /var/run/secrets/tokens
               - name: istio-data
                 mountPath: /var/lib/istio/data
               - name: podinfo
                 mountPath: /etc/istio/pod
               - name: egressgateway-certs
                 readOnly: true
                 mountPath: /etc/istio/egressgateway-certs
               - name: egressgateway-ca-certs
                 readOnly: true
                 mountPath: /etc/istio/egressgateway-ca-certs
             terminationMessagePolicy: File
             image: istio/proxyv2:1.20.2
             args:
               - proxy
               - router
               - '--domain'
               - $(POD_NAMESPACE).svc.cluster.local
               - '--proxyLogLevel=info'
               - '--proxyComponentLogLevel=misc:error'
               - '--log_output_level=default:info'
         volumes:
           - name: kafka-secret
             secret:
               secretName: kafka-secret
           - name: pvs-secret
             secret:
               secretName: pvs-secret
           - name: workload-socket
             emptyDir: {}
           - name: credential-socket
             emptyDir: {}
           - name: workload-certs
             emptyDir: {}
           - name: istiod-ca-cert
             configMap:
               name: istio-ca-root-cert
               defaultMode: 256
           - name: podinfo
             downwardAPI:
               items:
                 - path: labels
                   fieldRef:
                     apiVersion: v1
                     fieldPath: metadata.labels
                 - path: annotations
                   fieldRef:
                     apiVersion: v1
                     fieldPath: metadata.annotations
               defaultMode: 256
           - name: istio-envoy
             emptyDir: {}
           - name: istio-data
             emptyDir: {}
           - name: istio-token
             projected:
               sources:
                 - serviceAccountToken:
                     audience: istio-ca
                     expirationSeconds: 3600
                     path: istio-token
               defaultMode: 256
           - name: config-volume
             configMap:
               name: istio-istio-system
               defaultMode: 256
               optional: true
           - name: egressgateway-certs
             secret:
               secretName: istio-egressgateway-certs
               defaultMode: 256
               optional: true
           - name: egressgateway-ca-certs
             secret:
               secretName: istio-egressgateway-ca-certs
               defaultMode: 256
               optional: true
         dnsPolicy: ClusterFirst
     strategy:
       type: RollingUpdate
       rollingUpdate:
         maxUnavailable: 25%
         maxSurge: 100%
     revisionHistoryLimit: 10
     progressDeadlineSeconds: 600
   ---
   kind: Service
   apiVersion: v1
   metadata:
     name: istio-egressgateway
     namespace: data-prepper
     labels:
       app: istio-egressgateway
       istio: egressgateway
   spec:
     ports:
       - name: http2
         protocol: TCP
         port: 80
         targetPort: 8080
       - name: https
         protocol: TCP
         port: 443
         targetPort: 8443
       - name: pvs
         protocol: TCP
         port: 19200
         targetPort: 19200
       - name: kafka
         protocol: TCP
         port: 9093
         targetPort: 9093
     internalTrafficPolicy: Cluster
     selector:
       app: istio-egressgateway
   

6. Для создания доступа к кластеру Kafka из 3 узлов через Istio для начала создайте объект шлюза - Gateway:

   apiVersion: networking.istio.io/v1beta1
   kind: Gateway
   metadata:
     name: istio-egressgateway-kafka
     namespace: data-prepper
   spec:
     selector:
       istio: egressgateway
     servers:
       - hosts:
           - <FQDN узла #1>
           - <FQDN узла #2>
           - <FQDN узла #3>
         port:
           name: kafka
           number: 9093
           protocol: tcp
   

   Для каждого узла кластера Kafka, указанного в Gateway, по примеру ниже создайте VirtualService, ServiceEntry и DestinationRule:

   ---
   apiVersion: networking.istio.io/v1beta1
   kind: VirtualService
   metadata:
     name: vs-external-kafka-1
     namespace: data-prepper
   spec:
     gateways:
       - mesh
       - istio-egressgateway-kafka
     hosts:
       - <FQDN узла #1>
     tcp:
       - match:
           - gateways:
               - mesh
             port: 9093
         route:
           - destination:
               host: istio-egressgateway.data-prepper.svc.cluster.local
               port:
                 number: 9093
       - match:
           - gateways:
               - istio-egressgateway-kafka
             port: 9093
         route:
           - destination:
               host: <FQDN узла #1>
               port:
                 number: 9093
             weight: 100
     exportTo:
       - "."
   ---
   apiVersion: networking.istio.io/v1beta1
   kind: ServiceEntry
   metadata:
     name: se-external-kafka-1
     namespace: data-prepper
   spec:
     addresses:
       - <IP-адрес узла #1>
     exportTo:
       - .
     hosts:
       - <FQDN узла #1>
     location: MESH_EXTERNAL
     ports:
       - name: tcp
         number: 9093
         protocol: TLS
   ---
   apiVersion: networking.istio.io/v1beta1
   kind: DestinationRule
   metadata:
     name: dsr-external-kafka-1
     namespace: data-prepper
   spec:
     host: <FQDN узла #1>
     trafficPolicy:
       portLevelSettings:
         - port:
             number: 9093
           tls:
             mode: MUTUAL
             caCertificates: /etc/istio/kafka-secret/root.crt
             clientCertificate: /etc/istio/kafka-secret/tls.crt
             privateKey: /etc/istio/kafka-secret/tls.key
     exportTo:
       - "."
   

7. Схожим образом настройте Istio для Search — 1 Gateway и по одному VirtualService, ServiceEntry и DestinationRule для каждого узла, но уже с сертификатами для Search:

   apiVersion: networking.istio.io/v1beta1
   kind: Gateway
   metadata:
     name: istio-egressgateway-pvs
     namespace: data-prepper
   spec:
     selector:
       istio: egressgateway
     servers:
       - hosts:
           - <FQDN узла #1>
           - <FQDN узла #2>
           - <FQDN узла #3>
         port:
           name: pvs-http
           number: 19200
           protocol: http
   apiVersion: networking.istio.io/v1beta1
   kind: VirtualService
   metadata:
     name: vs-external-pvs-1
     namespace: data-prepper
   spec:
     hosts:
       - <FQDN узла #1>
     gateways:
       - mesh
       - istio-egressgateway-pvs
     http:
       - match:
           - gateways:
               - mesh
             port: 19200
         route:
           - destination:
               host: istio-egressgateway.data-prepper.svc.cluster.local
               port:
                 number: 19200
       - match:
           - gateways:
               - istio-egressgateway-pvs
             port: 19200
         route:
           - destination:
               host: <FQDN узла #1>
               port:
                 number: 19200
             weight: 100
     exportTo:
       - "."
   ---
   apiVersion: networking.istio.io/v1beta1
   kind: ServiceEntry
   metadata:
     name: se-external-pvs-1
     namespace: data-prepper
   spec:
     hosts:
       - <FQDN узла #1>
     addresses:
       - <IP-адрес узла #1>
     endpoints:
       - address: <IP-адрес узла #1>
     ports:
       - name: pvs-http
         number: 19200
         protocol: HTTP
     resolution: DNS
     location: MESH_EXTERNAL
     exportTo:
       - "."
   ---
   apiVersion: networking.istio.io/v1beta1
   kind: DestinationRule
   metadata:
     name: dsr-external-pvs-1
     namespace: data-prepper
   spec:
     host: <FQDN узла #1>
     trafficPolicy:
       portLevelSettings:
         - port:
             number: 19200
           tls:
             mode: MUTUAL
             caCertificates: /etc/istio/pvs-secret/root.crt
             clientCertificate: /etc/istio/pvs-secret/tls.crt
             privateKey: /etc/istio/pvs-secret/tls.key
     workloadSelector:
       matchLabels:
         app: istio-egressgateway
         istio: egressgateway
     exportTo:
       - "."
   

Настройка аудита компонента SRHX#

При старте сервиса компонент Поисковый движок (SRHX) проверяет наличие в директории /etc/opensearch/audit/ файла с настройками аудита audit.yml и при наличии файла применяет его настройки на кластер. Из других директорий применение данного файла невозможно.

Важно

Применение настроек аудита кластера возможно только через файл audit.yml, изменение настроек через файл opensearch.yml, REST-запросы или с помощью скрипта securityadmin.sh заблокировано.

Если файл не найден, то применяются настройки по умолчанию, соответствующие файлу audit.yml ниже

_meta:
  type: "audit"
  config_version: 2
config:
  # enable/disable audit logging
  enabled: true
  audit:
    # Enable/disable REST API auditing
    enable_rest: true
    # Categories to exclude from REST API auditing
    disabled_rest_categories:
    # Enable/disable Transport API auditing
    enable_transport: true
    # Categories to exclude from Transport API auditing
    disabled_transport_categories:
    # Users to be excluded from auditing. Wildcard patterns are supported. Eg:
    # ignore_users: ["test-user1", "test-user2"]
    ignore_users:
    # Requests to be excluded from auditing. Wildcard patterns are supported. Eg:
    # ignore_requests: ["indices:data/read/*", "SearchRequest"]
    ignore_requests: []
    # Log individual operations in a bulk request
    resolve_bulk_requests: true
    # Include the body of the request (if available) for both REST and the transport layer
    log_request_body: true
    # Logs all indices affected by a request. Resolves aliases and wildcards/date patterns
    resolve_indices: true
    # Exclude sensitive headers from being included in the logs. Eg: Authorization
    exclude_sensitive_headers: true
  compliance:
    # enable/disable compliance
    enabled: true
    # Log updates to internal security changes
    internal_config: true
    # Log external config files for the node
    external_config: true
    # Log only metadata of the document for read events
    read_metadata_only: false
    # Map of indexes and fields to monitor for read events. Wildcard patterns are supported for both index names and fields. Eg:
    # read_watched_fields: {
    #   "twitter": ["message"]
    #   "logs-*": ["id", "attr*"]
    # }
    read_watched_fields: {"*": ["*"]}
    # List of users to ignore for read events. Wildcard patterns are supported. Eg:
    # read_ignore_users: ["test-user", "employee-*"]
    read_ignore_users:
    # Log only metadata of the document for write events
    write_metadata_only: false
    # Log only diffs for document updates
    write_log_diffs: true
    # List of indices to watch for write events. Wildcard patterns are supported
    # write_watched_indices: ["twitter", "logs-*"]
    write_watched_indices: ["*"]
    # List of users to ignore for write events. Wildcard patterns are supported. Eg:
    # write_ignore_users: ["test-user", "employee-*"]
    write_ignore_users:

Описание всех параметров указанных в примере audit.yml:

Настройка интеграции#

Настройка интеграции с Secret Management System#

Для включения интеграции с Secret Management System:

1. Создайте группу Active Directory экземпляра компонента Поисковый движок (SRHX) в Secret Management System.

2. Активируйте KV-engine и PKI-engine.

3. Разместите в KV-engine корневой сертификат.

4. Выпустите PKI-engine роль с привилегиями:

• Allow IP Subject Alternative Names;

• Use CSR Subject Alternative Names;

• Enforce hostnames;

• Require Common Name;

• Use CSR Common Name;

• Allow localhost;

• Allow bare domains;

• Allow subdomains;

• Server flag;

• Client flag.

5. Получите доступ к методу аутентификации Approle.

6. Получите из Secret Management System параметры role_id и secret_id при помощи API. secret_id и role_id являются данными для доступа к созданным engine в Secret Management System.

7. Параметр secret_id отправьте по методу wrap Secret Management System с ключом secret_id для получения wrapped-токен. Wrapped-токен – это одноразовый токен (wrapped-token) в виде файла, который необходим для получения secret_id. secret_id и role_id являются данными для доступа к созданному хранилищу в Secret Management System.

8. Разместите wrapped-токен на файловой системе компонента Поисковый движок (SRHX) в каталоге /etc/opensearch/secman.

9. Заполните в файле opensearch.yml параметры:

• plugins.security.secman.enabled значением true;

• Параметры plugins.security.ssl.*

10. Заполните файл secman.yml. Большинство настроек интеграции с Secret Management System описываются в файле /etc/opensearch/secman.yml и считываются при запуске программы. Ниже пример готового файла.

# Блок параметров для авторизации в Secman
# Адрес сервера SecMan-а
plugins.security.secman.address: https://secman.host:secman.port
# Пространство имён SecMan-а (HashiCorp enterprise feature)
plugins.security.secman.namespace: YOUR_NAME_FOR_NAMESPACE
# Значение идентификатора Approle, настроенной в App Role authentication backend
plugins.security.secman.role_id: 11111111-1111-1111-1111-111111

# Блок параметров для wrapped-token
# Имя файла с wrapped-token-ом
plugins.security.secman.wrapped_token.path: /etc/opensearch/secman/approle_wrapped_secret_id

# Блок параметров для KV (Получение траст-сертификатов)
# Тип сертификатов, получаемых из KV
plugins.security.secman.kv.cert.type: pem
# Версия KV движка
plugins.security.secman.kv.engine_version: 1
# Путь до KV движка
plugins.security.secman.kv.mount.path: NAMESPACE/KV/MOUNT/PATH/KV
# Наименование папки в KV, где находится ключ(параметр), в котором лежит цепочка трастовых сертификатов
plugins.security.secman.kv.dir.path: dir_in_your_kv
# Название ключа, в котором находится цепочка трастовых сертификатов в папке "plugins.security.secman.kv.dir.path"
plugins.security.secman.kv.truststore_key: key_name_in_your_kv_dir_for_trust_cert

# Блок параметров для PKI (Генерация сертификатов для PVS)
# Тип сертификатов, получаемых из PKI
plugins.security.secman.pki.cert.type: pem
# Путь до PKI-движка
plugins.security.secman.pki.fetch.mount.path: path_to_PKI_engine
# SberCA-роль для выпуска клиент-серверных сертификатов с проверкой CN по DNS
plugins.security.secman.pki.fetch.role: PKI-client-server-DNS-role-name

# Блок по сертификатам
# Common name для транспортных сертификатов
plugins.security.secman.transport.cn: vm-fqdn
# Common name для сертификата
plugins.security.secman.http.cn: vm-fqdn

# Блок по сертификатам для audit-а
# Common name для сертификата
plugins.security.secman.audit.cn: cn_for_audit_certs
# SberCA-роль для выпуска клиентских сертификатов
plugins.security.secman.audit.pki.role: PKI-client-role-name
# Путь, где будут сохранены клиентские-сертификаты для аудита на диске
plugins.security.ssl.audit.keystore_filepath: /etc/opensearch/secman/certs/audit.jks
# Путь где будут сохранены траст-сертификаты для аудита на диске
plugins.security.ssl.audit.kv.truststore_path: /etc/opensearch/secman/certs/audittrust.jks

Описание всех возможных параметров файла secman.yml

Настройка сертификата для шифрования внутрикластерного взаимодействия

Настройки сертификата для шифрования внешнего взаимодействия с кластером

Настройка сертификата для взаимодействия с провайдером аудита

Важно

Параметры ниже заполняются только в случае, если настроена интеграция с внешним провайдером аудита согласно пункту Настройка интеграции с внешним провайдером аудита. Если интеграция не настроена, то удалите параметры ниже из файла secman.yml.

Интеграция сервиса Dashboards компонента Поисковый движок (SRHX) с Secret Management System#

Для включения интеграции с Secret Management System:

1. Разместите в KV-engine корневой сертификат для Dashboards (если ранее загружали корневые сертификаты для Server, то можно не загружать новые, а использовать корневые сертификаты Server).

2. Для PKI-engine используйте ранее выпущенную роль для компонента Поисковый движок (SRHX).

3. Параметр secret_id отправьте по методу wrap Secret Management System с ключом secret_id для получения wrapped-токен.

4. Разместите wrapped-токен на файловой системе сервиса Dashboards компонента Поисковый движок (SRHX) в каталоге /etc/opensearch-dashboards/secman.

5. Заполните в файле opensearch-dashboards.yml параметры:

• secman.enabled значением true;

• параметры server.ssl.* и opensearch.ssl.*.

6. Заполните файл secman_dashboards.yml. Большинство настроек интеграции с Secret Management System описываются в файле /etc/opensearch-dashboards/secman_dashboards.yml и считываются при запуске программы. Ниже пример готового файла.

# Блок параметров для авторизации в Secman
# Адрес сервера SecMan-а
secman.address: https://secman.host:secman.port
# Пространство имён SecMan-а (HashiCorp enterprise feature)
secman.namespace: YOUR_NAME_FOR_NAMESPACE
# Значение идентификатора Approle, настроенной в App Role authentication backend
secman.role_id: 11111111-1111-1111-1111-111111

# Блок параметров для wrapped-token
# Имя файла с wrapped-token-ом
secman.wrapped_token.path: /etc/opensearch-dashboards/secman/approle_wrapped_secret_id

# Блок параметров для KV (Получение траст-сертификатов)
# Тип сертификатов, получаемых из KV
secman.kv.cert.type: pem
# Версия KV движка
secman.kv.engine_version: 1
# Путь до KV движка
secman.kv.mount.path: NAMESPACE/KV/MOUNT/PATH/KV
# Папка в KV
secman.kv.dir.path: dir_in_your_kv
# Ключ в KV
secman.kv.truststore_key: key_name_in_your_kv_dir_for_trust_cert

# Блок параметров для PKI (Генерация сертификатов для PVS)
# Тип сертификатов, получаемых из PKI
secman.pki.cert.type: pem
# Путь до PKI-движка
secman.pki.fetch.mount.path: path_to_PKI_engine
# PKI-роль для выпуска сертификата
secman.pki.fetch.role: PKI-client-server-DNS-role-name

# Блок по сертификатам для взаимодействия Dashboards с кластером PVS
# Common name для сертификата
secman.dashboard.opensearch.cn: hostname_fqdn

# Блок по сертификатам для взаимодействия Dashboards с клиентом
# Common name для сертификата
secman.dashboard.server.cn: hostname_fqdn

Описание всех возможных параметров файла secman_dashboards.yml