Безопасность и автоматизация в экосистеме PostgreSQL
Декларативное управление ролями в Kubernetes через CloudNativePG 1.30.0
В конце июня 2026 года сообщество CloudNativePG представило новый стабильный релиз Kubernetes-оператора для СУБД PostgreSQL — версию 1.30.0. Одним из наиболее значимых нововведений стал переход к полностью декларативному управлению правами доступа и пользователями PostgreSQL с помощью нового пользовательского ресурса (Custom Resource Definition, CRD) под названием DatabaseRole.
Ранее роли пользователей описывались непосредственно внутри общей спецификации кластера в поле .spec.managed.roles. Это затрудняло управление доступом в рамках GitOps-пайплайнов, поскольку любые изменения прав требовали изменения конфигурации всего кластера. С введением DatabaseRole учетные записи становятся самостоятельными Kubernetes-объектами со своим жизненным циклом.
Пример описания роли в новом формате:
apiVersion: postgresql.cnpg.io/v1
kind: DatabaseRole
metadata:
name: application-developer
namespace: database
spec:
cluster: production-db
role: app_user
connectionLimit: 100
clientCertificate:
enabled: true
При установке флага clientCertificate.enabled: true оператор автоматически генерирует и своевременно продлевает клиентские TLS-сертификаты, подписывая их корневым центром сертификации кластера (Client CA), и сохраняет их в секрет вида <database-role-name>-client-cert. Это упрощает организацию защищенных беспарольных подключений к СУБД из приложений.
Алгоритмы выбора лидера: Защита от split-brain через Kubernetes Lease
Для повышения надежности в CloudNativePG 1.30.0 переработан алгоритм автоматического выбора лидера (primary promotion). Теперь процесс выбора основного узла координируется через механизм блокировок Kubernetes Lease API.
При возникновении аварии менеджер инстансов (instance manager) обязан захватить соответствующий Lease-объект в Kubernetes API, прежде чем объявить себя новым лидером (primary) и начать принимать запросы на запись. При штатном выключении узел добровольно освобождает блокировку. Временные параметры ожидания настраиваются в поле .spec.primaryLease. Данный подход минимизирует риски возникновения ситуации «раздвоения личности» (split-brain), когда при сбоях в сети два узла одновременно считают себя основными и начинают писать неконсистентные данные. При этом Lease выступает координационным шлюзом, но не заменяет собой аппаратные средства изоляции сбойных узлов (fencing).
Устранение уязвимостей безопасности в операторе
Релиз 1.30.0 содержит исправления ряда опасных уязвимостей в плоскости управления:
- Закрепление параметра
search_path(CVE-2026-55769) для предотвращения атак типа SQL-инъекция; - Безопасное кодирование паролей пользователей по стандарту SCRAM-SHA-256 (CVE-2026-55765);
- Усиление защиты межкомпонентного взаимодействия с помощью ECDSA-сертификатов (GHSA-7qwx-x8ff-3px9).
В связи с выходом новой ветки сообщество объявило о завершении поддержки (EOL) устаревших версий: поддержка ветки 1.28.x прекращена 30 июня 2026 года, а поддержка 1.29.x завершится 29 сентября 2026 года.
Ускорение инкрементальных представлений с pg_ivm 1.15
Расширение pg_ivm (Incremental View Maintenance) предоставляет механизм мгновенного обновления материализованных представлений (IMMV) с помощью триггеров AFTER. Вместо ресурсоемкой полной перезагрузки таблицы (REFRESH MATERIALIZED VIEW) pg_ivm рассчитывает дельту изменений при модификации таблиц-источников и точечно обновляет представление. Это снижает нагрузку на дисковую подсистему и процессор при обновлении аналитических панелей.
В обновлении pg_ivm 1.15 добавлена утилита pg_ivm_dump_metadata и вспомогательная функция restore_immv(). Они решают застарелую проблему несовместимости расширения со штатными средствами резервного копирования: ранее при миграции через pg_dump или обновлении версии СУБД с помощью pg_upgrade метаданные представлений ломались, из-за чего IMMV приходилось пересоздавать вручную. Теперь метаданные корректно экспортируются и восстанавливаются. Кроме того, исправлен баг, приводивший к некорректному расчету изменений, если одна таблица изменялась несколько раз внутри одного триггера.
Критическая уязвимость в pgJDBC 42.7.12: Угроза снижения защиты
В драйвере pgJDBC (официальном клиенте подключения к PostgreSQL для Java/JVM приложений) в версии 42.7.12 исправлена критическая уязвимость CVE-2026-54291, связанная с принудительным понижением протокола защиты (downgrade attack).
Проблема затрагивала приложения, настроенные на обязательное использование привязки каналов TLS (channel binding):
channelBinding=require
При определенных условиях злоумышленник, способный осуществлять перехват трафика (Man-in-the-Middle, MITM), мог незаметно перевести соединение с безопасного механизма SCRAM-SHA-256-PLUS (который сверяет цифровую подпись TLS-сертификата с данными канала связи) на обычный SCRAM-SHA-256 без проверки привязки канала.
Уязвимость возникала, если для шифрования использовался TLS-сертификат с алгоритмами подписи, не поддерживающими хэш привязки (например, Ed25519, Ed448 или экспериментальные постквантовые алгоритмы). В этом случае библиотека scram-client возвращала пустую привязку вместо генерации ошибки, а драйвер pgJDBC не проверял, был ли согласован именно механизм с привязкой, соглашаясь на plain-версию. Уязвимости подвержены версии драйвера с 42.7.4 по 42.7.11. Всем пользователям рекомендуется обновиться до версии 42.7.12.
Архитектурные выводы и чек-лист для инженеров баз данных
Развитие сопутствующих инструментов вокруг PostgreSQL показывает, что современная эксплуатация баз данных требует автоматизации рутины и защиты сетевого взаимодействия:
- Перейдите на декларативное описание прав: Примите формат
DatabaseRoleдля GitOps-управления ролями в Kubernetes; - Настройте автоматическое обновление TLS-сертификатов для клиентов баз данных;
- Проверьте настройки pg_dump при использовании расширения pg_ivm 1.15 для гарантии восстанавливаемости бэкапов;
- Обновите pgJDBC до версии 42.7.12 во всех Java-микросервисах, где требуется строгая MITM-защита соединения с СУБД.