Comments 20
Осталось pg_hba.conf выкинуть, перенеся информацию в БД, и будет совсем хорошо.
trust и ident — исключить как класс, ибо небезопасно.
local peer — прибить гвоздями, всё остальное — через CREATE/ALTER USER/ROLE CONNECT FROM <откуда> BY/VIA и/или GRANT CONNECT TO INSTANCE FROM <откуда> TO BY/VIA .
По умолчанию разрешить подключаться локально (и сокет, и 127.0.0.1) по через SCRAM-SHA-256.
PUBLIC-у по-умолчанию никаких грантов на подключение.
Очевидный встречный вопрос от сообщества будет, а как сделать разные настройки для реплик (для начала «как» на уровне описания желаемого поведения). Это явный usecase, для, например, аналитической реплики с прямым доступом для сотрудников, но в то же время не пускать их на мастер. Да, можно через firewall отпилить доступ, но обосновать целесообразность ломания поведения правил доступа надо будет.
Да, с доступом только к реплике — это вопрос.
В рамках предлагаемого переноса видится такое решение:
INSTANCE использовать для доступа и к мастеру, и к репликам;
MASTER/REPLICA в TO использовать для ограничения только к мастеру (пока непонятно для зачем ограничивать только к мастеру, но мало ли) и реплике.
Запросы, соответственно, выполняются на мастере.
Для определения мастера/реплики использовать pg_is_in_recovery().
А вот придти с таким proposal к какому-то консенсусу — задача нетривиальная и я думаю будут противники поактивнее, чем для отпиливания recovery.conf. Пачка настроек вне GUC сообщество не устраивала уже не первый год, а вот про hba как-то не уверен.
Если кто почувствует в себе силы — настоятельно рекомендую сначала написать proposal в pgsql-hackers и только потом начинать сооружать патч. И разделить proposal на 3 разных: соответственно под спиливание trust/ident, не выдавать connect всем при создании базы, собственно замена pg_hba.
Там есть два варианта — full backup / copy cluster или репликация, так вот в первом случае переносится вся база, включая гранты, а во втором случае переносятся только структура таблиц и данные, соответсвенно легко можно назначить разные права на master/replica.
Думаю такое же поведение можно продумать и для PostgreSQL — сделать два режима репликации — с переносом прав (системных таблиц) или нет.
Или же сделать еще проще и дать возможность исключать таблицы (она есть в логической репликации же) и соответственно по дефолту включить таблицы отвечающие за права в blacklist
p.s. но я не возьмусь даже за proposal, не то что за реализацию, к сожалению(((
Здесь можно много писать об их различиях, но и у того и у другого подхода есть как плюсы, так и ограничения. И против выбрасывания физической репликации я буду возражать очень сильно — она проста, надёжна и не требовательна ни к CPU ни к памяти. Взять страничку, записать страничку. Ну, ладно, чуть сложнее на самом деле из-за обработки конфликтов репликации. Но до сложностей логической репликации очень далеко. А игнорировать в физической репликации часть таблиц нельзя. И даже если сделать можно (против чего опять же даже я буду сильно возражать) — то проблем от этого добавится много. В частности, что делать с durability этой таблицы, раз её нет в wal (реплика свои wal писать не может и не должна).
В таком случае WAL писать не нужно, как и ломать физическую репликацию, достаточно добавить ключ, вроде того — синхронизировать гранты или нет
Я бы тоже сильно возражал против изменения текущей схемы физической репликации, но её и не нужно ломать, просто заменить HAL на что-то более удобное и гибкое
Пример: www.vertica.com/docs/9.1.x/HTML/index.htm#Authoring/SQLReferenceManual/SystemTables/CATALOG/GRANTS.htm — весь Catalog хранится в datapath, но он отделен от данных, то есть таплы для grants можно копировать (fullbackup), а можно и не копировать
В таком случае WAL писать не нужно
Как их восстанавливать при сбое? Важно: согласованно с состоянием системного каталога и, особенно теми несколькими shared relations, например как раз pg_authid.
Сейчас все системные таблицы обязательно WAL-logged.
Они специальные, дополнительно защищены, ряд таблиц запинен даже в private memory каждого backend'а, а не только в shared_buffers.
Как делать rollback?
С внешним pg_hba.conf прячем голову в песок, это конфигурация, СУБД его читает при старте/reload, в остальное время он неважен и обязанность админа за ним следить, как и за основным конфигом. На уровне SQL это уже будет обязанность базы. Вы замечали, что даже postgresql.auto.conf пишется во временный файл и затем подменяет старый с fsync?
Тем более важно по той причине, что без postgresql.auto.conf работать можно, а вот без правил авторизации — уже нет, вы и подключиться к базе не сможете, чтобы перебить руками grant connect from из бекапа.
При создании сессии пользователя или даже при попытке выполнения SQL мы проверяем в системной таблице в памяти — имеет ли он на это право, если да — генерируем исключение, если нет — выполняем его SQL
Зачем тут атомарность? Мы просто заменим правку HAL + релоад на механизм хранения этих данных «рядом» с данными в БД
Ну не записали мы grant — свет выключили — во-первых у нас есть юзер postgres с полными правами (кстати в упомянутой Vertica есть dbadmin, он как root в Linux внутри БД) и мы можем накатить грантов после того как сервер оживет. Вариантов с непустой БД и отсутствием прав на нее для некоего админа представить сложно
А если так получилось, что ему нужен сетевой доступ? Или, наоборот, хотим дать ему доступ только через unixsock? Дефолтом это сделать нельзя, unixsock существует не на всех поддерживаемых платформах.
Гранты на выполнение запросов и на доступ к объектам внутри конкретной базы есть и они обязаны быть транзакционными и wal-logged, об этом речи нет.
У них есть superuser, который просто системный пользователь и у него всегда тип авторизации только пароль, при этом он рекомендуется к использованию только для запуска/остановки базы, бэкапов и других сервисных функций + давать права pseudosuperuser'ам. При этом у него есть сетевой доступ
А вот как раз pseudosuperuser это уже роль и она хранится в самой БД и соответственно делегируется другим пользователям через GRANT pseudosuperuser TO username;
То есть тут четко разделяется сервисный уровень и уровень доступа к данным
При этом реализуется полная и частичная репликация на WAL уровне, т.к. просто объекты (страницы) принадлежащие конкретным схемам, таблицам и т.д. копирутся просто как файлы, а каталог формируется в виду снапшота (каталог описывает какой логической сущности какие файлы/страницы соответствуют)
Правда стоит отметить, что все-таки Вертика не реляционная база, хоть и ACID
UDP: ну да и у них нет авторизации типа ident и access
Осталось pg_hba.conf выкинуть
А что плохого в этом файлике. С применением параметров проблем нет, и ничего из вне не сможет добавить лишних доступов. ИМХО очень полезный файлик местами.
Правила доступа непосредственно в базе рядом с самими пользователями имеют как преимущества (хотя бы не надо конфиг перезагружать, что не проблема, но надо помнить об этом и, что более важно, проверять по логу, успешно ли загрузился конфиг или где опечатались — популярная ошибка указать IP без маски сети), так и недостатки.
И вот поскольку pg_hba.conf есть уже — то любому, кому этот конфиг не нравится, придётся как раз описывать его недостатки и преимущества переноса правил в саму базу.
ничего из вне не сможет добавить лишних доступов
Вот, тоже полезная точка зрения.
А вот ограничить в использовании trust и не давать connect права всем на новую базу — это я бы поддержал.
Простите, я сломал ваш recovery.conf