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

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

Сервисы компонента STLR представляют собой облачное решение, поставляемое для установки в среду контейнеризации (Platform V DropApp (K8S) / Kubernetes / Red Hat OpenShift — опционально).

Примечание: Этот документ содержит названия переменных, которые одинаково применимы для различных сред контейнеризации, указанных в системных требованиях. Имя переменной не определяет конкретную среду контейнеризации.

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

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

Примечание:

*

• Да — ПО, необходимое для функционирования сервиса, без установки которого не гарантирована работоспособность.

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

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

Тип зависимости для некоторых компонентов определяется:

• OTTS: можно отключить на уровне конфигурационных файлов ingress/egress. Управляется поставкой разных дистрибутивов конфигураций. Критично только для развертывания с обязательным требованием использования OTTS;

• CDJE: рекомендуется установка дистрибутива с помощью Platform V DevOps Tools (DOT), при желании можно использовать другой инструмент развертывания;

• MONA: устанавливается при необходимости. Поставляется отдельным дистрибутивом МОNA, установка в namespace выполняется через CDJE, возможно использование другого сервиса мониторинга;

• LOGA: допустимо сконфигурировать отправку логов в другую систему журналирования;

• COTE: STLR может взаимодействовать с платформенным компонентом COTE, возможно использование другого сервиса аудита;

• AUTH, KCSE: обязательны для работы через пользовательский интерфейс, возможно использование иных сервисов аутентификации и авторизации;

• IGEG, sidecar istio-proxy (istio-release-1.6.14-se-release-1.2.2): обязательна к установке указанная версия и сборка, если развертывание с OTTS и для некоммунальной установки.

Настройка интеграции с вышеперечисленными сервисами происходит в процессе конфигурации параметров для конкретного внешнего сервиса в определенных ConfigMaps. Подробная информация представлена в документе «Руководство по системному администрированию».

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

Список минимальных требований к КТС представлен ниже. В контексте развертывания STLR существуют два альтернативных подхода:

• коммунальное развертывание;

• автономное (изолированное) развертывание.

Коммунальное развертывание предполагает установку STLR в общий пространственный контекст (namespace) совместно с другими компонентами Platform V. Автономное развертывание, напротив, предусматривает установку STLR в отдельный namespace, являющееся единственным для данной инстанции продукта. В случае потребности в децентрализованном развертывании SRLS, необходимо учитывать соответствующие квоты, предоставляемые для данного развертывания.

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

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

Рекомендации по наполнению продукта зависимостями при сборке с помощью Build Tools (Solution Merger Job)#

Образы контейнеров не входят в состав дистрибутива компонента STLR. Базовые образы и образы sidecar необходимо указывать при сборке продукта, используя Solution Merger Job. Перед запуском инструмента дополнения продукта зависимостями в конфигурации необходимо указать, какие базовые образы следует использовать вместо образов, указанных в Dockerfile по умолчанию.

Важно: Образы определяются в соответствии с правилами установки, в которую будет помещен собранный продукт.

Базовый образ

Рекомендуемый стек:

1. SberLinux >8.

2. NodeJS >18.

3. Platform V SynGX (SNX).

Альтернативный (опциональный) стек:

1. AltLinux

2. NodeJS >18.

3. Nginx

Пример из merger.yml

base_image_mapping:        # mapping базовых docker-образов
    - from: .*openjdk11.*
      to: <укажите базовый образ необходимый для установки> # пример nexus_host/repository/base/rhel7openjdk11:7.6-252.1561619826-86

Образы sidecar-контейнеров

В конфигурации развертывания STLR присутствуют ссылки на образы sidecar-контейнеров, Dockerfile которых отсутствует в дистрибутиве продукта (образы технологических сервисов, поставляемых в других платформенных продуктах), поэтому в конфигурации Solution Merger Job следует явно указать какие хеши образов использовать для таких sidecar-контейнеров. Необходимо указывать образы sidecar-контейнеров, соответствующие версиям, указанным в разделе «Платформенные зависимости».

Пример из merger.yml

image_link_mapping:        # mapping ссылок на образы (применяется, чтобы указать актуальные ссылки на образы sidecar-контейнеров)
  # IGEG (Istio SE)
  ":.+proxyv2@sha256:[0-9a-f]{64}": ": <укажите образ, необходимый для установки>" # пример nexus_host/repository/synapse_security/istio/proxyv2@sha256:cdd42336b164955a0550a8ce338b577177dcdd975799af3d0d8a7352f2d20fb9
  # OTTS 5.21.0, если необходима интеграция с One-Time Password (OTP) / OTT
  ":.+ott-client-api@sha256:[0-9a-f]{64}": ": <укажите образ, необходимый для установки>" # пример nexus_host/repository/ott-client-api@sha256:764085215941ecb7e90429326113fe63b78b024e8595ac3249c5d88d128574ac
  # LOGA fluent-bit
  ":.+fluent-bit@sha256:[0-9a-f]{64}": ": <укажите образ, необходимый для установки>" # пример nexus_host/repository/ulogger/fluent-bit@sha256:04da83ed2af92600f7e0b4055d707c038c6e549ed14dba6372b0a2a50ddae32d