Перейти к основному содержимому

Сценарии использования Kintsugi agent (DBDA)

1. Аутентификация по протоколу OpenID Connect​

Предусловие: Стенд Kintsugi (DBCM) обслуживается OpenID провайдером.

Сценарий выполняется по шагам:

  1. Сервис агента Kintsugi загружает сертификат с диска (или получает из хранилища секретов) для дальнейшего соединения и входа в Platform V Kintsugi под ТУЗ.
  2. Сервис агента Kintsugi с полученным сертификатом обращается к OpenID Provider.
  3. Сервис агента Kintsugi обращается с запросами к серверу Kintsugi (DBCM) под ТУЗ.
  4. Входящие API-запросы агента принимаются и обрабатываются Kintsugi (DBCM).

Альтернативные сценарии​

Сервис агента Kintsugi загружает сертификат ТУЗ с локального диска (вместо получения из хранилища секретов). В этом случае параметры задаются в конфигурационном файле, и хранилище секретов не используется.

Исключительные сценарии​

Оператор не прошел аутентификацию OpenID provider. Он не будет перенаправлен на URL-адрес Kintsugi. Если оператор самостоятельно перейдет на URL-адрес Kintsugi, то он не получит доступ в систему и будет перенаправлен на адрес OpenID provider.

2. Получение и отправка метрик хоста​

Сценарий выполняется по шагам:

  1. Производится сборка метрик хоста из папки /proc.
  2. Сервис агента Kintsugi осуществляет отправку метрик в Kintsugi (DBCM). Интервал отправки и настройки подключения берутся из конфигурационного файла.
  3. Kintsugi (DBCM) получает метрики от cервиса агента Kintsugi и осуществляет запись данных.
  4. Kintsugi (DBCM) отправляет ответ на сообщение с метриками сервиса агента Kintsugi, подтверждая запись метрик.
  5. Сервис агента Kintsugi получает подтверждение о записи метрик в Kintsugi (DBCM).

Исключительные сценарии​

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

3. Отправка информации об обнаруженных СУБД на хосте​

Сценарий выполняется по шагам:

  1. Сервис агента Kintsugi авторизуется в системе Kintsugi с использованием сертификата ТУЗ.
  2. Kintsugi устанавливает соединение.
  3. Сервис агента Kintsugi запускает скрипт с правами на чтение каталога PGDATA и осуществляет проверку наличия СУБД.
  4. Сервис агента Kintsugi передает информацию о наличии новых СУБД в Kintsugi (DBCM), если агенту удалось обнаружить новые базы данных.
  5. Kintsugi (DBCM) получает информацию о наличии новых СУБД, где установлен сервис агента Kintsugi. Производится запись данных о наличии новых СУБД.
  6. Kintsugi (DBCM) отправляет ответ на сообщение с метриками сервиса агента Kintsugi, подтверждая запись метрик.
  7. Сервис агента Kintsugi получает подтверждение о записи данных в Kintsugi (DBCM).

Исключительные сценарии​

При невозможности получения информации об обнаруженных СУБД на хосте выводится сообщение об ошибке.

4. Получение сертификата из хранилища секретов​

Сценарий выполняется по шагам:

  1. Сервис агента Kintsugi считывает RoleID, SecretID из конфигурационного файла для AppRole аутентификации.
  2. Сервис агента Kintsugi проходит аутентификацию методом AppRole в системе управления секретами и запрашивает сертификат ТУЗ Kintsugi (DBCM).
  3. Система управления секретами передает сертификат ТУЗ Kintsugi (DBCM) сервису агента Kintsugi.
  4. Сервис агента Kintsugi записывает бинарные данные сертификата ТУЗ в header x-forwarded-client-cert.
  5. Сервис агента Kintsugi устанавливает соединение с системой Kintsugi (DBCM) с использованием потокового соединения.
  6. Kintsugi (DBCM) подтверждает успешное установление соединения.

Альтернативные сценарии​

Сервис агента Kintsugi выполняет аутентификацию в системе управления секретами с использованием упакованного токена (вместо метода AppRole). В этом случае агент считывает упакованный токен из файла, указанного в параметре secman.wrapped.file, и извлекает secret_id по ключу secman.wrapped.key_to_get_secret_id. Дальнейшие шаги (3–6) выполняются аналогично основному сценарию.

Исключительные сценарии​

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