Управление секретами — одна из наиболее критичных задач в корпоративной ИТ-инфраструктуре. От того, насколько надежно и централизованно хранятся ключи API, пароли, токены и сертификаты, зависит не только безопасность сервисов, но и устойчивость всего бизнеса.
С ростом популярности отечественных решений особое внимание уделяется возможности интеграции с российскими СУБД. В этом материале команда «Онланты» делится опытом тестирования StarVault — системы управления секретами — в связке с Postgres Pro в лабораторных условиях.
Цель эксперимента — проверить, насколько Postgres Pro подходит для использования в качестве внешнего хранилища StarVault, оценить производительность и устойчивость конфигурации, а также проработать сценарии аварийного восстановления.
Описание инфраструктуры
Для проведения испытаний была развернута тестовая инфраструктура, включающая два экземпляра StarVault, различающихся типом хранилища данных. Первый экземпляр использует выделенное хранилище на базе Postgres Pro, второй — встроенное Raft-хранилище, применяемое для сравнительного анализа производительности и стабильности системы.
Оба экземпляра работали в Standalone-конфигурации без настройки отказоустойчивости, что позволило сфокусироваться на чистых метриках взаимодействия компонентов. Все серверы функционировали в среде виртуализации zVirt под управлением Astra Linux Special Edition 1.8.1.UU1 (Орел) с установленной версией StarVault 1.0.4.
Каждый узел тестовой среды имел по 4 виртуальных процессорных ядра и 16 ГБ оперативной памяти, а также дисковую подсистему с производительностью не ниже 3000 IOPS при случайной записи. Для сетевого взаимодействия использовались интерфейсы 1 Гбит/с. Один сервер выполнял роль базы данных Postgres Pro, другой — экземпляра StarVault с внешним хранилищем, третий — StarVault с интегрированным Raft-хранилищем.
Методика и результаты тестирования производительности
Для оценки производительности StarVault применялась утилита HashiCorp Vault Benchmark, позволяющая моделировать нагрузку на систему при работе с различными механизмами управления секретами — от аутентификации (AppRole, UserPass) до операций с KV-хранилищами, шифрованием (Transit) и выпуском сертификатов (PKI).
Тестирование проводилось с помощью утилиты на выделенном сервере и включало три этапа.
Быстрые базовые тесты на запись и чтение (по 3 минуты), оценивающие реакцию системы при массовых операциях с KV-секретами.
Комплексный сценарий длительностью 30 минут, объединяющий все типы операций — аутентификацию, чтение и запись данных, шифрование, верификацию и генерацию сертификатов.
Сравнение выполнялось для двух экземпляров StarVault: одного с хранилищем на Postgres Pro, другого — с интегрированным Raft-хранилищем.
Перечень используемых сценариев тестирования утилиты Vault Benchmark
approle_auth: тест проверки производительности входа в систему с использованием метода Approle Auth. Подробное описание параметров конфигурации теста доступно по ссылке: https://github.com/hashicorp/vault-benchmark/blob/main/docs/tests/auth-approle.md
userpass_auth: тест проверки производительности входа в систему с использованием метода Userpass Auth. Подробное описание параметров конфигурации теста доступно по ссылке: https://github.com/hashicorp/vault-benchmark/blob/main/docs/tests/auth-userpass.md
kvv2_read, kvv2_write: тесты для проверки производительности механизма KVV2 (генерация, хранение и чтение произвольных секретов-ключей). Подробное описание параметров конфигурации теста доступно по ссылке: https://github.com/hashicorp/vault-benchmark/blob/main/docs/tests/secret-kv.md
transit_encrypt, transit_decrypt, transit_verify: тесты для проверки производительности механизма Transit (возможность шифрования и дешифровки данных). Подробное описание параметров конфигурации теста доступно по ссылке: https://github.com/hashicorp/vault-benchmark/blob/main/docs/tests/secret-transit.md
pki_issue: тест для проверки производительности мехнизма PKI (выпуск сертификатов X.509). Подробное описание параметров конфигурации теста доступно по ссылке: https://github.com/hashicorp/vault-benchmark/blob/main/docs/tests/secret-pki-issue.md
Результаты показали стабильную работу StarVault с Postgres Pro, без функциональных отклонений от классической конфигурации PostgreSQL. При этом вариант с Raft-хранилищем продемонстрировал более высокую производительность:
в среднем на 20–25% быстрее в комплексных сценариях,
и до трех раз быстрее при выполнении операций на запись.
Конфигурация Postgres Pro использовалась без дополнительного тюнинга; предполагается, что оптимизация параметров СУБД способна повысить ее производительность в последующих испытаниях.
Результаты производительности
Утилизация ресурсов во время комплексных тестов
Во время комплексных тестов также производился замер утилизации системных ресурсов (память, процессор, диск). Ниже представлены данные по утилизации.
Сервер SV01
CPU
Процент загрузки CPU
Оперативная память
Свободная оперативная память (в Гб)
Дисковая подсистема
Использование диска (в Мебибайт/сек)
Использование диска (операций в секунду)
Сервер DB01
CPU
Процент загрузки CPU
Оперативная память
Свободная оперативная память (в Гб)
Дисковая подсистема
Использование диска (в Мебибайт/сек)
Использование диска (тысяч операций в секунду)
Сервер SV03
CPU
Процент загрузки CPU
Оперативная память
Свободная оперативная память (в Гб)
Дисковая подсистема
Использование диска (в Мебибайт/сек)
Использование диска (тысяч операций в секунду)
Сценарии отказов и планы восстановления
Для оценки устойчивости системы были рассмотрены типовые сценарии инцидентов, разделенные на две группы — в зависимости от архитектуры StarVault.
StarVault с интегрированным локальным хранилищем Raft;
StarVault с выделенным хранилищем на базе PostgreSQL / Postgres Pro.
1. Сценарии для конфигурации с Raft-хранилищем
Тестировались три варианта отказа:
полный выход из строя сервера с доступной резервной копией виртуальной машины;
отказ при наличии только копий конфигурационного файла и данных хранилища;
отказ при наличии лишь резервной копии хранилища.
Во всех случаях процедура восстановления была успешной. Самый сложный случай (отказ при наличии лишь резервной копии хранилища) включал установку нового сервера, развертывание StarVault требуемой версии, ручное восстановление конфигурации и сертификатов, восстановление данных хранилища из резервных копий, проверку состояния сервиса и последующее «распечатывание» хранилища (unseal) через CLI или web-интерфейс. С подробным порядком действий можно ознакомиться ниже.
1. Установить новый сервер StarVault с таким же именем и IP-адресом.
2. Выполнить инсталляцию StarVault (с такой же версией, как у вышедшего из строя сервера) из репозитория или локального пакета.
3. Создать файл конфигурации в стандартной директории /etc/starvault.d/starvault.hcl. Убедиться, что у пользователя starvault имеется доступ на чтение и запись конфигурационного файла. Пример конфигурационного файла:
ui = true
cluster_addr = "https://<starvault_ip>:8201"
api_addr = "https://<starvault_ip>:8200"
disable_mlock = true
storage "raft" {
path = "/path/to/raft/data"
node_id = "raft_node_id"
}
listener "tcp" {
address = "<starvault_ip>:8200"
tls_cert_file = "/path/to/full-chain.pem"
tls_key_file = "/path/to/private-key.pem"
}4. Перенести файлы сертификата и файлы хранилища в соответствующие директории (указаны в конфигурационном файле). Убедиться, что у пользователя starvault имеется доступ на чтение и запись к файлам.
5. Если используются сертификаты, выпущенные локальным центром сертификации, тогда в операционной системе требуется выполнить импорт необходимых корневых/промежуточных сертификатов.
6. Выполнить запуск сервиса StarVault:
systemctl enable starvault.serviceВ случае проблем с запуском службы – отследить и устранить ошибки запуска сервиса:
journalctl -eu starvault.service
7. Проверить статус службы StarVault командой starvault status:
Key Value
--- -----
Seal Type shamir
Initialized true
Sealed true
Total Shares 5
Threshold 3
Unseal Progress 0/3
Unseal Nonce n/a
Version 1.0.4
Build Date 2025-03-14T20:50:17Z
Storage Type file
HA Enabled falseВ статусе отображается, что служба инициализирована, а хранилище запечатано.
8. Провести процедуру распечатывания хранилища.
Через Cli:
Последовательно ввести необходимое количество ключей для распечатывания хранилища с помощью команды:
starvault operator unsealПосле успешного распечатывания будет выведен статус службы StarVault.
Key Value
--- -----
Seal Type shamir
Initialized true
Sealed false
Total Shares 5
Threshold 3
Version 1.0.4
Build Date 2025-03-14T20:50:17Z
Storage Type file
Cluster Name vault-cluster-37c1a3ef
Cluster ID 8acadd3b-107b-c17a-2232-68eb8f04b65e
HA Enabled falseВ статусе отображается, что служба инициализирована и хранилище распечатано.
Через Web:
o В браузере открыть веб-страницу StarVault (например, https://<FQDN>:8200) и ввести ключи для распечатывания хранилища.
9. Включить автоматический запуск службы StarVault
systemctl enable starvault.service2. Сценарии для конфигурации с PostgreSQL / Postgres Pro
Для конфигурации с внешним хранилищем были проработаны более детализированные сценарии, охватывающие как отказ основного сервера StarVault, так и выход из строя сервера базы данных. Рассматривались варианты с полными и частичными резервными копиями.
Восстановление сервиса включает следующие основные шаги:
развертывание/восстановление экземпляра StarVault и/или Postgres Pro с исходными параметрами (имя, IP-адрес, версия ПО);
восстановление конфигурационных файлов, сертификатов и данных хранилища;
запуск и проверку статуса сервиса.
Для серверов с полной резервной копией восстановление проходило автоматически; при частичных копиях требовалась ручная настройка параметров и импорт данных. При отсутствии резервных копий сервера и базы данных порядок действий был следующим.
1. Установить новый сервер PostgreSQL\Postgres Pro с таким же именем и IP-адресом.
2. Выполнить инсталляцию PostgreSQL\Postgres Pro.
3. Создать пользователя, базу данных и назначить необходимые разрешения. Пример:
sudo -u postgres psql
CREATE USER vaultuser WITH PASSWORD 'StrongPasswordHere';
CREATE DATABASE vaultdb OWNER vaultuser;
GRANT ALL PRIVILEGES ON DATABASE vaultdb TO vaultuser;4. В файле “pg_hba.conf” предоставить разрешение на подключение к базе для пользователя с сервера StarVault:
host vaultdb vaultuser <starvault_ip>/32 md55. Перезапустить службу PostgreSQL\Postgres Pro, проверить журнал на наличие ошибок.
6. Проверить возможность подключения к базе пользователя:
psql -U vaultuser -d vaultdb7. На сервере StarVault проверить возможность подключения к СУБД:
nc -zv <database ip> <database port>
или
telnet <database ip> <database port>8. На сервере StarVault перезапустить службу StarVault. Посмотреть журнал службы и убедиться, что пропали ошибки подключения к хранилищу. Пример ошибки:
[ERROR] auth.approle.auth_approle_1492e257.tidy: error tidying global secret IDs: error="failed to connect to host=10.0.8.197 user=vaultuser database=vaultdb: dial error (dial tcp 10.0.8.197:5432: connect: connection refused)"9. Провести процедуру распечатывания хранилища.
Через Cli:
Последовательно ввести необходимое количество ключей для распечатывания хранилища с помощью команды:
starvault operator unsealПосле успешного распечатывания будет выведен статус службы StarVault.
Key Value
--- -----
Seal Type shamir
Initialized true
Sealed false
Total Shares 5
Threshold 3
Version 1.0.4
Build Date 2025-03-14T20:50:17Z
Storage Type postgresql
Cluster Name vault-cluster-e39e2ae3
Cluster ID 0da342ad-5e4c-c7ea-8ff2-b1e109b27cb5
HA Enabled falseВ статусе отображается, что служба инициализирована и хранилище распечатано.
Через Web:
В браузере открыть веб-страницу StarVault (например, https://<FQDN>:8200) и ввести ключи для распечатывания хранилища.
Результаты тестирования подтвердили, что обе конфигурации StarVault обладают высокой предсказуемостью при восстановлении после отказа.
Вариант с Raft-хранилищем обеспечивает более простое и быстрое восстановление за счет встроенного механизма хранения.
Конфигурация с Postgres Pro требует большего числа действий, но обеспечивает гибкость и масштабируемость, характерные для классических СУБД.
Вывод
Результаты испытаний показали, что связка StarVault + Postgres Pro является технологически состоятельным и безопасным решением для управления секретами в корпоративной инфраструктуре. Использование Postgres Pro в качестве внешнего хранилища обеспечивает стабильность, совместимость и предсказуемость поведения системы при рабочих нагрузках, а также полностью соответствует требованиям по технологическому суверенитету.
При этом встроенное Raft-хранилище продемонстрировало преимущество в производительности и простоте восстановления, что делает его подходящим вариантом для компактных и автономных развертываний. Конфигурация с Postgres Pro, напротив, лучше адаптируется под крупные инфраструктуры, где критичны масштабирование, аудит и централизованное управление данными.