Руководство по установке#

Термины и определения#

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

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

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

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

Примечание:

*

• Да — категория ПО обязательна для функционирования сервиса (это означает, что сервис не может выполнять свои основные функции без установки данной категории ПО).

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

**

• Рекомендовано — рекомендованный правообладателем АО «СберТех» продукт.

• Опционально — альтернативный по отношению к рекомендованному правообладателем АО «СберТех» продукт.

Платформенные зависимости#

Для настройки, контроля и функционирования компонента реализована интеграция с программными продуктами, правообладателем которых является АО «СберТех»:

Примечание:

***

• Да — компонент или продукт необходим для функционирования сервиса (это означает, что сервис не может выполнять свои основные функции без установки данного компонента).

• Нет — необязательный для функционирования сервиса компонент или продукт (это означает, что сервис может выполнять свои основные функции без установки данного компонента).

**** Рекомендуется установка программного продукта, правообладателем которого является АО «СберТех», при этом не исключена возможность (допускается правообладателем) использования аналога других производителей. Аналоги, в отношении которых продукт успешно прошел испытания и подтвердил свою работоспособность, указаны в разделе «Системное программное обеспечение».

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

Минимальные ресурсы, необходимые для режимов работы REQV:

Количество задействованных реплик компонент IGEG и прикладных приложений зависит от объема принимаемых данных.

Состав дистрибутива#

Дистрибутив содержит следующие конфигурации, в директории templates, объединенные в файлы шаблонов Helm:

Выбор способа установки#

Для компонента REQV рекомендована ручная установка, однако при необходимости и наличию компонента SMDL продукта SSM - установка может быть осуществлена с помощью Jenkins job SynapseInstallerKubernetes из дистрибутива компонента SMDL. Для использования job необходимо ознакомиться с документацией к компоненту SMDL, в документе руководстве оператора, далее перейти в раздел pipelines, и выбрать папку SynapseInstaller.

Подготовка окружения#

Для установки программного компонента Request validator (далее — Валидатор запроса) должно быть выполнено следующее:

1. Развернут и настроен кластер Платформы (Kubernetes 1.19 и выше) и SSM;

2. Развернут и настроен компонент POLM, подробное описание по настройке управлению политиками описано в документации на компонент POLM программного продукта SSM Platform V Synapse Service Mesh.

3. Развернут и настроен компонент SVPX, подробное описание по настройке сервисного прокси, описано в документации на компонент SVPX программного продукта SSM Platform V Synapse Service Mesh.

4. В кластере Kubernetes должен быть развернут отдельный проект для разработки приложений.

5. В проекте создана учетная запись с правами на загрузку артефактов

6. Docker-образ валидатор запроса размещен в целевом Docker-репозитории.

7. Настроен доступ в Docker-репозиторий для публикации образов разрабатываемых приложений.

8. В проект добавлен секрет для загрузки docker-образов из целевого Docker-репозитория.

9. Для доступа в Kubernetes c использованием консоли, на рабочем месте должен быть установлен клиент Kubernetes (kubectl).

10. При установке в системе контейнеризации все сертификаты, пароли и иная чувствительная информация хранится в одном из типов хранилищ;

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

• в файловой системе pod и получены из внешней системы хранения секретов Secret Management System.

11. Для работы компонента на целевых стендах рекомендуется использование mTLS (версия 1.2).

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

Перед установкой проверьте соблюдение следующих условий:

1. При работе компоненты REQV с IGEG требуется наличие компонент Platform V Synapse Service Mesh: IGEG, SVPX;

2. В кластере создан проект в котором будет разворачиваться валидатор запросов. При работе компоненты REQV с IGEG требуется подключить проект к контрольной панели SSM;

3. В проекте создана учетная запись с правами на загрузку артефактов (администратор проекта);

4. Получена ссылка на целевой Docker-репозиторий;

5. В проект добавлен секрет для загрузки docker-образов из целевого Docker-репозитория;*

6. В проекте имеются свободные ресурсы по лимитам и реквестам не менее, чем зарезервировано в конфигурационных артефактах;

