Сценарии администрирования#

Для выполнения сценариев администрирования системному администратору должна быть выдана роль admin.

Для получения роли:

  1. В среде контейнеризации последовательно перейдите по вкладкам User Management -> RoleBinding и нажмите Create binding.

  2. На открывшейся странице заполните обязательные поля:

  • name — наименование связи между пользователем и ролью, например: xxx-admin;

  • namespace — наименование namespace, к которому применяются права;

  • role — имя роли, например: admin;

  • subject name — логин администратора.

и нажмите Create.

Публикация health-метрик Batch Tasks для Prometheus#

Работоспособность сервиса Пакетная обработка задач (Batch Tasks) может быть определена с помощью health-метрик на графиках системы мониторинга.

Для этого сервис Batch Tasks выполняет публикацию дополнительной readiness-метрики batch_availability_readiness в формате Prometheus, которая отображает общую готовность сервиса обрабатывать запросы. Метрика Prometheus в actuator/prometheus синхронизирована с health-метрикой /actuator/health/readiness и отражает следующие состояния:

  • "UP" = 1.0 — если все смежные сервисы работают корректно.

  • "DOWN" = 0.0 — в других случаях.

Контроль доступа к сервису в Batch UI#

Администратору сервиса необходимо иметь тенант с возможностями просмотра, создания, редактирования и удаления Заданий. Настройка доступа тенанта приведена в Руководстве по системному администрированию разделе «Контроль доступа к сервису» в документации на компонент Batch UI (BATU).

Ролевая модель#

При работе с сервисом Batch Tasks рекомендуется в компоненте One-Time Password (OTP) / OTT (далее — OTT) применять следующую ролевую модель:

Роль

Функции

Создание/удаление Очереди

Создание/удаление Задачи

Просмотр метрик

Администратор ТС

Мониторинг работы сервиса

—

—

+

Администратор пользователя

Мониторинг работы пользователя

+

+

—

Пользователь

Работа с сущностями сервиса

+

+

—

Рекомендации по заданию стойких паролей#

Пароль считается стойким, если он удовлетворяет следующим условиям:

  • длина пароля составляет не менее 12 символов;

  • в качестве пароля не используется имя учетной записи;

  • пароль состоит из цифр, строчных и прописных букв;

  • в пароле используется минимум 6 разных символов;

  • пароль не применяется в открытых сервисах.

Рекомендуется изменять пароль раз в 30—90 дней в зависимости от среды. Это станет гарантией того, что злоумышленники не смогут взломать пароль подбором. Убедитесь, что в новом пароле не повторяется более трех символов старого пароля подряд.

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

Конфигурирование подключения сервиса к СУБД#

Чтобы выполнить конфигурирование подключения сервиса Batch Tasks к БД, например, настроить подключение к другому экземпляру БД, выполните следующие действия:

  1. Сконфигурируйте настройки подключения Batch Tasks к БД:

    • измените значение параметра jdbc-url (URL соединения с БД) на нужное;

    • в случае, если подключение к новой БД осуществляется под новым пользователем, внесите правки в значения параметров database.main.password и database.main.username;

    • разместите секреты с новыми username, password в системе оркестрации контейнерами согласно инструкции, приведенной в Руководстве по установке в разделе «Настройка окружения»;

    • проверьте актуальность настроек для новой СУБД в batch-tasks.all.conf:

# JDBC_URL соединения с основной БД (например: "jdbc:postgresql://tkled-pprb00045.vm.esrt.cloud.xxxx.ru:5432/dbschd_dev")
MAIN_DB_JDBC_URL=<!- заполните самостоятельно ->

# Текущая схема подключения к основной БД (например: "tasks_schema")
MAIN_DB_CURRENT_SCHEMA=<!- заполните самостоятельно ->

# Прикладной пользователь основной БД (например: "tasks_appl_user")
MAIN_DB_USER=<!- заполните самостоятельно ->

