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

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

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

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

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

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

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

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

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

и нажмите Create.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# JDBC_URL соединения с основной БД
MAIN_DB_JDBC_URL=<!- заполните самостоятельно ->

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

# Прикладной пользователь основной БД (например: "scheduler_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/scheduler_appl_user.crt
# Путь до volumeMounts закрытого клиентского ключа. Пути не меняются при изменении БД, поэтому менять значения не требуется.
MAIN_DB_TLS_KEY_PATH=/app/certs/db/scheduler_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-scheduler.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 БД.

# Host основной БД. Ввести параметры для новой БД, например:
MAIN_DB_HOST=xxx.xxx.xxx
MAIN_DB_IP=10.xx.xxx.xx
MAIN_DB_PORT=5432
   
# Параметры внешнего взаимодействия основной БД
MAIN_DB_EGRESS_IN_PORT=12001
MAIN_DB_EGRESS_OUT_PORT=2001 
   
# host SI БД. Ввести параметры для новой SI БД, например:
SI_DB_HOST=xxx.xxx.xxx
SI_DB_IP=10.xx.xxx.xx
SI_DB_PORT=5432
      
# Параметры внешнего взаимодействия Stand-In БД
SI_DB_EGRESS_IN_PORT=12003
SI_DB_EGRESS_OUT_PORT=2003

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

Graceful shutdown#

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

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

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

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

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

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

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

Особенности scheduler-dispatcher#

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

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

  1. Планировщик заданий останавливается, обновляется список запланированных к запуску задач.

  2. В начале команды preStop Hook выполняется остановка всех запланированных вызовов.

  3. Выполняется ожидание в течение времени, необходимого для обработки запросов, которые могут приходить, пока Pod не удален из списка endpoint. Конфигурируется в файле scheduler-dispatcher в placeholder SCHD_DISPATCHER_PRESTOP_SLEEP_DURATION_SECONDS.

  4. Выполняется ожидание завершения запущенных вызовов HttpTarget до истечения заданного времени. Если вызовы завершаются раньше, то и ожидание прекращается раньше. Конфигурируется в scheduler-dispatcher в placeholder SCHD_DISPATCHER``_HTTP_CLIENT_GRACE_PERIOD_SECONDS.

  5. Завершается выполнение команды preStop Hook, сервис получает SIGTERM и завершается (вместе с scheduler-dispatcher). Длительность выключения компонентов сервиса конфигурируется в scheduler-dispatcher в SCHD_DISPATCHER_TIMEOUT_PER_SHUTDOWN_PHASE. При этом сумма вышеперечисленных периодов времени не должна превысить общее время выключения Pod, которое конфигурируется в scheduler-dispatcher в SCHD_DISPATCHER_TERMINATION_GRACE_PERIOD_SECONDS.

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

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

  • scheduler-dispatcher.conf:

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

#### Сумма остальных интервалов для SCHD_DISPATCHER. Размерность: целое число секунд
SCHD_DISPATCHER_TERMINATION_GRACE_PERIOD_SECONDS=50
#### Необходимое время ожидания для обработки запросов, которые могут приходить, пока Pod не удален из списка endpoint. Размерность: целое число секунд
SCHD_DISPATCHER_PRESTOP_SLEEP_DURATION_SECONDS=10
#### Время ожидания завершения запущенных вызовов HttpTarget. Если вызовы завершаются раньше, ожидание также прекращается раньше. Размерность: целое число секунд
SCHD_DISPATCHER_HTTP_CLIENT_GRACE_PERIOD_SECONDS=20
#### Время на graceful shutdown для Tomcat, который обрабатывает входящие запросы. Значение параметра задается в формате Duration, например: «PT60S»; если задать просто число, то в качестве размерности будут использованы миллисекунды
SCHD_DISPATCHER_TIMEOUT_PER_SHUTDOWN_PHASE=PT20S

  • scheduler-server.conf:

### Конфигурирование параметров Graceful Shutdown для SCHD_SERVER
#### Сумма остальных интервалов для SCHD_SERVER. Размерность: целое число секунд
SCHD_SERVER_TERMINATION_GRACE_PERIOD_SECONDS=30
#### Необходимое время ожидания для обработки запросов, которые могут приходить, пока Pod не удален из списка endpoint. Размерность: целое число секунд
SCHD_SERVER_PRESTOP_SLEEP_DURATION_SECONDS=10
#### Время на graceful shutdown для Tomcat, который обрабатывает входящие запросы. Значение параметра задается в формате Duration, например: «PT60S»; если задать просто число, то в качестве размерности будут использованы миллисекунды
SCHD_SERVER_TIMEOUT_PER_SHUTDOWN_PHASE=PT20S

  • scheduler-journal-applier.conf:

### Конфигурирование параметров Graceful Shutdown для SCHD_JA
#### Сумма остальных интервалов для SCHD_JA. Размерность: целое число секунд
SCHD_JA_TERMINATION_GRACE_PERIOD_SECONDS=30
#### Необходимое время ожидания для обработки запросов, которые могут приходить, пока Pod не удален из списка endpoint. Размерность: целое число секунд
SCHD_JA_PRESTOP_SLEEP_DURATION_SECONDS=10
#### Время на graceful shutdown для Tomcat, который обрабатывает входящие запросы. Значение параметра задается в формате Duration, например: «PT60S»; если задать просто число, то в качестве размерности будут использованы миллисекунды
SCHD_JA_TIMEOUT_PER_SHUTDOWN_PHASE=PT20S

  • scheduler-gc.conf:

### Конфигурирование параметров Graceful Shutdown для SCHD_GC
#### Сумма остальных интервалов для SCHD_GC. Размерность: целое число секунд
SCHD_GC_TERMINATION_GRACE_PERIOD_SECONDS=30
#### Необходимое время ожидания для обработки запросов, которые могут приходить, пока Pod не удален из списка endpoint. Размерность: целое число секунд
SCHD_GC_PRESTOP_SLEEP_DURATION_SECONDS=10
#### Время на graceful shutdown для Tomcat, который обрабатывает входящие запросы. Значение параметра задается в формате Duration, например: «PT60S»; если задать просто число, то в качестве размерности будут использованы миллисекунды
SCHD_GC_TIMEOUT_PER_SHUTDOWN_PHASE=PT20S

Rolling Update#

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

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

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

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

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

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

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

Для просмотра настройки количества реплик в системе оркестрации контейнерами необходимо:

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

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

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

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

Параметр конфигурируется в файле scheduler-dispatcher.conf с placeholder SCHD_DISPATCHER_REPLICAS_COUNT.

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

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

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

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

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

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

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

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

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

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

При комбинировании способов:

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

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

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

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

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

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

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

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

#### Примеры к параметрам *_UPDATE_MAX_UNAVAILABLE: 1) При replicas=3 и maxUnavailable=1 во время обновления количество работающих Pods не будет опускаться ниже 2 и работа сервиса не будет прерываться; 2) При replicas=2 и maxUnavailable=2 стратегия Rolling сводится к стратегии Recreate - останавливаются оба Pods, вместо них запускаются два новых. Непрерывная работа сервиса в этом случае не обеспечивается.
#### Внимание! Значения параметров *_MAX_UNAVAILABLE и *_MAX_SURGE не могут одновременно быть равны нулю.
 
### Конфигурирование параметров Rolling Update для SCHD_DISPATCHER
#### Время в секундах на полное обновление. При превышении выполняется откат к предыдущей версии
SCHD_DISPATCHER_ROLLING_UPDATE_TIMEOUT_SECONDS=600
#### Насколько можно сократить количество работающих Pods относительно соответствующего параметра *_REPLICAS_COUNT
SCHD_DISPATCHER_ROLLING_UPDATE_MAX_UNAVAILABLE=1
#### Насколько общее число Pods (число: работающие + запускающиеся + завершающиеся) может превысить соответствующий параметр *_REPLICAS_COUNT
SCHD_DISPATCHER_ROLLING_UPDATE_MAX_SURGE=0

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

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

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

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

  • scheduler-gc.conf:

### Конфигурирование параметров Rolling Update для SCHD_GC
#### Время в секундах на полное обновление. При превышении выполняется откат к предыдущей версии
SCHD_GC_ROLLING_UPDATE_TIMEOUT_SECONDS=600
#### Насколько можно сократить количество работающих Pods относительно соответствующего параметра *_REPLICAS_COUNT
SCHD_GC_ROLLING_UPDATE_MAX_UNAVAILABLE=1
#### Насколько общее число Pods (число: работающие + запускающиеся + завершающиеся) может превысить соответствующий параметр *_REPLICAS_COUNT
SCHD_GC_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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для хранения ключевой информации в системе оркестрации контейнерами должны использоваться только защищенные артефакты Secret или монтирование в файловую систему pod с помощью sidecar vault-agent, который получает ключевую информацию из сервиса Secret Management System.

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

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

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

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

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

В сервисе Batch Scheduler первоначальный запуск контейнера и загрузка всех настроек, необходимых для запуска компонента, происходят при старте контейнера из 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-scheduler-app-secret, с набором полей с необходимыми именами:

kind: Secret
apiVersion: v1
metadata:
  name: batch-scheduler-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 микросервиса scheduler-server установите значение параметра enabled=true.

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

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

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

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

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

Пример:

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

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