7. При установке с использованием консоли, на рабочем месте должен быть установлен клиент Helm и клиент Kubernetes (kubectl).

Установка#

Ручная установка сервиса#

Установка сервиса валидации. В зависимости от целей бизнес-сервиса сервис валидации может быть установлен в следующих режимах:

• Работа в режиме sidecar в Ingress Gateway Deployment;

• Работа в режима sidecar в Egress Gateway Deployment;

• Работа в режиме отдельного сервиса Валидации.

Для установки компонента выполните следующие действия:

1. Создайте директорию установки.

2. Подключитесь к проекту.

Для подключения через консоль Платформы:

3. Настройка стендозависимых параметров

Для выбора режима установки необходимо в файле helm/sidecar-validator/reqv-pao/values.yaml отредактировать следующие параметры:

• is_istio_se: true - если проект подключен к Istio SE - true. Если проект подключен к RHSM - false

• common:

  • registry: repositoty@tag адрес репозитория с образом валидатора

  • proxy_image: repositoty@tag адрес репозитория с образом istio-proxy если проект подключен к RHSM

  • proxy_image_istio_se: repositoty@tag адрес репозитория с образом istio-proxy если проект подключен к Istio SE

• controlPanel: "istio-system" - имя контрольной панели к которой подключен проект

• istioServiceName: "istiod-istio-system" - имя сервиса istiod

• project_name: istio-test - имя проека куда производится установка

• include:

  • ingress: true - если установка в режиме sidecar Ingress Gateway, false - если установка в режиме sidecar Ingress Gateway не требуется

  • egress: true - если установка в режиме sidecar Egress Gateway, false - если установка в режиме sidecar Egress Gateway не требуется

  • standalone: true - если требуется установка в режиме отдельного сервиса, false - если не требуется

• test_service: true - если требуется установка сервиса "заглушки", false - если не требуется

• test_service_image:

  • repository: repositoty@tag адрес репозитория с образом

• jwt_polisy: "third-party-jwt" указать jwt_polisy - third-party-jwt или first-party-jwt

• audit: если true, то сообщения в аудит отправляются по HTTPs через egress

  • HTTPs: true

  • service_port: 8081 указать port для сервиса аудита

  • host: example.ru указать host аудита

  если HTTPs отключен (.Values.audit.https: false) и требуется отправка напрямую в аудит, указываем URL аудита url: http://audit.ru

  когда HTTPs включен (.Values.audit.https: true) если установка в режиме sidecar Ingress Gateway (.Values.include.ingress) или в режиме отдельного сервиса (.Values.include.standalone), за место указываем egress-audit-svc-reqv

  если установка в режиме sidecar Egress Gateway (.Values.include.еgress), за место указываем reqv-egressgateway

  • url: http://.<class 'jinja2.utils.Namespace'>.svc:8081

• secman:

  • enabled: true ниже пример заполненных аннотаций secman. Приведенные значения заменить на свои: SYNAPSE/KV/REQV - путь к сертификатам <пространство в хранилище>/<имя секрета> synapse - роль в SecMan, получаемая при подключении к хранилищу

  • common:

    • annotations:

      • namespace: "''"

      • role: synapse

      • authPath: auth/synapse

  • mTLS:

    • enabled: true

    • annotations:

      • template_tls_key: |

      • template_ca_crt: |

      • template_tls_crt: |

_если сообщение требуется отправить в аудит через egress, добавятся аннотации для подгрузки сертификатов

• audit:

  • enabled: true

  • annotations:

    • template_audit_tls_key: |

    • template_audit_ca_crt: |

    • template_audit_tls_crt: |

4. Установите валидатор.

Для установки через консольного клиента платформы

Подробнее о настройке конфигурационного файла описано в документе Руководство по системном администрированию раздел Общая настройка приложения в ConfigMap.

Настройка интеграции#

Настройка интеграции с компонентом IGEG

Описание и настройка интеграции компонента REQV с IGEG описаны в данном руководстве, раздел «Ручная установка сервиса».

