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

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

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

Работоспособность сервиса Batch UI может быть определена с помощью health-метрик на графиках системы мониторинга.

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

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

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

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

Контроль доступа к сервису с использованием сервиса СПАС#

В сервисе Batch UI авторизация и работа пользователей реализована через ролевую модель с разграничением доступа на основе атрибутов справочника ABAC (Attribute — Based Access Control).

Структура атрибутов#

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

Ролевая модель позволяет разграничивать пользовательские права на 3 категории:

• просмотр (Get);

• редактирование (Edit);

• удаление (Delete).

Ролевая модель Batch UI содержит defaultBatchRole — общая роль для доступа к операциям в UI. Например:

<role code="defaultBatchRole" description="Роль доступа к формам Batch" name="batch-master_defaultBatchRole">

Для подключения ролевой модели необходимо загрузить файл defaultBatchRole.xml в СПАС. Пример заполнения приведен в файле defaultBatchRole.xml.

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

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

Пример ролевой модели для разграничения прав#

В приведенной таблице столбцы представляют собой справочники атрибутов, строки — различные тенанты, которые хранятся во всех справочниках.

Например, наличие у пользователя атрибута с именем tenant-2 из справочника Edit разрешает пользователю редактирование данных tenant-2. Отсутствие атрибута tenant-4 из справочника Get запрещает пользователю доступ на чтение к tenant-4.

Подробное описание разграничения доступа приведено в документации на СПАС.

Конфигурирование поставки политики авторизации#

Политика авторизации должна быть размещена на узлах СПАС в определенной папке, которая задается с помощью настройки СПАС policyBasePath. В дистрибутиве политика хранится в папке /other/abac.

Управление контролем доступа к сервису#

Назначение, удаление и просмотр атрибутов пользователя#

Просмотр и/или изменение пользовательских прав (добавление/удаление атрибутов) выполняются администратором сервиса следующим образом:

1. Перейдите в UI СПАС.

2. Просмотрите атрибуты пользователя:

   1. Перейдите на страницу Пользователи.

   2. Выберите пользователя.

   3. Нажмите кнопку Атрибуты пользователя.

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

3. Чтобы добавить атрибут:

   1. Перейдите на страницу Пользователи.

   2. Выберите пользователя.

   3. Нажмите кнопку Атрибуты пользователя.

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

   5. Нажмите кнопку >>.

   6. В открывшемся окне нажмите кнопку Да, чтобы подтвердить назначение атрибута пользователю.

   В результате успешного добавления атрибута пользователю отобразится информационное окно. Нажмите кнопку ОК.

4. Чтобы удалить атрибут:

   1. Перейдите на страницу Пользователи.

   2. Выберите пользователя.

   3. Нажмите кнопку Атрибуты пользователя.

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

   5. Нажмите кнопку <<.

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

   В результате успешного удаления атрибута пользователя отобразится информационное окно. Нажмите кнопку ОК.

Подключение ABAC и загрузка справочника атрибутов#

Подключение модуля ABAC и загрузка справочника атрибутов выполняются администратором следующим образом:

1. Перейдите в UI СПАС.

2. Создайте модуль:

   1. Перейдите на страницу Модули → Подключить модуль.

   2. Введите название модуля.

3. Назначьте администратору (например, текущему пользователю, под которым сейчас выполнен вход) роль "Администратор модуля ${moduleId}":

   1. Перейдите на страницу Пользователи.

   2. Выберите пользователя.

   3. Нажмите кнопку Роли.

   4. Нажмите кнопку Добавить.

   5. Выберите роль из списка.

   6. Нажмите кнопку >>.

   7. Нажмите кнопку Добавить.

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

4. Подключите созданный модуль к ABAC:

   1. Перейдите на страницу Модули.

   2. Выберите модуль.

   3. Нажмите кнопку Подключить модуль к ABAC.

5. Загрузите справочник атрибутов:

   1. Перейдите на страницу Справочники ABAC.

   2. Выберите модуль.

   3. Нажмите кнопку Загрузить из файла.

   4. Выберите файл.

   5. Нажмите кнопку Загрузить, чтобы загрузить выбранный справочник атрибутов.

Подключение к сервисам Batch Tasks и Batch Scheduler выполняется отдельно.

Пример шаблона справочника для добавления нового тенанта для Batch Tasks#

В шаблоне справочника атрибутов для микросервиса task-server требуется заменить placeholder ${tenantId} на имя нового tenant и загрузить полученный файл в СПАС. Пример файла template.atrib.task.json.

Пример шаблона справочника для добавления нового тенанта для Batch Scheduler#

