OpenBao на Kubernetes с CloudNativePG вместо Vault

OpenBao на Kubernetes с CloudNativePG вместо Vault

OpenBao — открытый форк HashiCorp Vault, который развивает Linux Foundation. 16 сентября 2026 года CNCF опубликовала в блоге рецепт, как развернуть OpenBao на Kubernetes с PostgreSQL-кластером CloudNativePG вместо отдельного Raft- или Consul-хранилища. Авторы — Gabriele Bartolini из EnterpriseDB и Rob Kenefeck из ControlPlane, CNCF Ambassador.

Краткий ответ

OpenBao хранит секреты в PostgreSQL через встроенный postgresql storage backend, а CloudNativePG превращает этот кластер в синхронно реплицированную базу с mTLS-аутентификацией вместо паролей. Получается secrets management-стек из двух CNCF-проектов без выделенного Raft-кластера Vault и без привязки к лицензии одного вендора, но пока это опубликованный рецепт для тестирования, а не готовый план миграции продакшен-Vault.

Почему Vault стал тяжёлой зависимостью для платформенных команд

В практике платформенных команд, работающих с Kubernetes, Vault долгое время был основным выбором для хранения секретов. У такого выбора есть цена. Открытая версия Vault хранит данные во встроенном Raft-кластере либо во внешнем Consul — это ещё один consensus-стек, который команда обслуживает как отдельную критичную систему в проде. Коммерческая редакция, Vault Enterprise, отделена от открытого ядра; какие именно возможности доступны только в платной версии, стоит уточнять по актуальной документации HashiCorp, а не по устной репутации продукта.

Открытые альтернативы Vault обычно закрывают только часть этой проблемы: либо нет готовой интеграции с Kubernetes, либо настройка HA и аутентификации требует ручной сборки из разрозненных компонентов. OpenBao как форк под управлением Linux Foundation решает вопрос лицензии проекта, но архитектурная задача — на чём физически хранить секреты — остаётся открытой для команды.

Рецепт CNCF отвечает именно на этот вопрос: не создавать для secrets management отдельный тип хранилища, а переиспользовать Postgres-оператор, который у многих команд уже работает в кластере под прикладными базами.

Как устроена связка OpenBao и CloudNativePG

Авторы гайда описывают архитектуру так: postgresql storage backend OpenBao превращает Postgres-кластер в зашифрованное key-value хранилище, а CloudNativePG превращает этот кластер в самовосстанавливающуюся, синхронно реплицированную, аутентифицированную по сертификатам базу без зависимости от облачной СУБД.

В рецепте развёрнут трёхинстансный CNPG-кластер с кворумной синхронной репликацией (method: any, number: 1, режим durability required) — конфигурация с нулевой потерей данных при отказе. Для HA-блокировок самого OpenBao включён параметр ha_enabled = "true".

Рабочие нагрузки разнесены по выделенным узлам: node selectors, tolerations и обязательное зональное anti-affinity держат Postgres на отдельных узлах в разных доменах отказа, следуя рекомендациям CloudNativePG по планированию. Kubernetes в этой связке — давно перешедший в статус graduated проект CNCF, а CloudNativePG — Sandbox-проект, который сейчас проходит оценку Technical Oversight Committee для перехода в Incubation.

Матрица решений: где какой backend имеет смысл

Для команды, у которой CloudNativePG уже в проде под приложениями, третий вариант снижает число независимых систем хранения. Для команды без опыта Postgres-операторов он добавляет новую компетенцию вместо того, чтобы её убрать.

Случай 1: пароли исчезают из соединения полностью

Рецепт убирает пароли из подключения целиком. Роль-владелец схемы и прикладная роль, которую использует сам OpenBao, аутентифицируются через TLS-клиентский сертификат, выпущенный CRD DatabaseRole в блоке clientCertificate. Требование сертификата закреплено явными правилами pg_hba.conf — файла клиентской аутентификации PostgreSQL, который решает для каждого соединения, нужен ли роли сертификат, пароль или ничего.

Для security-команд это снимает классический риск утечки пароля из конфигурации или переменной окружения: сертификат управляется через Kubernetes CRD, а не хранится текстом в манифесте. Схема-init Job дополнительно закрывает default-открытость PostgreSQL: по умолчанию любая база даёт CONNECT роли PUBLIC, а схема public даёт USAGE той же PUBLIC, так что любая залогиненная в кластер роль могла бы заглянуть в базу OpenBao. Job явно отзывает эти права и выдаёт только то, что нужно роли openbao-rw.

Случай 2: локальный тест без облачной инфраструктуры

Проверить схему можно без внешнего кластера. Репозиторий cnpg-playground поднимает Kind-кластер из шести узлов: control plane, один узел для инфраструктурных нагрузок, один для прикладных и три с таинтом node-role.kubernetes.io/postgres — на них рецепт размещает CNPG-кластер, оставляя OpenBao только два узла общего назначения.