# Флаг поддержки SSL/TLS-соединения на основной БД (true/false). Если при подключении к новой БД используется SLL (true), то проверьте нижеследующие параметры (TLS_CERT_PATH, TLS_KEY_PATH, TLS_ROOT_CERT_PATH, TLS_FACTORY); если SLL при подключении к новой БД не используется (false), то эти параметры не применяются.
MAIN_DB_SSL_ON=<!- заполните самостоятельно: true/false ->

# Путь до volumeMounts публичного клиентского сертификата. Пути не меняются при изменении БД, поэтому менять значения не требуется.
MAIN_DB_TLS_CERT_PATH=/app/certs/db/tasks_appl_user.crt

# Путь до volumeMounts закрытого клиентского ключа. Пути не меняются при изменении БД, поэтому менять значения не требуется.
MAIN_DB_TLS_KEY_PATH=/app/certs/db/tasks_appl_user.pk8

# Путь до volumeMounts публичного родительского (CA) сертификата. Пути не меняются при изменении БД, поэтому менять значения не требуется.
MAIN_DB_TLS_ROOT_CERT_PATH=/app/certs/db/root.crt

# Фабрика для построения JDBC-соединения. Пути не меняются при изменении БД, поэтому менять значения не требуется.
MAIN_DB_TLS_FACTORY=org.postgresql.ssl.jdbc4.LibPQFactory

Для использования кластера БД Patroni в файле batch-tasks.istio.all.conf необходимо сконфигурировать следующие параметры:

### Конфигурирование параметров Stand-In БД
MAIN_DB_HOST_M=<Обязательно к заполнению>
MAIN_DB_IP_M=<Обязательно к заполнению>
MAIN_DB_PORT_M=5432

### Мастер БД в кластере Main
MAIN_DB_EGRESS_IN_PORT_M=12001
MAIN_DB_EGRESS_OUT_PORT_M=2001

### Конфигурирование параметров Stand-In БД
### Мастер БД в кластере SI - заполнить при необходимости
SI_DB_HOST_M=<Обязательно к заполнению>
SI_DB_IP_M=<Обязательно к заполнению>
SI_DB_PORT_M=5432

### Мастер БД в кластере SI
SI_DB_EGRESS_IN_PORT_M=12003
SI_DB_EGRESS_OUT_PORT_M=2003

# Флаг включения дополнительных параметров и конфигурационных файлов для возможности использования кластера Patroni
PATRONI_ENABLED=false

  1. Если используется репликационная БД, повторите вышеуказанные действия для конфигурирования параметров подключения к репликационной базе данных (Stand-In DB).

# Host основной БД. Введите параметры для новой БД, например:
MAIN_DB_HOST=tkled-pprb00045.vm.esrt.cloud.xxxx.ru
MAIN_DB_IP=10.xx.xxx.xx
MAIN_DB_PORT=5432

# Host SI БД. Введите параметры для новой SI БД, например:
SI_DB_HOST=tkled-pprb00062.vm.esrt.cloud.xxxx.ru
SI_DB_IP=10.xx.xxx.xx
SI_DB_PORT=5432

Реализация Graceful Shutdown и конфигурирование Rolling Update сервиса Batch Tasks#

Graceful shutdown#

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

Общий принцип завершения работы Pod#

  1. Pod переводится в статус Terminating и исключается из списка endpoints для сервиса. Начинается отсчет тайм-аута (grace period).

  2. Выполняется команда preStop Hook. Конфигурирование команды preStop Hook в yaml-файле позволяет выполнить одно из двух действий: команду или запрос.

  3. После завершения команды preStop Hook приложению посылается сигнал SIGTERM.

  4. Начинается отсчет тайм-аута (grace period), за время которого приложение завершается. Конфигурируется в yaml-файле.

  5. Если за время тайм-аута приложение еще не завершилось, посылается сигнал SIGKILL, приложение принудительно завершает работу, Pod удаляется.

Особенности tasks-worker#

Микросервис tasks-worker выполняет вызовы httpTarget с помощью Apache Async Http Client по мере появления новых Задач. При этом вызовы синхронизируются через БД (таблица билетов).