В шаблоне справочника атрибутов для микросервиса scheduler-server требуется заменить placeholder ${tenantId} на имя нового тенанта и загрузить полученный файл наименование файла в СПАС. Пример файла template.atrib.schd.json.

Добавление нового тенанта#

Под словом тенант понимаются хост и порт, которые могут вызываться Задачами. Если из Задач могут вызываться несколько разных пар «хост+порт», то добавьте их все в соответствии с описанием ниже. Добавление нового тенанта в конфигурацию сервисов Batch Tasks, Batch Scheduler может выполняться при следующих исходных данных:

• Ранее использовалась конфигурация с одним тенантом.

• В конфигурации сервиса уже два и более тенантов.

В зависимости от исходных данных действия по добавлению нового тенанта будут отличаться.

Список параметров#

За настройку тенанта отвечают следующие параметры:

• ${tenant_host} — целевой хост, без протокола (HTTP/HTTPS) и порта;

• ${tenant_port} — целевой порт. Для HTTPS — 443, для HTTP — 80, если явно не требуется указать другой;

• ${tenant_inner_port} — внутренний PORT, на который httpTarget будет отправлять запросы. Пример значения: 22000;

• ${tenant_egress_port} — вспомогательный промежуточный порт. У разных тенантов должны отличаться. Рекомендуется использовать различные значения из одного диапазона, например, 21000–21999;

• ${egress_name} — наименование Egress deploy;

• ${tenant_inner_port} — внутренний порт, на который сервисы Batch будут делать вызовы. Рекомендуется использовать значение 80 для всех тенантов;

• ${tenant_protocol} — протокол. Если целевой API вызывается по HTTPS, используется значение «tls», если по HTTP — «http»;

• ${tenant_tls_mode} — режим TLS. Если целевое API вызывается по HTTPS, используется значение «MUTUAL», если по HTTP — «DISABLE»;

• ${distrib_release_version} — версия сервиса.

Ручное добавление нового тенанта#

Для добавления нового тенанта создайте и загрузите в систему оркестрации контейнеров новые конфигурационные файлы:

• destination-rule-egress-tenant.yml;

• envoy-filter-ott-egress-tenant.yml;

• gateway-egress-tenant.yml;

• service-egress-tenant.yml;

• service-entry-egress-tenant.yml.

Пример заполненного файла destination-rule-egress-tenant.yml:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: хххх-dr-egress-${tenant_name}-${distrib.release.version}
spec:
  host: ${tenant_host}
  exportTo: [.]
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN
    portLevelSettings:
      - port:
        number: ${tenant_port}
      tls:
        caCertificates: /etc/istio/egressgateway-ca-certs/ca-chain.cert.pem
        clientCertificate: /etc/istio/egressgateway-certs/tls.crt
        privateKey: /etc/istio/egressgateway-certs/tls.key
        mode: ${tenant_tls_mode}
        sni: ${tenant_host}

Пример заполненного файла envoy-filter-ott-egress-tenant.yml:

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: хххх-ev-ott-egress-auth-filter-${tenant_name}-${distrib.release.version}
spec:
  configPatches:
  - applyTo: HTTP_FILTER
  match:
    context: GATEWAY
    listener:
      filterChain:
        filter:
          name: envoy.http_connection_manager
      portNumber: ${tenant_egress_port}
  patch:
    operation: INSERT_BEFORE
    value:
      name: envoy.ext_authz
      config:
        failure_mode_allow: false
        grpc_service:
          google_grpc:
            stat_prefix: ext_authz
            target_uri: 'unix:/mnt/ott-uds-socket/ott.socket'
        timeout: {{OTT_TIMEOUT}}
      with_request_body:
        allow_partial_message: true
        max_request_bytes: 8192
  workloadSelector:
    labels:
      app: ${egress_name}

Для placeholder {{.OTT_TIMEOUT }} укажите значение 2s (данное значение принято для корректной работы с OTT и при необходимости может быть изменено).

Пример заполненного файла gateway-egress-tenant.yml:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: xxxx-gw-egress-${tenant_name}-${distrib.release.version}
spec:
  selector:
    istio: ${egress_name}
  servers:
    - hosts:
        - '*'
      port:
        name: tcp-${tenant_egress_port}-${tenant_name}
        number: ${tenant_egress_port}
        protocol: HTTPS
      tls:
        mode: ISTIO_MUTUAL

Пример заполненного файла service-egress-tenant.yml:

kind: Service
apiVersion: v1
metadata:
  name: xxxx-svc-egress-${tenant_name}-${distrib.release.version}
  labels:
    app: ${egress_name}
    istio: ${egress_name}
