Настройка интеграции с системой управления секретами в окружении Platform V Backend#

HashiCorp Vault используется для управления следующими секретами:

• сертификатами для обработки входящих и исходящих запросов с mTLS (ingress / egress);

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

• учетными данными для подключения к БД;

• сертификатами для mTLS подключения к OTT;

• сертификатами для mTLS подключения к Kafka компонента журналирования.

Потребители

В случае интеграции с HashiCorp Vault потребуется:

• установленный и настроенный HashiCorp Vault;

• установленный и настроенный HashiCorp Vault Agent Injector в среде контейнеризации Kubernetes или Openshift;

• получить необходимые привилегии для управления в HashiCorp Vault;

  Необходимо учесть, что injector при запуске подхватывает значения runAsUser/runAsGroup из первого поднятого контейнера. В случае получения ошибки 403 на доступ к файлам секретов, требуется установить значение параметра holdApplicationUntilProxyStarts в false

• подготовить секреты в зависимости от выбранного engine;

• настроить возможность аутентификации Vault Agent из namespace DCGN среды контейнеризации Kubernetes или Openshift;

• внести изменения в конфигурацию DCGN для настройки параметров интеграции;

• если ранее был установлен DCGN без интеграции с системой управления секретами, то перед установкой необходимо очистить namespace от ранее созданных секретов.

Примечание. Для удаления секретов из namespace можно использовать playbook OPENSHIFT_DEL_RES Security job компонента Deploy Tools. Необходимо настроить файл openshift_del_res.conf на удаление секретов из проекта DCGN, пример:

openshift_del_res.project.1.cluster = none
openshift_del_res.project.1.projects = project_DCGN
# удаление secrets
openshift_del_res.delete.projects.secrets = on

Подробнее о работе и настройке job читайте в документации компонента Deploy Tools.

Настройки для конфигурации#

Для выпуска сертификатов с использованием engine PKI, путь к сертификатам задается в виде <pki_path>/issue/<role> <parameters>, где:

• pki_path – путь до engine PKI;

• role – имя роли;

• parameters – список параметров разделенные пробелом, указываются парой ключ=значение.

Примеры:

dcgn.vault.secret.ingress.certs.path=pki/issue/dcgn common_name=<hostname> format=pem ttl=12h
dcgn.vault.secret.db.postgres.certs.path=pki/issue/dcgn common_name=<имя пользователя> format=pem

В DCGN поддерживается конфигурация engine секретов kv и pki, но по умолчанию поставляется конфигурация для engine pki. Чтобы изменить engine в конфигурации необходимо для каждого path параметра секрета сменить формат pki на kv.

Например:

dcgn.vault.secret.db.postgres.certs.path={{ lookup('custom_vars', 'dcgn.vault.secret.pki.baseEngineMountPath') }}{{ lookup('custom_vars', 'dcgn.ose.configmap.vault.hashicorp.com.secret.engine.pki.name') }}fetch/{{ lookup('custom_vars', 'dcgn.ose.configmap.vault.hashicorp.com.secret.engine.pki.client.role') }} common_name={{ lookup('custom_vars', 'dcgn.ose.configmap.certificate.client.cn') }} format=pem

изменить на:

dcgn.vault.secret.db.postgres.certs.path={{ lookup('custom_vars', 'dcgn.vault.secret.kv.baseEngineMountPath') }}KV/db/certs

Требования и рекомендации при использовании engine секретов: kv, pki, database#

Не рекомендован к использованию engine Database Engine (database).

Использование KV Engine (kv)#

Хранение сертификатов

При использовании KV для хранения сертификатов, секрет должен содержать следующие ключи:

Сертификаты должны быть представлены в PEM формате.

Пример содержимого секрета с сертификатами:

{
   "ca_chain": [
      "-----BEGIN CERTIFICATE-----\nMIIEjjCCA...\n-----END CERTIFICATE-----",
      "-----BEGIN CERTIFICATE-----\nMIIDMjCCA...\n-----END CERTIFICATE-----"
   ],
   "certificate": "-----BEGIN CERTIFICATE-----\nMIIFszCC...\n-----END CERTIFICATE-----",
   "issuing_ca": "-----BEGIN CERTIFICATE-----\nMIIEjjCCA...\n-----END CERTIFICATE-----",
   "private_key": "-----BEGIN PRIVATE KEY-----\nMIIEvAIBA...\n-----END PRIVATE KEY-----"
}

Хранение учетной записи БД

При использовании KV для хранения учетной записи БД, секрет должен содержать следующие ключи:

Пример содержимого секрета с учетной записью:

{
    "username": "dcgn_dev",
    "password": "password"
}

Примечание. По умолчанию Vault Agent с периодичностью в 5 минут запрашивает секрет. Изменить поведение можно добавив специальный ключ ttl – время жизни секрета, тогда Vault Agent будет запрашивать его при достижении 85% от указанного ttl. Пример значения: 10.5(s|m|h|d), где s – секунды, m – минуты, h – часы, d – дни, дробная часть опциональна. Если не указана единица измерения времени, то значение интерпретируется в секундах.

Автоматизация применения секретов#

В DCGN реализован механизм автоматического обновления секретов, без перезапуска и без недоступности приложений. Во время работы приложения (runtime) происходит отслеживание изменения в файлах на файловой системе и по факту изменений выполняется перезапуск ресурсов приложения. Механизм автоматической ротации секретов можно отключить через параметр dcgn.secret.hotreload.enabled при старте приложения.

DCGN корректно обрабатывает ситуацию изменения секретов сразу в нескольких (или во всех) pod, не допуская ситуации одновременного обновления и применения секретов во всех приложениях. Для обеспечения плавности обновления секретов между репликами одного приложения (pod), обновление выполняется с задержкой рассчитываемой по формуле: hotreload.timeLowerBound + |(hotreload.timeUpperBound - hotreload.timeLowerBound) * sin(x)|, где:

• hotreload.timeLowerBound – нижняя граница времени применения секрета (раньше этого времени применение секрета не начнется);

• hotreload.timeUpperBound – верхняя граница времени применения секрета (позже этого времени применение секрета не начнется);

• x – случайное значение, генерируемое при старте приложения.

Общие настройки#

Примечание. Стратегия применения секретов реализована для секретов Базы данных DCGN. Возможные значения FAIL_FAST/FAIL_SAFE. При стратегии FAIL_SAFE приложение во время выполнения будет использовать старые секреты, если обновление секретов завершилось с ошибкой.

Ограничения#

Бесшовная ротация обеспечивается только при условии некоторого grace-периода смены секретов, при котором доступны старый и новый секреты.

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

Секрет на сервис-провайдере ротируется раньше, чем на стороне клиента, например, на стороне ОТТ-сервера и в sidecars ОТТ. Предполагается, что это обеспечивается системой управления секретами или организационными мерами.

Применение сертификатов для установки mTLS-соединения с PostgreSQL выполняется автоматически средствами HikariCP и не подпадает под требование отключения.

Аутентификации по ТУЗ#

Для успешного обновления secret ТУЗ для подключения к СУБД требуется одновременное обновление ТУЗ в экземпляре СУБД, Secret Management System и в приложении. Ошибки аутентификации могут появится для новых соединений, которые создает пул со старым secret (но когда в экземпляр СУБД уже обновился ТУЗ), либо с новым secret (но когда экземпляр СУБД еще не обновил ТУЗ). Чтобы исключить такие ошибки, рекомендуется обеспечить период отсрочки (grace period) для отключаемого ТУЗ. Для этого нужно выполнить следующие шаги:

1. Ротация секрета на стороне Secret Management System типа логин/пароль, используемого для аутентификации в СУБД, производится администраторами путем замены ТУЗ в KV Engine:

   • Создаются две ТУЗ с пересекающимися сроками действия пароля (grace period - пересечение сроков действия паролей, когда действуют обе ТУЗ. Используется для плавной замены ТУЗ).

   • В KV Secrets Engine указываются логин, пароль и срок действия (TTL) первой ТУЗ.

2. При наступлении grace period в KV Secrets Engine указываются логин, пароль и срок действия (TTL) второй ТУЗ (в этот момент могут использоваться обе ТУЗ).

3. Далее ТУЗ меняются с предварительной сменой пароля.

4. Для смены пароля ТУЗ можно настроить использование статических ролей Database Secrets Engine:

   • Для каждой ТУЗ создается статическая роль.

   • Для роли настраивается политика генерации паролей.

   • Для смены пароля ТУЗ выполняется операция ротации, которая генерирует новый пароль и обновляет его в СУБД для ТУЗ.

5. После выполнения операции ротации логин, новый пароль и срок действия пароля (TTL) ТУЗ указываются в KV Secrets Engine.

Примечание.

Для исключения проблем при обновлении secret ТУЗ СУБД рекомендуется отказаться от аутентификации через ТУЗ и перейти на аутентификацию по сертификату.