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

В настоящем документе приведены инструкции по установке компонента JDBC Gateway (код JDBC), далее — Шлюз БД, из состава программного продукта Platform V Synapse Enterprise Integration (код SEI).

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

Назначение документа#

Настоящий документ содержит руководство по установке Компонента «JDBC Gateway» программного продукта Platform V Synapse Enterprise Integration (далее так же «Шлюз БД»), который предоставляет облачным приложениям возможность вызова процедур, хранящихся во внешней БД.

Важно!

Компонент «Шлюз БД» поставляется в виде собранного Docker-образа, размещаемого в целевом Docker-репозитории, и предназначен для использования в составе прикладных интеграционных решений, разрабатываемых продуктовыми командами.

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

Компонент «Шлюз БД» не предназначен для самостоятельной эксплуатации вне рамок прикладных интеграционных решений.

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

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

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

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

Примечание:

*

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

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

**

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

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

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

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

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

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

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

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

На данный момент поддерживается только ручная установка.

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

Для установки Шлюза JDBC в составе прикладного дистрибутива должно быть выполнено следующее:

1. Развернут и настроен кластер Kubernetes в соответствии с требованиями, предъявляемыми к Платформе.

2. В кластере создан проект (namespace), в котором будет разворачиваться шлюз.

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

4. Выпуск сертификатов для защищенного соединения с БД

5. Docker-образ шлюза размещен в целевом Docker-репозитории по ссылке, указанной в конфигурационном артефакте Deployment.

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

7. Подготовлен комплект настроенных конфигурационных артефактов.

8. В БД созданы необходимые процедуры и функции, к ним предоставлен соответствующий доступ, который настроен исходя из принципа минимальных полномочий.

9. В БД созданы необходимые процедуры и к ним предоставлен соответствующий доступ.

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

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

При опциональном использовании совместно со Шлюзом JDBC Сайдкара компонента «Сервисный прокси» (SVPX) продукта «Platform V Synapse Service Mesh» (SSM) минимальные ресурсы, необходимые для запуска, следует уточнить в соответствующей документации используемого компонента.

Перечень программных продуктов, используемых при установке:

Установка#

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

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

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

Пререквизиты#

1. Базовый образ для сборки docker image загружен в docker registry.

2. Установлен клиент kubectl.

3. Установлен docker.

Публикация базового образа#

1. Загрузить образ из файла командой docker load

2. Поставить тег полученному образу и залить в docker registry (командами docker tag, docker push)

Сборка образа из owned и party частей#

1. Скачать party и owned дистрибутивы.

2. Разархивировать party дистрибутив.

3. Разархивировать owned дистрибутив и разархивировать архив в нем.

4. Скопировать содержимое party дистрибутива в разархивированную owned часть по пути package/bh/BOOT-INF/lib.

5. Перейти в терминале в директорию package/ дистрибутива owned.

6. Скопировать в данную директорию dockerfile из package/conf/k8s/base/synapse-esb-database-adapter/Dockerfile и отредактировать его, указав путь до базового образа:

   cp conf/k8s/base/synapse-esb-database-adapter/Dockerfile .
   

7. Выполнить сборку докер образа, предварительно авторизоваться в docker registry (командой docker login):

    docker build .
   

8. Поставить тег полученному образу и залить в docker registry (командами docker tag, docker push)

Добавление скрипта ожидания в образ приложения#

В приложение добавляются скрипт ожидания секретов из HashiCorp Vault waitingSecrets.sh и скрипт entrypoint.sh с командой запуска приложения.