spec:
  ports:
    - name: tcp-15021-status
      protocol: TCP
      port: 15021
      targetPort: 15021
    - name: tcp-${tenant_egress_port}
      protocol: TCP
      port: ${tenant_egress_port}
      targetPort: ${tenant_egress_port}
  selector:
    app: ${egress_name}
    istio: ${egress_name}
  sessionAffinity: None
  type: ClusterIP

Пример заполненного файла service-entry-egress-tenant.yml:

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: xxxx-se-egress-se-${tenant_name}-${distrib.release.version}
spec:
  exportTo:
    - .
  hosts:
    - ${tenant_host}
  location: MESH_EXTERNAL
  ports:
    - name: ${tenant_protocol}-${tenant_port}
      number: ${tenant_port}
      protocol: ${tenant_protocol}
    - name: http-${tenant_inner_port}-mesh
      number: ${tenant_inner_port}
      protocol: HTTP
  resolution: DNS

Пример заполненного файла virtual-service-egress-tenant.yml:

# пример использования для направления трафика на заранее известный хост ${tenant_host} через OTT sidecar
# порт ${tenant_egress_port} на Egress

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: xxxx-vs-egress-${tenant_name}-${distrib.release.version}
spec:
  exportTo:
    - .
  gateways:
    - xxxx-gw-egress-${tenant_name}-${distrib.release.version}
    - mesh
  hosts:
    - ${tenant_host}
  http:
    - match:
        - gateways:
            - mesh
          port: ${tenant_inner_port}
      rewrite:
        authority: >-
          ${tenant_host}
      route:
        - destination:
            host: xxxx-svc-egress-${tenant_name}-${distrib.release.version}
            port:
              number: ${tenant_egress_port}
      timeout: ${tenant_timeout}
    - match:
        - gateways:
            - xxxx-gw-egress-${tenant_name}-${distrib.release.version}
          port: ${tenant_egress_port}
      rewrite:
        authority: >-
          ${tenant_host}
      route:
        - destination:
            host: ${tenant_host}
            port:
              number: ${tenant_port}
          weight: 100
      timeout: ${tenant_timeout}

Автоматизированное добавление тенанта с помощью Deploy Tools#

Для добавления тенантов добавьте настройки host в файл custom_property.yml в репозитории сервиса по пути: /conf/inventory/custom_property.yml в блоке:

tenants:
   - name: <наименование тенанта>
     host: <host системы оркестрации контейнерами>
     port: <порт host тенанта, выбирается самостоятельно>
     egress_port: <промежуточный порт для маршрутизации Istio, выбирается самостоятельно>
     inner_port: <внутренний порт для маршрутизации Istio, выбирается самостоятельно>
     protocol: http/https
     tls_mode: DISABLE/MUTUAL
     timeout: <время тайм-аута, например, 5s>
     common_names:
        - cn: .*CN=какой-то_CN_1.*
          program_size: 300
        - cn: .*CN=какой-то_CN_2.*
          program_size: 400
        - cn: .*CN=какой-то_CN_3.*
          program_size: 500

При добавлении нового тенанта выполните повторный запуск Jenkins Job Deploy Tools сервиса Batch Tasks и/или Batch Scheduler с playbook OPENSHIFT_INGRESS_EGRESS_DEPLOY согласно инструкции, приведенной в Руководстве по установке в разделе «Автоматизированная установка сервиса с использованием Deploy Tools» в подразделе «Запуск автоматизированной установки с помощью Deploy Tools» соответственно на компоненты Batch Tasks и Batch Scheduler.

Использование placeholder в шаблонах#

Так как в шаблонах файлов, приведенных в блоке uniqueParams, в параметре name присутствует placeholder {{TENANT_NAME}}, принимающий уникальные значения из os_namespaces.yml, параметры каждого тенанта размещаются в отдельных файлах после отработки Jenkins Job.

Пример заполненного файла destination-rule-egress-tenant.yml для сервиса Batch Tasks:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: batch-tasks-egress-dr-{{TENANT_NAME}}
  ...

Перенаправление запроса через внутренний порт#

Отдельное внимание стоит уделить параметрам TENANT_INNER_PORT — они могут быть как различными для разных тенантов, так и одинаковыми. Значение TENANT_INNER_PORT определяет внутренний порт сервиса, на который httpTarget будет выполнять запрос. Процесс выполнения запроса выглядит следующим образом:

1. Запрос выполняется на внутренний HTTP-порт (TENANT_INNER_PORT).

2. Запрос перенаправляется на внутренний порт Egress (TENANT_EGRESS_PORT).