В команде preStop Hook выполняются несколько действий:

  1. В начале команды preStop Hook останавливается цикл отбора новых Задач из БД.

  2. Выполняется ожидание в течение времени, необходимого для завершения уже запущенной итерации отбора новых задач из БД. Конфигурируется в файле tasks-worker.conf в placeholder TASKS_WORKER_PRESTOP_SLEEP_DURATION_SECONDS.

  3. Выполняется ожидание завершения запущенных вызовов httpTarget, не дольше заданного времени. Если вызовы завершаются раньше, ожидание также прекращается раньше. Конфигурируется в файле tasks-worker.conf в placeholder TASKS_WORKER_HTTP_CLIENT_GRACE_PERIOD_SECONDS.

  4. Завершается выполнение команды preStop Hook, сервис получает SIGTERM и завершается. Длительность выключения компонентов сервиса конфигурируется в файле tasks-worker.conf в placeholder TASKS_WORKER_TIMEOUT_PER_SHUTDOWN_PHASE. При этом сумма трех вышеперечисленных периодов времени не должна превысить общее время выключения Pod, которое конфигурируется в файле tasks-worker.conf в placeholder TASKS_WORKER_TERMINATION_GRACE_PERIOD_SECONDS.

Схема работы

Конфигурирование параметров Graceful Shutdown#

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

  • tasks-server.conf:

### Конфигурирование параметров Graceful Shutdown для TASKS_SERVER

#### Сумма остальных интервалов для TASKS_SERVER. Размерность: целое число секунд
TASKS_SERVER_TERMINATION_GRACE_PERIOD_SECONDS=30
#### Необходимое время ожидания для завершения уже запущенной итерации отбора новых задач из БД. Размерность: целое число секунд
TASKS_SERVER_PRESTOP_SLEEP_DURATION_SECONDS=10
#### Время на Graceful Shutdown для Tomcat, который обрабатывает входящие запросы. Значение параметра задается в формате Duration, например: "PT20S"; если задать просто число, то в качестве размерности будут использованы миллисекунды
TASKS_SERVER_TIMEOUT_PER_SHUTDOWN_PHASE=PT20S

  • tasks-worker.conf:

### Конфигурирование параметров Graceful Shutdown для TASKS_WORKER

#### Сумма остальных интервалов для TASKS_WORKER. Размерность: целое число секунд
TASKS_WORKER_TERMINATION_GRACE_PERIOD_SECONDS=45
#### Необходимое время ожидания для завершения уже запущенной итерации отбора новых задач из БД. Размерность: целое число секунд
TASKS_WORKER_PRESTOP_SLEEP_DURATION_SECONDS=5
#### Время ожидания завершения запущенных вызовов httpTarget. Если вызовы завершаются раньше, ожидание также прекращается раньше. Размерность: целое число секунд
TASKS_WORKER_HTTP_CLIENT_GRACE_PERIOD_SECONDS=20
#### Время на Graceful Shutdown для Tomcat, который обрабатывает входящие запросы. Значение параметра задается в формате Duration, например: "PT60S"; если задать просто число, то в качестве размерности будут использованы миллисекунды
TASKS_WORKER_TIMEOUT_PER_SHUTDOWN_PHASE=PT20S

  • tasks-gc.conf:

### Конфигурирование параметров Graceful Shutdown для TASKS_GC

#### Сумма остальных интервалов для TASKS_GC. Размерность: целое число секунд
TASKS_GC_TERMINATION_GRACE_PERIOD_SECONDS=30
#### Необходимое время ожидания для завершения уже запущенной итерации отбора новых задач из БД. Размерность: целое число секунд
TASKS_GC_PRESTOP_SLEEP_DURATION_SECONDS=10
#### Время на Graceful Shutdown для Tomcat, который обрабатывает входящие запросы. Значение параметра задается в формате Duration, например: "PT60S"; если задать просто число, то в качестве размерности будут использованы миллисекунды
TASKS_GC_TIMEOUT_PER_SHUTDOWN_PHASE=PT20S

  • tasks-journal-applier.conf:

### Конфигурирование параметров Graceful Shutdown для TASKS_JOURNAL_APPLIER