Настройка интеграции с компонентом AUDT

Описание и настройка интеграции компонента REQV с AUDT описаны в Руководство по системному администрированию раздел «Базовое конфигурирование».

Обновление#

Для обновления версии сервиса валидации необходимо обновить Deployment, sidecar которого является REQV, либо деплоймента отдельного сервиса REQV. Для этого поменять версию docker-образа сервиса в разделе containers на новую или установить релиз с обновленной версией. Артефакты ConfigMap и EnvoyFilter являются конфигурационными для сервиса, в котором инжектирован REQV, и в случае обновления ставятся из релиза с обновленной версией компоненты REQV. Удаление старой версии перед обновлением не требуется.

Для обновления выполните следующие шаги:

1. Создайте директорию установки.

2. Подключитесь к проекту.

Для подключения через консоль Платформы проделать шаги раздела «Ручная установка сервиса» пункт 2 данного документа

3. Загрузите новую версию. Для обновления используется стратегия rolling:

1. Загрузите новую версию через консоль Платформы, проделав шаги раздела «Ручная установка сервиса» пункт 3,4 данного документа и поменяв версию образа валидатора.

2. Если при установке использовался Helm, то выполните команду "helm upgrade reqv", что запустит обновление пакета с перезагрузкой pods приложения.

Удаление#

Для удаления компонента необходимо выполнить команду:

• Перейдите в каталог helm/sidecar-validator/reqv-pao. Выполните в консоли команду: "helm remove reqv."

Проверка работоспособности#

Проверьте pods сервиса валидации через веб-интерфейс платформы оркестарции (Kubernetes). Pod должен быть в статусе "Running" Данный способ подходит для всех режимов работы REQV.

Проверка корректности работы:

1. Выберите на вкладке Pods один из pods и кликните правой кнопкой мыши.

2. Выберите на открывшейся странице вкладку Logs. Выберите контейнер валидатора запросов и убедитесь, что отсутствуют ошибки в консольном выводе.

Валидация при развертывании в Граничном прокси (IGEG).

Проверяемые функции:

1. Прием сообщений от граничных прокси по протоколу REST

2. Валидация тела сообщения согласно схемам валидации форматов XML и JSON

3. Логирование событий приема и валидации сообщений

Проверка интеграции с продуктом Platform V Audit SE (AUDT) выполняется в самом продукте AUDT.

###Проверка работоспособности компонента REQV, собранного на SberLinux в DropApp.

а) Откройте веб-терминал DropApp

б) Выберите namespace с развернутым компонентом REQV, в соответствии с инструкцией описанной в документе Руководство по установке

в) Откройте раздел деплоймент и найдите деплоймент компонента REQV

г) Перейдите на вкладку pods и убедитесь, что все pods в статусе Running

д) Откройте запущенный pod компонента REQV

е) Перейдите на вкладку терминал и введите команду cat /etc/os-release - в выводе команды присутствует информация о том, что REQV работает на базовом образе SberLinux.

Проверка наличия и работоспособности Secret Management System определяется наличием в развертываемом компоненте IGEG контейнера с именем vault.

Откат#

Для отката до предыдущей версии сервиса валидации необходимо выполнить команду: helm rollback, находясь в директории шаблонов из раздела «Ручная установка сервиса», пункт 3 данного документа. Удаление текущей версии перед откатом до предыдущей версии не требуется. Максимальное количество версий для отката 2.

Часто встречающиеся проблемы и пути их устранения#

Чек-лист валидации установки#

1. Проверка наличия sidecar с сервисом валидации. Открыть Deployment Ingress Gateway/Egress Gateway, либо отдельный сервис REQV, в режиме просмотра и найти работающий контейнер приложения валидации.

2. Проверка конфигурации сервиса валидации. Открыть раздел ConfigMaps платформы Kubernetes и найти конфигурации с именами «validator-config» и «validator-schemas».

3. Проверить наличие артефактов с типом EnvoyFilter с именем «validator-ingress» и/или «validator-egress» в случае установки REQV в режиме Ingress/Egress.