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

Для выполнения сценариев администрирования администратору сервиса необходимо иметь тенант с возможностями просмотра, создания, редактирования и удаления Заданий. Настройка доступа тенанта приведена в разделе «Контроль доступа к сервису».

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

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

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

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

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

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

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

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

и нажмите Create.

Публикация 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 в СПАС. Пример заполнения приведен в файле.

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

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

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

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

Например, наличие у пользователя атрибута с именем 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 и загрузить полученный файл в СПАС:

{
    "attrName": "xxxx:pprb:namespace:d:i", // Корневой атрибут. Описывает элемент предопределенного справочника модулей
    "values": [
        "task-server"                      // Единственное значение корневого атрибута — имя модуля, для которого загружается справочник атрибутов
    ],
    "child": [
        {
            "attrName": "xxxx:pprb:batch:tasksServer:get:d", // Справочник тенанта для операции get. К справочникам добавляется суффикс ":d"
            "values": [
                "items"                                      // Единственное значение справочника — константа "items"
            ],
            "child": [
                {
                    "attrName": "xxxx:pprb:batch:tasksServer:get:d:i", // Элемент справочника тенанта. К элементам справочника добавляется суффикс ":d:i"
                    "values": [
                        "${tenantId}"                                  // Элементы справочника
                    ]
                }
            ]
        },
        {
            "attrName": "xxxx:pprb:batch:tasksServer:edit:d",           // Существует возможность список тенантов уместить в одном атрибуте или разбить на несколько
            "values": [
                "items"
            ],
            "child": [
                {
                    "attrName": "xxxx:pprb:batch:tasksServer:edit:d:i",
                    "values": [
                        "${tenantId}"
                    ]
                }
            ]
        },
        {
            "attrName": "xxxx:pprb:batch:tasksServer:delete:d",
            "values": [
                "items"
            ],
            "child": [
                {
                    "attrName": "xxxx:pprb:batch:tasksServer:delete:d:i",
                    "values": [
                        "${tenantId}"
                    ]
                }
            ]
        }
    ]
}

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

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

{
    "attrName": "sbrf:pprb:namespace:d:i", // Корневой атрибут. Описывает элемент предопределенного справочника модулей.
    "values": [
        "scheduler-server"                     // Единственное значение корневого атрибута - имя модуля, для которого загружается справочник атрибутов.
    ],
    "child": [
        {
            "attrName": "sbrf:pprb:batch:schedulerServer:get:d",   // Справочник тенант для операции get. К справочникам добавляется суффикс ":d".
            "values": [
                "items"                                        // Единственное значение справочника - константа "items".
            ],
            "child": [
                {
                    "attrName": "sbrf:pprb:batch:schedulerServer:get:d:i",  // Элемент справочника тенанта. К элементам справочника добавляется суффикс ":d:i".
                    "values": [
                        "${tenantId}"                                   // Элементы справочника.
                    ]
                }
            ]
        },
        {
            "attrName": "sbrf:pprb:batch:schedulerServer:edit:d",           // Существует возможность список тенантов уместить в одном атрибуте или разбить на несколько
            "values": [
                "items"
            ],
            "child": [
                {
                    "attrName": "sbrf:pprb:batch:schedulerServer:edit:d:i",
                    "values": [
                        "${tenantId}"
                    ]
                }
            ]
        },
        {
            "attrName": "sbrf:pprb:batch:schedulerServer:delete:d",
            "values": [
                "items"
            ],
            "child": [
                {
                    "attrName": "sbrf:pprb:batch:schedulerServer:delete:d:i",
                    "values": [
                        "${tenantId}"
                    ]
                }
            ]
        }
    ]
}

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

Обзор#

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

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

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

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

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

Для активации режима ReadOnly для Batch UI установите во всех манифестах дистрибутива параметры:

• для сервиса Batch Tasks:

tasks/server/access/enabled = false
tasks/server/access/read-only = true

• для сервиса Batch scheduler:

scheduler/server/access/enabled = false
scheduler/server/access/read-only = true

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

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

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

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

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

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

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

• ${tenant_name} — произвольное название тенанта. Допускаются буквы, цифры, дефис. Для разных тенантов значения должны отличаться. Пример: "http-target";

• ${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;

• virtual-service-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» на соответствующие компоненты.

Использование 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).

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

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

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

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

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

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

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

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

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

Реализация 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 установите параметры согласно таблице.

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

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

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

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

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

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

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

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

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

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: срок действия сертификата.

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

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

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

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

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

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