В блоге CNCF представлен операционный рецепт построения стека управления секретами с открытым исходным кодом в Kubernetes, объединяющего OpenBao и CloudNativePG. OpenBao — это форк HashiCorp Vault с открытым исходным кодом под эгидой Linux Foundation, тогда как CloudNativePG превращает кластер PostgreSQL в самовосстанавливающийся сервис с синхронной репликацией и аутентификацией на основе сертификатов. Рецепт использует Kubernetes — выпускной проект CNCF — и CloudNativePG — проект в статусе Sandbox, который проходит оценку Техническим надзорным комитетом CNCF для перехода на этап Incubation.
Основная идея заключается не просто в использовании PostgreSQL в качестве обычного хранилища, а в том, чтобы OpenBao опирался на высокодоступный бэкенд PostgreSQL без зависимости от облачной базы данных, принадлежащей конкретному поставщику. Рецепт использует три экземпляра CloudNativePG с синхронной репликацией на основе кворума, так что для обеспечения устойчивости данных достаточно доступности одной синхронной резервной копии. В то же время операции записи могут остановиться, если доступной резервной копии, удовлетворяющей требованию по устойчивости, нет.
Что меняется в архитектуре?
OpenBao использует встроенное хранилище PostgreSQL с включённой таблицей блокировок высокой доступности посредством параметра ha_enabled = true. Конфигурация создаёт две таблицы: openbao_kv_store для хранения данных и openbao_ha_locks для хранения записей блокировок высокой доступности. Рецепт отключает локальное хранилище по умолчанию в схеме OpenBao, поскольку всё состояние должно находиться в CloudNativePG.
CloudNativePG запускает кластер PostgreSQL из трёх экземпляров, направляя их на выделенные узлы и обеспечивая распределение по отдельным доменам отказа с помощью селекторов узлов, допусков и ограничений межподового сродства. Рецепт использует каталог образов, задающий минимизированную версию PostgreSQL 18, вместо ручной записи фиксированного тега образа; также показан тестовый вариант с образом, защищённым SHA-отпечатком.
Аутентификация без паролей
Один из важнейших аспектов рецепта — удаление паролей из соединения OpenBao с базой данных. CloudNativePG создаёт объекты DatabaseRole для роли, владеющей схемой, и ограниченной операционной роли с именем openbao-rw; обе получают клиентский TLS-сертификат. Правила pg_hba требуют TLS-соединение и клиентский сертификат для этих ролей, одновременно отклоняя незашифрованные соединения.
Эта деталь важна, поскольку одно лишь создание сертификата не заставляет автоматически использовать его: именно правила PostgreSQL определяют для каждого соединения, будет ли аутентификация выполняться с помощью сертификата, пароля или соединение будет отклонено. Рецепт также устанавливает для смонтированных в контейнеры файлов секретов права 0640, поскольку библиотека libpq отклоняет закрытые ключи, доступные для чтения группе или всем пользователям, если они смонтированы со значением по умолчанию 0644.
Поскольку, согласно материалу, DatabaseRole пока не управляет выдачей разрешений на уровне таблиц, одноразовая задача Job выполняет команды создания таблиц и выдаёт ограниченной роли права SELECT, INSERT, UPDATE и DELETE. Задача также отзывает у PUBLIC право CONNECT и право использования публичной схемы, после чего повторно выдаёт минимально необходимые права openbao-rw. В конфигурации OpenBao включается параметр skip_create_table, чтобы ограниченная операционная роль не пыталась создавать таблицы самостоятельно.
Что это означает на практике для операторов Kubernetes?
Рецепт предлагает локальный путь тестирования с использованием репозитория cnpg-playground, который создаёт шестииузловой кластер Kind и содержит предварительно настроенные параметры CloudNativePG. Для эксперимента требуются Docker, Kind, Helm и kubectl. Однако распределение узлов в тестовой среде создаёт важное ограничение: выделенные и помеченные узлы PostgreSQL оставляют для размещения трёх реплик OpenBao с обязательным сродством только два общих узла. Поэтому рецепт временно разрешает OpenBao использовать узел плоскости управления в среде Kind, с явным предупреждением не переносить это послабление в производственную среду. В производственном кластере с тремя рабочими немаркированными узлами такая мера не требуется.
После установки схемы OpenBao необходимо инициализировать кластер и снять печать с каждого экземпляра по отдельности, используя три требуемых ключа Shamir из пяти. Снятие печати с первого экземпляра не снимает печать с двух остальных, а политика StatefulSet по умолчанию OrderedReady откладывает создание следующего экземпляра до готовности предыдущего. Поэтому ключи снятия печати и корневой токен следует хранить в безопасном месте, а затем вводить ключи для каждого экземпляра по порядку.
После инициализации OpenBao хранит состояние запуска и свои ключи в таблице openbao_kv_store, а значение тестового секрета сохраняется как зашифрованные данные типа BYTEA, а не в открытом виде, даже при прямом доступе к таблице PostgreSQL. Материал подтверждает успешное выполнение теста записи и чтения секрета с использованием KV v2 и ограниченной роли PostgreSQL.
Эксплуатационные ограничения и вопросы, не охваченные рецептом
CloudNativePG автоматически обновляет сертификаты: срок действия клиентского сертификата CNPG составляет 90 дней, и обычно он обновляется примерно за неделю до истечения. Однако OpenBao не перечитывает файлы сертификатов автоматически; интерфейс хранилища PostgreSQL открывает пул соединений при запуске процесса. Поэтому необходимо планировать поэтапный перезапуск экземпляров OpenBao после обновления, предпочтительно в рамках 83-дневного окна обновления до истечения срока действия старого сертификата.
Кроме того, высокая доступность внутри кластера Kubernetes не равна полноценному плану аварийного восстановления. Рецепт автоматически не создаёт резервные копии и не обеспечивает восстановление после полной потери кластера. Для производственного использования материал рекомендует добавить Barman Cloud Plugin с объектным хранилищем, таким как Amazon S3, Google Cloud Storage или Azure Blob Storage, и использовать ресурсы Backup и ScheduledBackup для архивирования WAL и базовых резервных копий, а также восстановления до определённого момента времени. Цели RTO и RPO, требующие пережить потерю целого кластера, предполагают наличие асинхронного кластера PostgreSQL во втором кластере или регионе.