#### Сумма остальных интервалов для TASKS_JOURNAL_APPLIER. Размерность: целое число секунд
TASKS_JA_TERMINATION_GRACE_PERIOD_SECONDS=30
#### Необходимое время ожидания для завершения уже запущенной итерации отбора новых задач из БД. Размерность: целое число секунд
TASKS_JA_PRESTOP_SLEEP_DURATION_SECONDS=10
#### Время на Graceful Shutdown для Tomcat, который обрабатывает входящие запросы. Значение параметра задается в формате Duration, например: "PT60S"; если задать просто число, то в качестве размерности будут использованы миллисекунды
TASKS_JA_TIMEOUT_PER_SHUTDOWN_PHASE=PT20S

Rolling Update#

Сервис Batch Tasks поддерживает Rolling Update — стратегию обновления без прерывания работы сервиса с постепенным отключением экземпляров старой версии и вводом экземпляров новой версии.

В системе оркестрации контейнерами предусмотрена стратегия обновления Rolling Update, которая реализует эту логику.

Чтобы просмотреть настройки стратегии обновления, в консоли системы оркестрации контейнерами выполните следующие действия:

  1. Перейдите Workloads → Deployment (Deployment Configs).

  2. В списке выберите необходимую конфигурацию tasks-worker/tasks-server/tasks-journal-applier.

  3. В конфигурации перейдите на вкладку YAML и поиском найдите spec.strategy.type.

Параметр конфигурируется в файле batch-tasks.k8s.all.conf.

При обновлении приложения стратегией Rolling создается новый Replication Controller. При этом количество Pod в старом Replication Controller постепенно сокращается, а в новом — увеличивается до тех пор, пока в старом не достигнет нуля, а в новом — значения, заданного параметром replicas (в OpenShift конфигурация tasks-server параметр spec.replicas).

Чтобы просмотреть настройки количества реплик, в консоли системы оркестрации контейнерами выполните следующие действия:

  1. В меню Workloads выберите раздел Deployment (Deployment Configs).

  2. В списке выберите необходимую конфигурацию tasks-server/tasks-worker/tasks-gc/tasks-journal-applier.

  3. В конфигурации перейдите на вкладку YAML.

  4. Поиском найдите параметр spec.replicas.

Параметр конфигурируется в файле tasks-server.conf с placeholder TASKS_SERVER_REPLICAS_COUNT.

Параметр конфигурируется в файле tasks-worker.conf с placeholder TASKS_WORKER_REPLICAS_COUNT.

Параметр конфигурируется в файле tasks-journal-applier.conf с placeholder TASKS_JA_APPLIER_REPLICAS_COUNT.

Для gc не конфигурируется, т.к. для корректной работы Pod необходим только один экземпляр.

Доступные стратегии развертывания#

Существует две стратегии развертывания, которые могут комбинироваться:

  1. Поочередное завершение работы старых Pods и запуск на их месте новых Pods:

    • плюсы: способ не требует дополнительных ресурсов,

    • минусы: во время обновления количество работающих Pods будет меньше, чем количество реплик.

  2. Поочередный запуск новых Pods, а после их успешного запуска (получение успешной liveness/readiness probes) — завершение старых pods:

    • плюсы: доступность сервиса не уменьшается,

    • минусы: требует дополнительных ресурсов.

При комбинировании способов ожидаемые:

  • недостатки:

    • временное уменьшение количества работающих экземпляров сервиса,

    • временное использование дополнительных ресурсов.

  • преимущества:

    • более быстрое обновление.

Выбор стратегии остается за администраторами системы оркестрации контейнерами.

Конфигурирование параметров Rolling Update#

Пример заполненного файла tasks-server.conf:

## Конфигурирование параметров Rolling Update

### Дополнительная информация
#### Примеры к параметрам *_UPDATE_MAX_UNAVAILABLE: 1) При replicas=3 и maxUnavailable=1 во время обновления количество работающих Pods не будет опускаться ниже 2 и работа сервиса не будет прерываться. 2) При replicas=2 и maxUnavailable=2 стратегия Rolling сводится к стратегии Recreate — останавливаются оба Pods, вместо них запускаются два новых. Непрерывная работа сервиса в этом случае не обеспечивается
#### Внимание! Значения параметров *_MAX_UNAVAILABLE и *_MAX_SURGE не могут одновременно быть равны нулю

