OpenBao на VPS: временные пароли PostgreSQL для приложения

MAATRIX · 17 октября 2026 · 8 мин чтения

Пароль к базе однажды записали в файл окружения. Через год он находится в пяти копиях приложения, старом архиве, ноутбуке подрядчика и неизвестном числе журналов. Смена пароля выглядит простой только до вопроса: «А кто ещё им пользуется?»

OpenBao позволяет выдавать приложению отдельные учётные данные PostgreSQL с ограниченным сроком действия. Вместо одного общего вечного пользователя появляются временные роли, связанные с конкретной выдачей. Это помогает ограничить срок жизни секрета и управлять отзывом, но требует от приложения умения обновлять соединения.

Разберём учебный доступ только на чтение к отдельной базе. Эксперимент выполняется на тестовой среде. Подключать механизм к рабочей базе следует после проверки прав, отзыва и поведения пула соединений.

Откуда берётся временная роль

OpenBao подключается к PostgreSQL служебной учётной записью и выполняет разрешённый шаблон создания роли. Приложение проходит собственную аутентификацию в OpenBao, запрашивает доступ и получает имя пользователя, пароль и сведения об аренде — lease.

У аренды есть срок. При завершении или отзыве OpenBao выполняет предусмотренные действия для прекращения доступа. Это не означает, что любой уже открытый сеанс PostgreSQL мгновенно исчезнет. Поведение соединений и команды отзыва нужно проверить отдельно.

В архитектуре остаются важные секреты: служебный доступ OpenBao к базе, средства первоначальной настройки и способ аутентификации приложения. Их становится проще контролировать, но они не растворяются в облаке. Особенно опасно выдать приложению root-токен OpenBao: такой ход отменяет большую часть смысла проекта.

Принцип работы описан в документации database secrets engine. В этой статье мы используем отдельную роль чтения, чтобы временные пользователи не становились владельцами таблиц и не получали права изменять схему.

Подготовьте изолированный стенд

Нужны работающая установка OpenBao с постоянным защищённым хранилищем, TLS, завершённой инициализацией и настроенными политиками, а также тестовая PostgreSQL. Режим разработки OpenBao не подходит для постоянного размещения секретов.

Для пилота отдельного узла можно рассмотреть MAATRIX Uab Start: 2 vCPU и 4 GB памяти. Если база и тестовое приложение находятся рядом, Heka Standard с 8 GB даст больше пространства для эксперимента. Выбор зависит от состава стенда; один VPS при этом остаётся одной точкой отказа.

Используйте поддерживаемую Ubuntu или Debian, ограничьте сетевой доступ к API OpenBao и к PostgreSQL. Настройте синхронизацию времени: срок действия токенов и сертификатов зависит от часов. Сохраняйте резервные копии и предусмотренные средства восстановления отдельно, в защищённом порядке.

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

Разрешаем чтение конкретных таблиц

В учебной базе app создайте групповую роль без входа. Она будет содержать права, которые наследуют временные пользователи. Команды ниже выполняются администратором именно в тестовой базе:

CREATE ROLE app_readonly NOLOGIN;
GRANT CONNECT ON DATABASE app TO app_readonly;
GRANT USAGE ON SCHEMA public TO app_readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO app_readonly;

Это права на существующие таблицы. Для будущих таблиц задайте default privileges от имени их фактического владельца. Если миграции выполняют разные роли, настройка одной из них не распространяется волшебным образом на остальные.

Проверьте доступ обычным тестовым пользователем, которому назначена app_readonly: SELECT должен работать, INSERT и изменение схемы — завершаться отказом. Если данные разделяются между клиентами, дополнительно требуется подходящая модель строкового доступа. Общая роль чтения всей базы для этого недостаточна.

Создайте отдельную управляющую роль OpenBao с правами, необходимыми плагину для создания, выдачи членства и отзыва временных ролей. Не используйте без необходимости суперпользователя PostgreSQL. Набор полномочий зависит от версии PostgreSQL и команд плагина; проверьте его по документации PostgreSQL-плагина OpenBao.

Настраиваем соединение и шаблон выдачи

Включите database secrets engine в согласованном пути, например database. Если этот путь уже используется, сначала изучите существующую конфигурацию. Повторная настройка не должна нарушить другие приложения.

Создайте подключение appdb с плагином PostgreSQL, разрешённой ролью app-readonly и соединением, использующим подстановки {{username}} и {{password}}. Для TLS выбирайте проверку сертификата и имени сервера; обеспечьте доступ к доверенному корневому сертификату.

Настройки с паролем удобно передавать из защищённого JSON-файла через bao write database/config/appdb @connection.json. Содержание файла формируется по схеме вашей версии, а права ограничиваются владельцем. Не помещайте настоящий пароль в опубликованную команду, историю терминала или репозиторий.