Развёртывание требует Docker, Kind, Helm и kubectl. Скрипт ./scripts/setup.sh openbao поднимает один локальный кластер, а REQUIREMENTS_ONLY=true ./demo/setup.sh разворачивает оператор CloudNativePG, cert-manager, плагин Barman Cloud и каталог образов, минуя демо-базы плейграунда. Кластер, роли и база создаются манифестом Cluster, который ссылается на каталог образов postgresql-minimal-trixie: CNPG сам разрешает его в актуальный минимальный образ PostgreSQL 18, так что повторный kubectl apply подхватывает новые патч-релизы без правки манифеста.

Случай 3: ротация сертификатов — деталь, которую легко упустить

Как отмечают авторы гайда CNCF, клиентские сертификаты CNPG живут 90 дней и обновляются автоматически примерно за неделю до истечения — по тому же расписанию, что и сертификат streaming_replica. Обновление подменяет содержимое секрета role-openbao-rw-client-cert без правки манифестов.

Но сам OpenBao этого не замечает. Как и Vault до него, postgresql storage backend открывает пул соединений один раз при старте процесса и больше не перечитывает файлы сертификата. Обновлённый сертификат вступает в силу только после rolling restart подов OpenBao. Это особенность жизненного цикла соединения самого storage-плагина, а не то, чем управляет реконсилиация сертификатов CNPG: задача CNPG заканчивается на поддержании актуального секрета. Как указано в том же материале, команде нужно закладывать плановый rolling restart внутри 83-дневного окна обновления, заранее до истечения старого сертификата.

Где эта схема может сломаться

Зрелость компонентов здесь неравномерна. Kubernetes — graduated-проект с многолетней практикой эксплуатации, а CloudNativePG всё ещё Sandbox-проект, ожидающий решения TOC по переходу в Incubation. Для критичных секретов статус Sandbox стоит держать в уме при выборе архитектуры, а не воспринимать его как готовый эквивалент зрелости Kubernetes.

Схема из гайда — это единичный Kubernetes-кластер. Настоящий disaster recovery требует большего: авторы отдельно упоминают, что для непрерывного архивирования WAL и Point-in-Time Recovery нужен Barman Cloud Plugin — как указано в том же материале, встроенный .spec.backup.barmanObjectStore CNPG задекларировала устаревшим в пользу плагина, — а для реальных RTO/RPO нужно распределять развёртывание CNPG между несколькими Kubernetes-кластерами через распределённую топологию с асинхронной репликой в другом регионе.

Сам гайд на момент публикации сфокусирован на первом шаге — развёртывании CNPG-кластера, ролей и базы. Интеграция OpenBao с Kubernetes auth и автоматизация выдачи секретов в опубликованном материале не расписаны, и команде придётся свериться с отдельной документацией OpenBao, прежде чем переносить продакшен-нагрузку.

Что проверить перед тем как менять Vault на OpenBao

Прежде чем переносить секреты, стоит закрыть несколько вопросов: срок и условия текущего контракта с HashiCorp, критичность SLA для secrets backend, готовность платформенной команды поддерживать Postgres-кластер как часть инфраструктуры секретов, а не только приложений, и наличие инструмента миграции существующих секретов из Vault — в опубликованном рецепте CNCF об этом шаге речи нет.

Отдельно проверьте, какой статус у CloudNativePG допускает политика вашей организации: если в критичный путь допускаются только graduated CNCF-проекты, Sandbox-статус CNPG может быть блокером до перехода в Incubation.

Заключение

Связка OpenBao и CloudNativePG показывает рабочий паттерн secrets management без отдельного Raft-кластера, собранный из компонентов, которые многие платформенные команды уже эксплуатируют. Платформенные команды получают вариант без вендорской лицензии на secrets backend, но зрелость именно этой комбинации, вероятно, пока ниже, чем у связки Vault с многолетней практикой эксплуатации, и решение стоит проверять на некритичных секретах, прежде чем переносить продакшен.

FAQ

Что такое OpenBao и кто его поддерживает?

OpenBao — открытый форк HashiCorp Vault, который развивает Linux Foundation. Проект сохраняет API и логику Vault, но развивается как community-проект вне контроля одного вендора.

Чем архитектура OpenBao с CloudNativePG отличается от Vault с Raft?

Vault и OpenBao по умолчанию хранят данные во встроенном Raft-хранилище — отдельном consensus-кластере, за которым нужно следить. Схема из гайда CNCF использует postgresql storage backend OpenBao и передаёт хранение PostgreSQL-кластеру под управлением CloudNativePG, с TLS-аутентификацией через pg_hba вместо паролей.

Можно ли протестировать эту схему локально?

Да, репозиторий cnpg-playground поднимает Kind-кластер из шести узлов с уже настроенным оператором CloudNativePG, cert-manager и Barman Cloud plugin, без облачной инфраструктуры.

Готова ли эта архитектура для критичных production-нагрузок?

Конфигурация из гайда рассчитана на прод-паттерны: три инстанса, кворумная синхронная репликация с нулевой потерей данных, зональное anti-affinity. Но CloudNativePG остаётся CNCF Sandbox-проектом на пути к Incubation, и это стоит учитывать при оценке риска для критичных секретов.

Нужно ли полностью отказываться от Vault, чтобы попробовать OpenBao?

Нет. Схему можно развернуть параллельно и протестировать на некритичных сервисах, прежде чем принимать решение о миграции продакшен-секретов.