### Конфигурирование параметров Rolling Update для TASKS_SERVER
#### Время в секундах на полное обновление. При превышении выполняется откат к предыдущей версии
TASKS_SERVER_ROLLING_UPDATE_TIMEOUT_SECONDS=600
#### Насколько можно сократить количество работающих Pods относительно соответствующего параметра *_REPLICAS_COUNT
TASKS_SERVER_ROLLING_UPDATE_MAX_UNAVAILABLE=1
#### Насколько общее число Pods (число: работающие + запускающиеся + завершающиеся) может превысить соответствующий параметр *_REPLICAS_COUNT
TASKS_SERVER_ROLLING_UPDATE_MAX_SURGE=0

Пример заполненного файла tasks-worker.conf:

### Конфигурирование параметров Rolling Update для TASKS_WORKER
#### Время в секундах на полное обновление. При превышении выполняется откат к предыдущей версии
TASKS_WORKER_ROLLING_UPDATE_TIMEOUT_SECONDS=600
#### Насколько можно сократить количество работающих Pods относительно соответствующего параметра *_REPLICAS_COUNT
TASKS_WORKER_ROLLING_UPDATE_MAX_UNAVAILABLE=1
#### Насколько общее число Pods (число: работающие + запускающиеся + завершающиеся) может превысить соответствующий параметр *_REPLICAS_COUNT
TASKS_WORKER_ROLLING_UPDATE_MAX_SURGE=0

Пример заполненного файла tasks-gc.conf:

### Конфигурирование параметров Rolling Update для TASKS_GC
#### Время в секундах на полное обновление. При превышении выполняется откат к предыдущей версии
TASKS_GC_ROLLING_UPDATE_TIMEOUT_SECONDS=600
#### Насколько можно сократить количество работающих Pods относительно соответствующего параметра *_REPLICAS_COUNT
TASKS_GC_ROLLING_UPDATE_MAX_UNAVAILABLE=1
#### Насколько общее число Pods (число: работающие + запускающиеся + завершающиеся) может превысить соответствующий параметр *_REPLICAS_COUNT
TASKS_GC_ROLLING_UPDATE_MAX_SURGE=0

Пример заполненного файла tasks-journal-applier.conf:

### Конфигурирование параметров Rolling Update для TASKS_JOURNAL_APPLIER
#### Время в секундах на полное обновление. При превышении выполняется откат к предыдущей версии
TASKS_JA_ROLLING_UPDATE_TIMEOUT_SECONDS=600
#### Насколько можно сократить количество работающих Pods относительно соответствующего параметра *_REPLICAS_COUNT
TASKS_JA_ROLLING_UPDATE_MAX_UNAVAILABLE=1
#### Насколько общее число Pods (число: работающие + запускающиеся + завершающиеся) может превысить соответствующий параметр *_REPLICAS_COUNT
TASKS_JA_ROLLING_UPDATE_MAX_SURGE=0

Администрирование внешних средств защиты информации осуществляется в соответствии с их документацией.

Настройка геобалансировщика#

Для настройки геобалансировки с health-check установите параметры согласно таблице.

Параметр

Описание

CN_CERT_GEOBALANCER=geobalancer_cn

Значения клиентского сертификата геобалансировщика (CN)

INGRESS_HEALTH_URL=health-istio-ingressgateway-${NAMESPACE}.apps.${OPENSHIFT_CLUSTER}

Host роутера Ingress на health-endpoint

INGRESS_HEALTH_PORT=5444

Входной порт Ingress для приема HTTPS-трафика на health-endpoint

INGRESS_HTTPS_HEALTH_GW_NAME=batch-ingress-health-gw

Наименование Ingress Gateway для HTTPS-трафика на health-endpoint

Просмотр метрик мониторинга#

Для просмотра метрик мониторинга с использованием компонента Объединенный мониторинг Unimon:

  1. В среде контейнеризации перейдите на вкладку PODs и выберите pod, например, tasks-server.

  2. Перейдите в терминал и введите команду:

curl localhost:8081/actuator/prometheus

  1. В полученном сообщении отобразятся отбрасываемые метрики с событиями мониторинга (также приведены в разделе «События мониторинга»).

  2. Перейдите в систему отображения метрик (например, Prometheus), указав необходимую метрику. Например, system_cpu_usage.

Просмотр событий системного журнала#

Для просмотра событий системного журнала с использованием компонента Журналирование:

  1. Перейдите в UI Журналирование.

  2. Перейдите на вкладку Системный журнал.

  3. На открывшейся странице заполните поля: Начальная дата, Начальное время, Конечная дата, Конечное время.

  4. Нажмите кнопку Поиск.

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

Контроль сертификатов#

Подробная инструкция по получению сертификатов приведена в Руководстве по установке в разделе «Настройка окружения».

Сертификаты хранятся в зашифрованном виде на сервере, где будет развернут компонент, и необходимы для всех TLS/mTLS-соединений. Сервис Batch Tasks не предусматривает дополнительных средств защиты сертификатов. Также сертификаты могут храниться в зашифрованном виде в SecMan (при наличии интеграции).

Подробная информация о необходимых сертификатах приведена в разделе «Настройки параметров безопасности».

При развертывании дистрибутива работа с секретными данными происходит на следующих этапах:

  1. Передача секретных данных в систему оркестрации контейнерами.

  2. Использование секретных данных при выполнении шагов развертывания (например, для добавления скриптов с использованием библиотеки Liquibase).

В первом случае необходимо передать в систему оркестрации контейнерами секрет, во втором — просто хранить секретные данные, которые будут использоваться при работе Jenkins Job. В обоих случаях также имеется возможность получить секреты из SecMan.

Сервис Batch Tasks может использовать сторонние сертификаты:

  • Istio (Ingress, Egress) при использовании Istio для сетевой безопасности;

  • сертификаты клиентский и серверный для подключения к БД по SSL при необходимости;

  • сертификат для ОТТ при необходимости.

Рекомендации по работе с сертификатами:

  1. Сертификат должен быть подписан только удостоверяющим центром (CA). Необходимо удостовериться в отсутствии самоподписных сертификатов.

  2. Сертификат должен «принадлежать» сервису Batch Tasks (нельзя использовать один и тот же сертификат для функционирования разных сервисов в рамках одной инсталляции Platform V).

  3. Сертификат должен быть действительным на текущую дату. Необходима проверка срока действия сертификата.

  4. Сертификат не должен быть отозван соответствующим удостоверяющим центром (CA). Необходима проверка списков исключения сертификатов.

  5. Должны быть подключены механизмы аутентификации, авторизации и валидации по сертификатам (при интеграции сервиса с компонентами Platform V, реализующими данный функционал, например OTT).

  6. Приватный/доверенный ключ не должен распространяться по каналам связи и должен иметь стойкий пароль.

Управление сертификатами для mTLS взаимодействий внутри проекта осуществляется механизмами системы оркестрации контейнерами.

Для хранения ключевой информации в системе оркестрации контейнерами должны использоваться только защищенные артефакты Secret.

Сертификаты для тестовых и промышленных сред должны быть выданы удостоверяющим центром.

Для сред разработки разрешено использование самоподписанных сертификатов.

Инструкция по получению сертификатов приведена в Руководстве по установке в разделе «Настройка окружения».

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

Безопасная загрузка настроек сервиса Batch Tasks#

В сервисе Batch Tasks первоначальный запуск контейнера и загрузка всех настроек, необходимых для запуска компонента, происходят при старте контейнера из ConfigMap, Secrets, внешнего хранилища конфигураций, интегрированного в среду исполнения. Монтирование секретов происходит в папку вместо монтирования в переменные окружения. Также секреты могут быть получены из сервиса SecMan.

Приложению для запуска и работы нужны конфигурационные файлы, в которых прописаны настройки и сертификаты. Сертификаты хранятся в Secrets и монтируются на файловую систему при старте контейнера, откуда их читает приложение. Конфигурационные файлы хранятся в ConfigMaps и также монтируются на файловую систему контейнера.