Для тестовой роли сохраните в create-readonly.sql следующий шаблон:

CREATE ROLE "{{name}}" WITH LOGIN
  PASSWORD '{{password}}' VALID UNTIL '{{expiration}}';
GRANT app_readonly TO "{{name}}";

После проверки соединения создайте роль выдачи:

bao write database/roles/app-readonly \
  db_name=appdb \
  creation_statements=@create-readonly.sql \
  default_ttl=1h \
  max_ttl=4h

Это пример сроков для стенда. Рабочие значения выбирают по времени выполнения операций и способу обновления доступа. Слишком короткий срок без поддержки в приложении создаёт аварии чаще, чем пользу.

Получаем первую пару и проверяем ограничения

Запрос bao read database/creds/app-readonly выдаёт временные данные и идентификатор lease. Выполняйте его в защищённой среде: ответ содержит пароль. Не пересылайте вывод целиком в чат и не включайте его в обычный журнал отладки.

Подключитесь выданной ролью к тестовой базе, выполните чтение и убедитесь в запрете записи. Запишите технический ID аренды, время выдачи и ожидаемое окончание без сохранения открытого секрета в отчёте.

Теперь отзовите именно эту аренду предусмотренной командой bao lease revoke, подставив её реальный ID. Проверьте новое подключение и состояние уже открытого сеанса. Если отзыв завершился ошибкой, исследуйте права управляющей роли и зависимости пользователя.

Временная роль не должна становиться владельцем постоянных объектов. Иначе её удаление может столкнуться с зависимостями. Поэтому для приложения, которое пишет данные или выполняет миграции, модель прав и команды отзыва проектируются отдельно.

Пул соединений должен знать о смене пароля

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

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

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

Сбой выдачи пароля тоже проектируют

Приложение не должно превращать временную недоступность OpenBao в непрерывный поток запросов на новые учётные записи. Задайте ограниченные повторы с паузой и случайным разбросом, а также предел ожидания. Уже открытый рабочий пул иногда позволяет продолжить обслуживание, но рассчитывать на это как на бессрочный запасной вход нельзя: у соединений, аренды и самого приложения разные жизненные циклы.

Отдельно определите поведение при исчерпании пула. Понятное сообщение о временной недоступности лучше, чем бесконечно вращающийся индикатор и тысяча зависших запросов. Для фоновых задач заранее решите, допускается ли повторная обработка после восстановления доступа. Здесь помогает идентификатор операции, по которому база отличает повтор от новой заявки.

В мониторинге нужны количество неудачных выдач, время получения секрета и число соединений приложения. Сам пароль в метрики не попадает. На учебном стенде временно перекройте доступ к OpenBao и проверьте восстановление после снятия ограничения. Такой опыт показывает качество интеграции гораздо точнее, чем один удачный запрос с выданным паролем.

Политика приложения должна быть узкой

Выдайте приложению только право чтения согласованного пути database/creds/app-readonly и необходимые действия над собственным токеном по выбранной схеме. Оно не должно менять SQL-шаблон, создавать новые подключения или читать секреты соседней системы.

Способ входа приложения выбирайте под среду: машинная идентичность, поддерживаемый auth-метод и короткоживущие токены. Если применяется первоначальный секрет, защищайте его доставку и срок. Замена одного постоянного пароля базы на постоянный всесильный токен лишь переносит проблему.

Проверьте отрицательный сценарий: токен приложения пытается прочитать другой путь и изменить роль. Ожидается отказ. Такие проверки полезно повторять после изменений политик, потому что расширение прав часто происходит постепенно и без громкого объявления.

Проверка, после которой можно планировать рабочее внедрение

Стенд должен пережить повторную выдачу, истечение срока, явный отзыв, перезапуск OpenBao и временный разрыв связи с PostgreSQL. Для каждого случая зафиксируйте поведение приложения и способ восстановления.

Отдельно испытайте отказ PostgreSQL в момент отзыва: проверьте, что неудачная операция видна администратору и после восстановления связи доступ прекращается предусмотренным способом. Зафиксируйте, кто разбирает такие случаи. Журнал аудита помогает сопоставить аренду, приложение и действие; храните его защищённо и не превращайте сообщение об ошибке в публикацию пароля.

Переход выполняйте по одному приложению. Сохраните управляемый резервный путь на время внедрения, затем уберите прежний постоянный доступ после подтверждённой проверки. Не оставляйте старого пользователя бессрочно «на всякий случай».

Временные пароли полезны, когда срок доступа становится частью работы системы. Их ценность проявляется не в необычном имени пользователя, а в возможности объяснить: кто получил доступ, зачем, на какое время и как его прекратить. Именно эту цепочку стоит довести до конца на тестовом VPS прежде, чем доверять ей рабочую базу.