3. Запрос проходит через OTT-sidecar и выполняется шифрование.

4. Запрос отправляется на реальный HOST:PORT (TENANT_HOST, TENANT_PORT).

Использование режима ReadOnly для Batch UI#

Режим ReadOnly при работе через Batch UI позволяет только просматривать сущности сервисов Batch Tasks и/или Batch Scheduler. Все остальные операции по изменению, запуску, остановке и возобновлению с использованием сервиса Batch UI недоступны.

Режим работы ReadOnly необходим при отсутствии интеграций с системами аутентификации и авторизации (СПАС, СУДИР, ОСА).

Сервис Batch UI предоставляет режим инсталляции с доступом к UI в режиме ReadOnly с помощью конфигурации развертывания.

При входе в Batch UI после авторизации отображается предупреждение:

Настройка режима ReadOnly#

Для активации режима ReadOnly для Batch UI в файле batch-ui-backend.conf установите значения параметра UI_BACKEND_ACCESS_READONLY=false. Пример:

# Контроль доступа к сервису — настройка режима readonly в batch-ui-backend
# Включение режима readonly для UI
UI_BACKEND_ACCESS_READONLY=false

Контроль доступа к сервису с использованием сервиса ОСА#

В сервисе Batch UI авторизация и работа пользователей реализована через ролевую модель с разграничением доступа на основе ролевой модели RBAC (Role — Based Access Control).

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

Для доступа к Platform V Batch используется системная роль, имя которой задается в конфигурации сервиса, по-умолчанию — defaultBatchRole.

Для каждого тенанта и сервиса вводится своя бизнес-роль, которая предоставляет доступ к методам продукта Platform V Batch. Тип роли задается в конфигурации тенанта.

По-умолчанию, предполагается, что существует только одна роль «Владелец Тенанта» (tenantOwner).

Существует возможность добавления атомарных групп ролей с ограниченными возможностями:

• просмотра (например, tenantReader);

• создания (например,tenantEditor);

• удаления (например, tenantDeleter).

При конфигурировании тенанта необходимо указать одну из обязательных ролей:

• владельца (tenant_owner_role_name);

• просмотра (read_role_name).

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

При отсутствии у пользователя обязательной роли сервис авторизации возвращает ошибку с сообщением о неправильном составе ролей у пользователя. Например, если пользователь имеет роль создания и редактирования (tenantEditor), но нет роли на чтение (read_role_name) или роли владельца (tenant_owner_role_name), пользователь получит ошибку.

Для подключения ролевой модели необходимо загрузить файл defaultBatchRole.xml в ОСА. Пример заполнения приведен в файле defaultBatchRole.xml. Инструкция по загрузке приведена в документации на сервис ОСА.

Пример ролевой модели для разграничения прав аналогичен ролевой модели для сервиса СПАС.

Подробное описание разграничения доступа приведено в документации на ОСА.

Добавление нового тенанта#

Для добавления нового тенанта в файле custom_property.yml добавьте блок module_id с необходимыми параметрами. Пример:

   - module_id: <new_tenant>
     owner_role: <new_tenant_OwnerRole1, опционально>
     read_role: <new_tenant_ReadRole1, опционально>
     write_role: <new_tenant_WriteRole1, опционально>
     delete_role: <new_tenant_DeleteRole1, опционально>

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

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

• пароль изменяется минимум один раз за 80 дней;

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

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

• пароль не должен содержать логин УЗ пользователя или какую-либо его часть;

• пароль должен быть уникален, недопустимо использование одного и того же пароля для нескольких УЗ одного пользователя;

• пароль должен храниться в зашифрованном виде, хранение пароля в незащищенном виде (в текстовых, конфигурационных файлах, скриптов) запрещено;

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

• при компрометации пароля необходимо незамедлительно его сменить;

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

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

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

Graceful shutdown#

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

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

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

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

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

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

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

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

Для конфигурирования параметров Graceful Shutdown заполните файл batch-ui-backend.conf. Пример заполнения:

# Конфигурирование параметров Graceful Shutdown для batch-ui-backend
# Сумма остальных интервалов для batch-ui-backend. Размерность — целое число секунд
UI_BACKEND_TERMINATION_GRACE_PERIOD_SECONDS=30
# Необходимое время ожидания для завершения уже запущенной итерации отбора новых задач из БД. Размерность: целое число секунд
UI_BACKEND_PRESTOP_SLEEP_DURATION_SECONDS=10
# Время на Graceful shutdown для Tomcat, который обрабатывает входящие запросы. Значение параметра задается в формате Duration, например: "PT20S"; если задать просто число, то в качестве размерности используются миллисекунды
UI_BACKEND_TIMEOUT_PER_SHUTDOWN_PHASE=PT20S