ConfigMap и Secret подключаются к файловой системе контейнера в режиме .spec.containers[].volumeMounts[].readOnly: true.

В конфигурационных файлах вместо настроек, которые нельзя хранить в ConfigMaps в открытом виде (например, логины и пароли), оставлены placeholders. Пароли хранятся в Secrets и монтируются при запуске контейнера в отдельную папку. Приложение при запуске читает конфигурационный файл и секреты и подставляет вместо placeholders соответствующие значения из Secrets.

Настройки ConfigMap в виде переменных окружения не передаются.

Обязательный секрет#

В каталоге /install/secrets дистрибутива представлены шаблоны секретов для инсталляции.

Для подстановки значений из Secrets вместо placeholders необходимо наличие секрета в namespace системы оркестрации контейнерами Kubernetes или OpenShift с именем batch-tasks-app-secret, содержащего набор полей с необходимыми именами:

kind: Secret
apiVersion: v1
metadata:
  name: batch-tasks-app-secret
data:
  access.secret-key: <!- SPAS secret key ->
  database.main.password: <!- main database password ->
  database.main.username: <!- main database username ->
  database.stand-in.password: <!- stand-in database password ->
  database.stand-in.username: <!- stand-in database username ->
  journal.ssl.key.password: <!- journal ssl key password ->
  journal.ssl.keystore.password: <!- journal ssl keystore password ->
  journal.ssl.truststore.password: <!- journal ssl truststore password ->
type: Opaque

«Безопасная» загрузка#

Секрет монтируется в определенную папку внутри контейнера (/app/secrets), для каждого поля в секрете создается файл с определенным именем, содержимое файла — значение поля в секрете. Имена файлов в этой папке совпадают с именами placeholders в конфигурационном файле. Вспомогательный класс EnvironmentPostProcessor читает файлы из этой папки и вместо каждого placeholders подставляет значение из соответствующего файла. Таким образом: пароли хранятся в секретах, а не в открытом виде, они не объявляются как переменные окружения, а загружаются из файлов напрямую.

Рекомендации к проверке подлинности сертификатов#

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

keytool -v -list -keystore <FileName>.jks | awk '/Owner:|Issuer:|Valid from/'

Вывод содержит следующую информацию:

  • Owner: информация о CN сертификата.

  • Issuer: УЦ банка.

  • Valid from: срок действия сертификата.

Порядок действий в случае компрометации криптографических ключей#

Криптоключи, в отношении которых возникло подозрение в компрометации, а также действующие совместно с ними другие криптоключи, рекомендуется немедленно вывести из действия и перевыпустить, если иной порядок не оговорен во внутренних документах Заказчика.

Конфигурирование валидатора URL#

Для включения валидатора UrlValidator для проверки HttpTarget.url в Configmap микросервиса tasks-server установите значение параметра enabled=true.

  static:
    task:
      url:
        validation:
          enabled: {{URL_VALIDATOR_ENABLED}} # Флаг включения валидации Httptarget.url: true - включена; false - выключена
          domains: {{URL_DOMAINS}}

При включенном UrlValidator существует возможность расширения списка доменов первого уровня, чтобы валидатор их успешно обрабатывал и не генерировал исключение InvalidFormat url.

Для расширения доменов первого уровня (валидатор обрабатывает и не генерирует исключение InvalidFormat url) перечислите через запятую домены в параметре domains.

Включение/отключение health-check для сервиса Аудит#

Для включения/отключения работы health-check в файле task-server.conf установите нужное значение флага true/false. При значении параметра false проверка доступности сервиса Аудит не проверяется. В этом случае при недоступности сервиса Аудит, события могут не попадать в Аудит (readiness probe Аудита в actuator/health нет). При значении параметра true и недоступном сервисе Аудит, трафик не принимается и не отправляется до тех пор, пока Аудит не станет доступным (в Batch Tasks значение readiness probe false).

# Проверка доступности Аудит (Readiness): true — включена, false — выключена
TASKS_SERVER_AUDIT_HEALTH_CHECK=true

По умолчанию health check включен, для отключения перед установкой сервиса в репозитории конфигураций необходимо установить значение параметра false.