В DockerFile прописывается последовательность запуска скрипта (waitingSecrets.sh вызывает entrypoint.sh) и собирается новый образ приложения.
Пример DockerFile:

 FROM registry.delta.sbrf.ru/base/redhat/openjdk/openjdk-11-rhel8:latest
  
 COPY jarName.jar jarName.jar
 COPY  ./src/main/resources/waitingSecrets.sh waitingSecrets.sh
 COPY  ./src/main/resources/entrypoint.sh entrypoint.sh
 ENTRYPOINT ["sh","waitingSecrets.sh"]

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

 using /tmp/secman/config/secman.txt
 Secman config found
 Waiting for secrets:
 /deployments/config/db/certs/ca.crt
 /deployments/config/db/certs/cert.crt
 /deployments/config/db/certs/key.pk8
 file /deployments/config/db/certs/ca.crt exist
 file /deployments/config/db/certs/cert.crt exist
 file /deployments/config/db/certs/key.pk8 exist
 Waiting 1 s.
  
   .   ____          _            __ _ _
  /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
 ( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
  \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
   '  |____| .__|_| |_|_| |_\__, | / / / /
  =========|_|==============|___/=/_/_/_/
  :: Spring Boot ::                (v2.4.4)
  
 2022-05-31 15:42:56.295 [INFO ] [main] [com.sbt.synapse.Application] [T:] - Starting Application using Java 11.0.4 on service-db-module-857f66986-68lkt with PID 9 (/home/jboss/services-db-module-1.3.4.jar started by ? in /home/jboss)
 2022-05-31 15:42:56.381 [DEBUG] [main] [com.sbt.synapse.Application] [T:] - Running with Spring Boot v2.4.4, Spring v5.3.5
 2022-05-31 15:42:56.384 [INFO ] [main] [com.sbt.synapse.Application] [T:] - No active profile set, falling back to default profiles: default

Установка общих компонентов#

1. Добавление к проекту механизмов ServiceMesh Kubernetes/Istio

       kubectl label namespace имя_неймспейса istio-injection=enabled
   

2. Для установки Компонента «Сервисный прокси» (SVPX) продукта «Platform V Synapse Service Mesh» (SSM) нужно отредактировать deployment dc.yaml по пути package/conf/k8s/base/synapse-esb-database-adapter, и заполнить необходимые переменные:

   jdbc.istio.enabled - включение/отключение контейнера Компонента «Сервисный прокси» (например, true/false)
   jdbc.ose.deployment.metadata.annotations.sidecar.istio.io.proxyCPU - cpu request для контейнера Компонента «Сервисный прокси» (например, 500m)
   jdbc.ose.deployment.metadata.annotations.sidecar.istio.io.proxyCPULimit - cpu limit для контейнера Компонента «Сервисный прокси» (например, 500m)
   jdbc.ose.deployment.metadata.annotations.sidecar.istio.io.proxyMemory - memory request для контейнера Компонента «Сервисный прокси» (например, 512m)
   jdbc.ose.deployment.metadata.annotations.sidecar.istio.io.proxyMemoryLimit - memory limit для контейнера Компонента «Сервисный прокси» (например, 512m)
   

3. Для установки Компонента «Журналирование» (LOGA) нужно отредактировать конфигурационный файл deployment dc.yaml по пути package/conf/k8s/base/synapse-esb-database-adapter, вставив блок ниже:

   spec:
     volumes:
       - name: sendkafka 
         emptyDir: {}
       - name: filebeat-tmp
         emptyDir: {}
       - name: filebeat
         configMap:
           name: filebeat-jdbc
           defaultMode: 256
     containers:
       - name: filebeat
         image: <образ Компонента «Журналирование»>
         resources:
           limits:
             cpu: 200m
             memory: 200Mi
           requests:
             cpu: 100m
             memory: 100Mi
         volumeMounts:
           - name: sendkafka
             mountPath: /send
           - name: filebeat-tmp
             mountPath: /usr/share/filebeat/data/
           - name: filebeat
             readOnly: true
             mountPath: /usr/share/filebeat/filebeat.yml
             subPath: filebeat.yml
           - name: synapselogs
             mountPath: /opt/synapse/logs
         terminationMessagePath: /dev/termination-log
         terminationMessagePolicy: File
         imagePullPolicy: Always
         securityContext:
           runAsNonRoot: true
           readOnlyRootFilesystem: true
   

А также создать ConfigMap с конфигурацией:

   kind: ConfigMap
   apiVersion: v1
   metadata:
      name: filebeat-jdbc
   data:
      filebeat.yml: |-
         filebeat.inputs:
           - type: log
             enabled: true
             close_removed: true
             close_inactive: 2m
             tail_files: true
             scan_frequency: 1s
             max_bytes: 1000000000
             paths:
               - /opt/synapse/logs/*.log

         output.logstash:
           hosts: ["logstash-jdbc-service:5055"]
           loadbalance: true

         filebeat.shutdown_timeout: 10s
         logging.level: error
         logging.metrics.enabled: true

4. Для установки Компонента HashiCorp Vault нужно отредактировать deployment dc.yaml по пути package/conf/k8s/base/synapse-esb-database-adapter, и заполнить необходимые переменные:

   jdbc.secman.enabled - подключить сайдкар Secman (например, true)
   jdbc.ose.deployment.spec.template.metadata.annotations.vault.hashicorp.com.log-level - уровень логирования для HashiCorp Vault (например, info)
   jdbc.ose.deployment.spec.template.metadata.annotations.vault.hashicorp.com.namespace - имя созданного хранилища в HashiCorp Vault (например, DEV_DZO)
   jdbc.ose.deployment.spec.template.metadata.annotations.vault.hashicorp.com.role - имя полученной роли в HashiCorp Vault (например, role-ga-secman-syte)
   jdbc.secman.vault.path - путь до хранилища с секретами в HashiCorp Vault (например, A/IFT/FS/JDBC/KV/POSTGRES)
   jdbc.secman.vault.mount-path - путь для загрузки секретов в файловой системе Pod (например, /deployments/config/db)
   jdbc.ose.deployment.spec.template.metadata.annotations.vault.hashicorp.com.agent-limits-cpu - cpu limit для HashiCorp Vault (например, 250m)
   jdbc.ose.deployment.spec.template.metadata.annotations.vault.hashicorp.com.agent-limits-mem - memory limit для HashiCorp Vault (например, 128Mi)
   jdbc.ose.deployment.spec.template.metadata.annotations.vault.hashicorp.com.agent-requests-cpu - cpu request для HashiCorp Vault (например, 125m)
   jdbc.ose.deployment.spec.template.metadata.annotations.vault.hashicorp.com.agent-requests-mem - memory request для HashiCorp Vault (например, 64Mi)
   

А также отредактировать configmap-secman-mount.yaml по пути package/conf/k8s/base/configmaps/ заполнив параметр:

jdbc.prop.sslrootcertpath - путь к корневому сертификату (например, /deployments/config/db/ca.crt)
jdbc.prop.sslcertpath - путь к клиентскому сертификату (например, /deployments/config/db/cert.crt)
jdbc.prop.sslkeypath - путь к файлу клиентского ключа (например, /deployments/config/db/key.pk8)
jdbc.prop.dbsecretpath - путь к файлу с конфиденциальными данными, такими как пароль пользователя базы данных  (например, /deployments/config/db/db-secret.yml)

5. Для интеграции с компонентом MONA продукта Platform V Monitor необходимо в конфигурацию deployment dc.yaml добавить следующие аннотации:

  annotations:
    prometheus.io.path: /actuator/prometheus        # контроллер, с которого собирать метрики
    prometheus.io.port: '8080'                      # порт, на котором доступен web server
    prometheus.io.scrape: 'true'                    # включание сбора метрик с помощью MONA

Установка сервера базы данных#

Установка сервера базы данных Postgres осуществляется по инструкции Руководство по установке Компонента «Platform V Pangolin» (PSQL) продукта «Platform V Pangolin SE». Для выпуска клиентского сертификата и ключа можно воспользоваться инструкцией Порядок создания хранилищ ключей и сертификатов для Шлюза БД в Руководстве по безопасности. Создание серверного сертификата и ключа для базы данных описано в разделе Настройка базы данных в Руководстве по безопасности.

Установка Шлюза БД#

1. Отредактировать deployment dc.yaml по пути package/conf/k8s/base/synapse-esb-database-adapter, а также заполнить необходимые переменные:

   jdbc.ose.deployment.spec.replicas - количество реплик пода (например, 2)
   jdbc.ose.deployment.spec.strategy.rollingUpdate.maxUnavailable -  максимальное количество подов, которые могут быть недоступны при обновлении (например, 0)
   jdbc.ose.deployment.spec.strategy.rollingUpdate.maxSurge - максимальное количество подов, которое можно создать сверх желаемого количества подов (например, 25%)
   jdbc.ose.deployment.spec.template.spec.terminationGracePeriodSeconds - время, которое даётся приложению на корректную остановку (например, 50)
   jdbc.ose.deployment.spec.template.spec.priorityClassName - параметр, для управления приоритетом компонентов через механизм PriorityClass (например, '')
   jdbc.ose.deployment.spec.template.spec.containers.jdbc.resources.limits.cpu - cpu limit для контейнера приложения (например, 800m)
   jdbc.ose.deployment.spec.template.spec.containers.jdbc.resources.limits.memory - memory limit для контейнера приложения (например, 800Mi)
   jdbc.ose.deployment.spec.template.spec.containers.jdbc.resources.requests.cpu  - cpu request для контейнера приложения (например, 800m)
   jdbc.ose.deployment.spec.template.spec.containers.jdbc.resources.requests.memory - memory request для контейнера приложения (например, 800Mi)
   jdbc.ose.deployment.spec.template.spec.containers.jdbc.livenessProbe.failureThreshold - количество ошибочных запросов необходимых для провального прохождения liveness пробы (например, 5)
   jdbc.ose.deployment.spec.template.spec.containers.jdbc.livenessProbe.initialDelaySeconds - время инициализации liveness пробы в секундах (например, 60)
   jdbc.ose.deployment.spec.template.spec.containers.jdbc.livenessProbe.periodSeconds - частота запросов liveness пробы в секундах (например, 10)
   jdbc.ose.deployment.spec.template.spec.containers.jdbc.livenessProbe.successThreshold - количество успешных запросов необходимых для успешного прохождения liveness пробы (например, 1)
   jdbc.ose.deployment.spec.template.spec.containers.jdbc.livenessProbe.timeoutSeconds - таймаут в секундах, за который приложение должно ответить по запросу liveness пробы (например, 10)
   jdbc.ose.deployment.spec.template.spec.containers.jdbc.readinessProbe.failureThreshold - количество ошибочных запросов необходимых для провального прохождения readiness пробы (например, 5)
   jdbc.ose.deployment.spec.template.spec.containers.jdbc.readinessProbe.initialDelaySeconds - время инициализации readiness пробы в секундах (например, 60)
   jdbc.ose.deployment.spec.template.spec.containers.jdbc.readinessProbe.periodSeconds - частота запросов readiness пробы в секундах (например, 10)
   jdbc.ose.deployment.spec.template.spec.containers.jdbc.readinessProbe.successThreshold - количество успешных запросов необходимых для успешного прохождения readiness пробы (например, 1)
   jdbc.ose.deployment.spec.template.spec.containers.jdbc.readinessProbe.timeoutSeconds - таймаут в секундах, за который приложение должно ответить по запросу readiness пробы (например, 10)
   jdbc.ose.configmap.javaArguments - параметры запуска JVM (например, -Xms1000m -Xmx1000m -XX:+UseG1GC -XX:+ExitOnOutOfMemoryError)
   registry - хост docker registry (например, dzo.sw.sbc.space)
   registry_path - путь docker registry до образа  (например, /sbt_dev/ci90000017_synapse_dev)
   distrib.release.version - версия дистрибутива (например, v1)
   

2. Также в файле dc.yaml в поле image указать тег образа, полученный на шаге 8 этапа сборки.

3. Отредактировать configmap-service-db-module.yaml по пути package/conf/k8s/base/configmaps/ заполнив параметр:

   jdbc.threadpool.maxconcurrentconsumers - максимальное количество потоков обработки gRPC-запросов, которое может использовать сервер (например, 20)
   jdbc.threadpool.concurrentconsumers - количество потоков обработки gRPC-запросов при старте сервера (например, 5)
   jdbc.logs.enabled - логический параметр, отвечающий за журналирование IN/OUT-параметров, передаваемых и получаемых из хранимых процедур (например, false)
   jdbc.datasource.dburl - адрес базы данных (например, jdbc:postgresql://<host>:<port>/<database>)
   jdbc.datasource.maxpoolsize - # максимальное количество подключений в пуле базы данных (например, 20)
   jdbc.debug.enabled - логический параметр, отвечающий за включение уровня логирования типа debug для jvm (например, false)
   jdbc.prop.tlsprotocol - требуемая версия TLS протокола JVM (например, TLSv1.2)
   jdbc.prop.cipherSuites - требуемый алгоритм шифрования JVM (например, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384)
   jdbc.prop.ssl - логический параметр, отвечающий за включение ssl соединения (например, true)
   jdbc.datasource.username - имя пользователя базы данных (например, postgres)
   jdbc.prop.sslmode- метод аутентификации при заданном параметре ssl: true (например, verify-full)
   jdbc.prop.sslhostnameverifier - проверка всего DN серверного сертиката, работает при sslmode=verify-full (например, com.sbt.synapse.dnverify.DnHostnameVerifier)
   jdbc.prop.sslalloweddn - разрешенный список DN серверных сертификатов в формате строки, работает при значении sslhostnameverifier=com.sbt.synapse.dnverify.DnHostnameVerifier (например, 'CN=10.xx.xx.xx, O=SBRF, C=RU;CN=hostname.ru, O=SBRF, C=RU')
   jdbc.prop.dnmaxcount - параметр, указывающий максимальное количество разрешенных DN (например, 2)
   jdbc.prop.sslrootcertpath - путь к корневому сертификату (например, /deployments/config/db/ca.crt)
   jdbc.prop.sslcertpath - путь к клиентскому сертификату (например, /deployments/config/db/cert.crt)
   jdbc.prop.sslkeypath - путь к файлу клиентского ключа (например, /deployments/config/db/key.pk8)
   jdbc.prop.dbsecretpath - путь к файлу с паролем пользователя или других конфидециальных данных ( например, /deployments/config/db/db-secret.yml)
   jdbc.crypto.enabled - логический параметр, отвечающий за включение/выключение поддержки шифрования (например, true)
   jdbc.crypto.keyExpirationHours - интервал обновления симметричного ключа в часах (например, 24)
   jdbc.crypto.keySize - размер симметричного ключа в битах (например, 256)
   jdbc.crypto.asymmetricAlgorithmName - алгоритм ассиметричного шифрования (например, RSA)
   jdbc.crypto.asymmetricMode - режим ассиметричного шифрования (например, ECB)
   jdbc.crypto.asymmetricPadding - схема заполнения для ассиметричного шифрования (например, PKCS1Padding)
   jdbc.crypto.symmetricAlgorithmName - алгоритм симметричного шифрования (например, AES)
   jdbc.crypto.symmetricMode - режим симметричного шифрования (например, GCM)
   jdbc.crypto.symmetricPadding - схема заполнения для ассиметричного шифрования (например, NoPadding)
   jdbc.crypto.provider - крипто провайдер (например, BC)
   jdbc.crypto.returnAsIsOnError - если true и при расшифровке сообщения возникнет ошибка Шлюз БД вернет сообщение в исходном виде, если он равен false, то при возникновении ошибки выбросит exception и обработка сообщения прекратится
   jdbc.crypto.secman.role - роль Secman в кластере (например, role-ga-secman-syte)
   jdbc.crypto.secman.vaultaddr - стенд Secman (например, secman-dzo.solution.sbt:8443)
   jdbc.crypto.secman.osaddr - стенд кластера (например, stands-vdc01.solution.sbt)
   jdbc.crypto.secman.vaultpath - путь в Secman, где лежат сертификаты шифратора (Ключи в секрете должны быть названы pem и key) (например, A/IFT/FS/JDBC/KV/POSTGRESCYPHER)
   jdbc.crypto.secman.vaultns - имя хранилища в Secman (например, DEV_DZO)
   

4. Отредактировать synapse-esb-adapter-se.yaml по пути package/conf/k8s/base/istio/config/egress, а также заполнить необходимые переменные:

   jdbc.ose.istio.endpoint.enable - включение указания ip базы данных (например, true)
   jdbc.ose.istio.endpoint - ip базы данных (например, 10.xx.xx.xx)
   jdbc.ose.istio.databasehost - имя хоста базы данных (например, ignite)
   jdbc.ose.istio.egress.databaseport - порт базы данных (например, 5432)
   

5. Установить компоненты, необходимые для работы адаптера (kubectl apply -f <имя компонента>):

   • Deployment;

   • Service;

   • ServiceEntry с точками подключения к серверам БД;

   • ConfigMap с настройками шлюза;

   • ConfigMap с параметрами вызова процедур/функций в базе данных;

   • ConfigMap со списком секретов, которые нужно ждать из HashiCorp Vault;

    kubectl apply -f conf/k8s/base/configmaps/configmap-entity.yaml
    kubectl apply -f conf/k8s/base/configmaps/configmap-secman-mount.yaml
    kubectl apply -f conf/k8s/base/configmaps/configmap-service-db-module.yaml
    kubectl apply -f conf/k8s/base/istio/config/egress/synapse-esb-adapter-se.yaml
    kubectl apply -f conf/k8s/base/synapse-esb-database-adapter/dc.yaml
    kubectl apply -f conf/k8s/base/synapse-esb-database-adapter/svc.yaml
    kubectl apply -f conf/k8s/base/empty-service/svc.yaml
   

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

Ниже описана процедура интеграции с рекомендованным АО «СберТех» продуктами. На усмотрение пользователя может быть настроена интеграция с аналогичным по функциональности продуктами от других производителей.

Интеграция с продуктом Platform V Pangolin SE производится через компонент Platform V Pangolin (PSQL) путем конфигурирования параметра jdbc.datasource.dburl в 3 шаге подраздела "Установка Шлюза БД", подробнее описано в инструкции "Руководство по установке". Интеграция с продуктом Platform V Monitor производится через компонент Журналирование (LOGA), процесс конфигурации описан в документации на этот компонент "Руководство по установке". Интеграция с продуктом Platform V Synapse Service Mesh производится компонент Сервисный прокси (SVPX) в автоматическом режиме после подключения проекта в контрольной панели Synapse Service Mesh, подробности описаны в документации на это компонент. Интеграция с HashiCorp Vault производится путем конфигурирования параметров в разделе "Установка общих компонентов", детальнее можно ознакомится в документации на этот компонент, и в нижеследующем разделе Интеграция Шлюза БД с HashiCorp Vault.

Интеграция Шлюза БД с HashiCorp Vault#

Пререквизиты:

• создано хранилище в HashiCorp Vault;

• в хранилище загружены секреты (подробнее в разделе Хранение секретов в Secret Management в Руководстве по безопасности);

• получена роль HashiCorp Vault на данное хранилище;

• выдан доступ к данному хранилищу HashiCorp Vault на проект, в который устанавливается Deployment;

Интеграция Шлюза БД с HashiCorp Vault для базы Postgres#

1. Для интеграции необходимо отредактировать Deployment, добавив следующие аннотации:

   Настройка Deployment для интеграции с HashiCorp Vault

   spec:
     template:
       metadata:
         annotations:
           vault.hashicorp.com/agent-inject: 'true'                        # включить sidecar HashiCorp Vault
           vault.hashicorp.com/namespace: <NAMESPACE_VAULT>                # имя созданного хранилища в HashiCorp Vault (например, CI01994970_CI02129749)
           vault.hashicorp.com/role: <SECMAN_ROLE>                         # имя полученной роли в HashiCorp Vault (например, ci01994970_ci02129749_a_snps_osh_ift_ac)
           vault.hashicorp.com/secret-volume-path: <SECMAN_MOUNT_PATH>     # путь для загрузки секретов в файловой системе Pod (например, /deployments/config/db/certs)
           vault.hashicorp.com/agent-inject-secret-cert.crt: 'true'        # включить чтение секрета cert.crt
           vault.hashicorp.com/agent-inject-template-cert.crt: |           # создается файл cert.crt в файловой системе
             {{- with secret <SECRET_PATH> -}}                             # путь до секрета в HashiCorp Vault (например, CI01994970_CI02129749/A/SNPS/OSH/IFT/KV/JDBC)
             {{ base64Decode .Data.cert }}                                 # значение из HashiCorp Vault по ключу cert, переведенное из base64
             {{- end }}                                                                                               
           vault.hashicorp.com/agent-inject-secret-ca.crt: 'true'          # включить чтение секрета ca.crt
           vault.hashicorp.com/agent-inject-template-ca.crt: |             # создается файл ca.crt
             {{- with secret <SECRET_PATH> -}}                             # путь до секрета в HashiCorp Vault (например, CI01994970_CI02129749/A/SNPS/OSH/IFT/KV/JDBC)
             {{ base64Decode .Data.ca }}                                   # значение из HashiCorp Vault по ключу ca, переведенное из base64
             {{- end }}
           vault.hashicorp.com/agent-inject-secret-key.pk8: 'true'         # включить чтение секрета key.pk8
           vault.hashicorp.com/agent-inject-template-key.pk8: |            # создается файл key.pk8 в файловой системе
             {{- with secret <SECRET_PATH> -}}                             # путь до секрета в HashiCorp Vault (например, CI01994970_CI02129749/A/SNPS/OSH/IFT/KV/JDBC)
               {{ base64Decode .Data.key }}                                # значение из HashiCorp Vault по ключу key, переведенное из base64
             {{- end }}
           vault.hashicorp.com/agent-inject-secret-db-secret.yml: 'true'   # включить чтение секрета db-secret.yml
           vault.hashicorp.com/agent-inject-template-db-secret.yml: |      # создается файл db-secret.yml
             {{- with secret <SECRET_PATH> -}}                             # путь до секрета (например, CI01994970_CI02129749/A/SNPS/OSH/IFT/KV/JDBC)
             {{ base64Decode .Data.secret }}                               # значение из HashiCorp Vault по ключу db-secret.yml, переведенное из base64
             {{- end }}
       spec:
         volumes:
           - name: db-postgre-secman # новая ConfigMap со списком секретов, которые нужно ждать
             configMap:
               name: db-postgre-secman
               items:
                 - key: secman.txt
                   path: secman.txt
               defaultMode: 256
         containers:
           - volumeMounts:
               - name: db-postgre-secman # новая ConfigMap со списком секретов, которые нужно ждать
                 readOnly: true
                 mountPath: /tmp/secman/config
   

2. Добавить в ConfigMap, в котором прописываются настройки подключения к базе данных, пути до сертификатов:

ConfigMap с настройками подключения к базе данных

 kind: ConfigMap
 apiVersion: v1
 metadata:
   name: service-db-module-app-config
 data:
   application.yml: |-
     ...
     ds:
       prop:
         sslrootcert: /deployments/config/db/certs/ca.crt
         sslcert: /deployments/config/db/certs/cert.crt
         sslkey: /deployments/config/db/certs/key.pk8

3. Добавить ConfigMap, в котором прописывается список файлов, загружаемых в Pod из HashiCorp Vault:

ConfigMap со списком загружаемых файлов из HashiCorp Vault

  kind: ConfigMap
  apiVersion: v1
  metadata:
    name: db-postgre-secman
  data:
    secman.txt: |-
      /deployments/config/db/certs/ca.crt     # указываем путь, который мы указали в аннотации vault.hashicorp.com/secret-volume-path
      /deployments/config/db/certs/cert.crt
      /deployments/config/db/certs/key.pk8
      /deployments/config/db/db-secret.yml

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

Пример проверки загрузки секретов из HashiCorp Vault в файловую систему Pod

 ls -a /deployments/config/db/certs/

Интеграция Шлюза БД с HashiCorp Vault для базы Oracle#

1. Для интеграции необходимо отредактировать Deployment, добавив следующие аннотации:

   Настройка Deployment для интеграции с HashiCorp Vault

   spec:
     template:
       metadata:
         labels:
           secman-injector: enabled                                        # включить sidecar HashiCorp Vault
         annotations:
           vault.hashicorp.com/agent-inject: 'true'                        # включить sidecar HashiCorp Vault
           vault.hashicorp.com/namespace: <NAMESPACE_VAULT>                # имя созданного хранилища в HashiCorp Vault (например, CI01994970_CI02129749)
           vault.hashicorp.com/role: <SECMAN_ROLE>                         # имя полученной роли в HashiCorp Vault (например, ci01994970_ci02129749_a_snps_osh_ift_ac)
           vault.hashicorp.com/secret-volume-path: <SECMAN_MOUNT_PATH>     # путь для загрузки секретов в файловой системе Pod (например, /deployments/config/db/certs)
           vault.hashicorp.com/agent-inject-secret-keystore.jks: 'true'    # включить чтение секрета keystore.jks
           vault.hashicorp.com/agent-inject-template-keystore.jks: |       # создается файл keystore.jks
             {{- with secret <SECRET_PATH> -}}                             # путь до секрета (например, CI01994970_CI02129749/A/SNPS/OSH/IFT/KV/JDBC)
             {{ base64Decode (index .Data "keystore.jks") }}               # значение из HashiCorp Vault по ключу keystore.jks, переведенное из base64
             {{- end }}
           vault.hashicorp.com/agent-inject-secret-truststore.jks: 'true'  # включить чтение секрета truststore.jks
           vault.hashicorp.com/agent-inject-template-truststore.jks: |     # создается файл truststore.jks
             {{- with secret <SECRET_PATH> -}}                             # путь до секрета (например, CI01994970_CI02129749/A/SNPS/OSH/IFT/KV/JDBC)
             {{ base64Decode (index .Data "truststore.jks") }}             # значение из HashiCorp Vault по ключу truststore.jks, переведенное из base64
             {{- end }}
           vault.hashicorp.com/agent-inject-secret-db-secret.yml: 'true'   # включить чтение секрета db-secret.yml
           vault.hashicorp.com/agent-inject-template-db-secret.yml: |      # создается файл db-secret.yml
             {{- with secret <SECRET_PATH> -}}                             # путь до секрета (например, CI01994970_CI02129749/A/SNPS/OSH/IFT/KV/JDBC)
             {{ index .Data "db-secret.yml" }}                             # значение из HashiCorp Vault по ключу db-secret.yml
             {{- end }}                    
       spec:
         volumes:
           - name: db-oracle-secman 										# новая ConfigMap со списком секретов, которые нужно ждать
             configMap:
               name: db-oracle-secman
               items:
                 - key: secman.txt
                   path: secman.txt
               defaultMode: 256
         containers:
           - volumeMounts:
               - name: db-oracle-secman 									# новая ConfigMap со списком секретов, которые нужно ждать
                 readOnly: true
                 mountPath: /tmp/secman/config
   

2. Добавить в ConfigMap, в котором прописываются настройки подключения к базе данных, пути до сертификатов:

ConfigMap с настройками подключения к базе данных

 kind: ConfigMap
 apiVersion: v1
 metadata:
   name: service-db-module-app-config
 data:
    application.yml: |-
       ...
       ds:
         prop:
           oracle:
             net:
               ssl_server_dn_match: true
               ssl_cipher_suites: (TLS_DHE_RSA_WITH_AES_256_GCM_SHA384)
               authentication_services: (TCPS)
           javax:
             net:
               ssl:
                 trustStore: /deployments/config/db/certs/ewallet.jks
                 trustStorePassword: password
                 trustStoreType: JKS
                 keyStore: /deployments/config/db/certs/ewallet.jks
                 keyStorePassword: password
                 keyPassword: password
                 keyStoreType: JKS

3. Добавить ConfigMap, в котором прописывается список файлов, загружаемых в Pod из HashiCorp Vault:

   ConfigMap со списком загружаемых файлов из HashiCorp Vault

  kind: ConfigMap
  apiVersion: v1
  metadata:
    name: db-oracle-secman
  data:
    secman.txt: |-
      /deployments/config/db/certs/ca.crt     							# указываем путь, который мы указали в аннотации vault.hashicorp.com/secret-volume-path
      /deployments/config/db/certs/cert.crt
      /deployments/config/db/certs/key.pk8
      /deployments/config/db/db-secret.yml

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

Пример проверки загрузки секретов из HashiCorp Vault в файловую систему Pod

ls -a /deployments/config/db/certs/

Ротация сертификатов#

Существует возможность включить механизм обновления сертификатов, полученных из HashiCorp Vault. Обновленные сертификаты и ключи монтируются в файловую систему шлюза БД и применяются в режиме runtime без прерывания основных функций шлюза БД. Для этого необходимо использовать PKI хранилище HashiCorp Vault, добавив аннотации в Deployment:

 annotations:
         vault.hashicorp.com/role: <SECMAN_ROLE>						# SECMAN_ROLE - роль в HashiCorp Vault
         vault.hashicorp.com/agent-init-first: 'true'					# запускать контейнер vault-agent первым
         vault.hashicorp.com/agent-pre-populate: 'false'					# отключение запуска init контейнера vault-agent
 		vault.hashicorp.com/secret-volume-path: /deployments/config/db		# путь, куда монтировать сертификаты и ключ
         vault.hashicorp.com/agent-inject-template-check-root.crt: >				# запрос на генерацию корневого сертификата
           {{- with secret "<SECRET_PATH>/PKI/issue/<SECMAN_ROLE>"				# SECRET_PATH - путь до хранилища PKI
           "common_name=<GENERATED_COMMON_NAME>" "format=pem"  "ttl=8760h"		        # установка GENERATED_COMMON_NAME - СN клиентского сертификата, формата сертификата, времени обновления сертификата в часах
           "private_key_format=pkcs8"  -}} {{ .Data.issuing_ca }}  {{- end }}	        # установка формата приватного ключа
         vault.hashicorp.com/agent-inject-template-check-cert.crt: >				# запрос на генерацию клиентского сертификата
           {{- with secret "<SECRET_PATH>/PKI/issue/<SECMAN_ROLE>"
           "common_name=<GENERATED_COMMON_NAME>" "format=pem"  "ttl=8760h"
           "private_key_format=pkcs8"  -}} {{ .Data.certificate }}  {{- end }}
         vault.hashicorp.com/agent-inject-template-check-key.pk8: >
           {{- with secret "<SECRET_PATH>/PKI/issue/<SECMAN_ROLE>"
           "common_name=<GENERATED_COMMON_NAME>" "format=pem"   "ttl=8760h"
           "private_key_format=pkcs8" -}} {{
            (index .Data.private_key)}}  {{- end }}
         vault.hashicorp.com/agent-inject-template-db-secret.yml: |				# запрос на получение файла с конфиденциальными данными из хранилища KV
           {{- with secret "<SECRET_PATH_KV>" -}}						# SECRET_PATH_KV - путь до хранилища KV
           {{base64Decode (index .Data "secret") }}								
           {{- end }}
         vault.hashicorp.com/agent-inject-secret-check-root.crt: 'true'
         vault.hashicorp.com/agent-inject-secret-check-cert.crt: 'true'
 		vault.hashicorp.com/agent-inject-secret-check-key.pk8: 'true'
         vault.hashicorp.com/agent-inject-secret-db-secret.yml: 'true'

Обновление#

Обновите все развернутые в окружении артефакты сервиса, кроме БД и информации в БД.

1. Перед обновлением требуется сохранить бэкап предыдущей конфигурации:

    kubectl get deployment service-db-module > depl.yml
    kubectl get service service-db-module > svc.yml
    kubectl get service empty-service > svc_empty.yml
    kubectl get se db-service-entry > se.yml
    kubectl get configmap service-db-module-app-config > cm_app.yml
    kubectl get configmap db-postgre-secman > cm_secman.yml
    kubectl get configmap service-db-module-entity-config > cm_ent.yml

2. Остановить Шлюз БД:

kubectl scale --replicas=0 deployment/service-db-module`

3. Удалить все предыдущие ресурсы шлюза:

    kubectl delete deployment service-db-module 
    kubectl delete service service-db-module 
    kubectl delete service empty-service 
    kubectl delete se db-service-entry 
    kubectl delete configmap service-db-module-app-config 
    kubectl delete configmap db-postgre-secman 
    kubectl delete configmap service-db-module-entity-config 

4. Провести установку новой версии компонента по инструкции из раздела Установка. Чтение процедур и функций из базы данных новой версии Шлюза БД начинается автоматически после его старта в Kubernetes.

Удаление#

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

1. Остановите шлюз:

С использованием веб-интерфейса

С использованием консоли

2. Удалите артефакты действующей версии:

С использованием веб-интерфейса

С использованием консоли

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

С использованием веб-интерфейса

С использованием консоли

Шаги проверки работоспособности платформенных зависимостей и модулей компонента

Откат#

1. Остановить Шлюз БД:

kubectl scale --replicas=0 deployment/service-db-module`

2. Удалить все предыдущие ресурсы адаптера:

    kubectl delete deployment service-db-module 
    kubectl delete service service-db-module 
    kubectl delete service empty-service 
    kubectl delete se db-service-entry 
    kubectl delete configmap service-db-module-app-config 
    kubectl delete configmap db-postgre-secman 
    kubectl delete configmap service-db-module-entity-config 

3. Провести установку бэкапа по инструкции из раздела Установка.

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

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

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

 kubectl get deployment service-db-module 
 kubectl get service service-db-module 
 kubectl get service empty-service 
 kubectl get se db-service-entry 
 kubectl get configmap service-db-module-app-config 
 kubectl get configmap db-postgre-secman 
 kubectl get configmap service-db-module-entity-config 

Все компоненты должны присутствовать в проекте и должна отсутствовать ошибка <<Error from server (NotFound)>>.

Чек-лист успешной настройки интеграции с платформенными зависимостями