Rolling Update#

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

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

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

1. Последовательно перейдите по вкладкам Workloads → Deployment (Deployment Configs).

2. В списке выберите конфигурацию batch-ui/batch-ui-backend.

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

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

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

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

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

2. В списке выберите конфигурацию batch-ui/batch-ui-backend.

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

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

Параметр конфигурируется в файле batch-ui-backend.conf с placeholder UI_BACKEND_REPLICAS_COUNT.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример заполненного файла batch-ui-backend.conf:

# Конфигурирование параметров Rolling Update для batch-ui-backend
# Время в секундах для полного обновления. При превышении выполняется откат к предыдущей версии
UI_BACKEND_ROLLING_UPDATE_TIMEOUT_SECONDS=600
# Насколько возможно сократить количество работающих pods, относительно соответствующего параметра *_REPLICAS_COUNT
UI_BACKEND_ROLLING_UPDATE_MAX_UNAVAILABLE=1
# Насколько общее число pods (число: работающие + запускающиеся + завершающиеся), может превысить соответствующий параметр *_REPLICAS_COUNT
UI_BACKEND_ROLLING_UPDATE_MAX_SURGE=0

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

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

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

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

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

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

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

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

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

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

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

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

1. В среде контейнеризации перейдите на вкладку PODs и выберите pod batch-ui (batch-ui-backend).

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

curl localhost:8080/actuator/prometheus

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

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

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

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

Управление ключами и сертификатами#

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

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

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

2. Использование секретных данных при выполнении шагов развертывания.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подробнее о конфигурационных файлах#

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

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

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

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

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

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

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

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

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

• Issuer: УЦ банка.

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

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

При компрометации криптографических ключей (для выпуска и подписи токена) рекомендуется:

1. Приостановить информационное взаимодействие с применением скопрометированного ключа.

2. Незамедлительно поставить в известность Администратора безопасности или иное уполномоченное лицо Организации по вопросам информационной безопасности о произошедшем инциденте.

3. Следовать указания Администратора безопасности. Общий порядок действий:

• вывод из эскплуатации скомпрометированного ключа;

• проведение мероприятий по замене ключа;

• проверка работоспособности с новым ключом.

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

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

# Проверка доступности сервиса Аудит (Readiness), так же включает в себя прерывание операций при ошибке отправки события в аудит: true — проверка доступности Аудит и прерывание операции включены, false — проверка доступности Аудит и прерывание операции выключены
UI_AUDIT_HEALTH_CHECK=true

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

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

Описание#

Параметры конфигурации TASK_MAX_UPLOAD_FILE_SIZE и TASK_MAX_FILE_SIZE управляют процессом загрузки файлов для генерации задач.
Настройки влияют на:

• Максимальный допустимый размер файла.

• Размер отдельных частей (чанков) при потоковой загрузке.

Параметры конфигурации#

1. TASK_MAX_UPLOAD_FILE_SIZE#

Назначение: Определяет максимальный размер файла, который пользователь может загрузить для генерации задачи.

Формат: Размер, строковое представление с единицами измерения (например, 1B, 1KB, 1MB, 1GB, 1TB).

Примеры допустимых значений: TASK_MAX_UPLOAD_FILE_SIZE=524288000 # 500 мегабайт TASK_MAX_UPLOAD_FILE_SIZE=1MB # 1 мегабайт
TASK_MAX_UPLOAD_FILE_SIZE=2GB # 2 гигабайта

Особенности:

• Если файл превышает это значение, загрузка блокируется на этапе валидации.

• Значение должно быть ≥ TASK_MAX_FILE_SIZE.

2. TASK_MAX_FILE_SIZE#

Назначение: Задает максимальный размер одного чанка при потоковой загрузке файла.

Формат: Размер в байтах или строковое представление с единицами измерения (например, 1B, 1KB, 1MB).

Ограничения:

• Размер должен быть задан от 100KB до 2MB.

Примеры: TASK_MAX_FILE_SIZE=10KB # 10 килобайт TASK_MAX_FILE_SIZE=1MB # 1 мегабайт

Особенности:

• Значение должно быть ≤ TASK_MAX_UPLOAD_FILE_SIZE.

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

1. Соотношение параметров:

   • TASK_MAX_FILE_SIZE ≤ TASK_MAX_UPLOAD_FILE_SIZE.

2. Безопасность:

   • Не устанавливайте TASK_MAX_UPLOAD_FILE_SIZE выше доступного дискового пространства.

Типичные проблемы и решения#