Сценарии администрирования#

Администрирование Platform V Pangolin осуществляется средствами, которые описаны в этом разделе.

Реализация АРМ администратора#

Для администрирования системы используется утилита psql. Эта утилита представляет собой терминальный клиент для передачи запросов к СУБД и отображения результатов.

psql [параметр...] [имя_бд [имя_пользователя]]

Примечание:

Решение по обеспечению безопасности АРМ администратора должно исходить из окружения конечной АС.

Получение информации об используемой версии#

В данном разделе приведены примеры команд для получения используемой версии продукта Platform V Pangolin. Примеры команд не отличаются для ОС Альт 8 СП и Rad Hat.

Для клиентской части#

Чтобы получить название и версию клиентской части продукта Platform V Pangolin, запустите любую команду с ключом --product_version, например:

Команда:

pg_ctl --product_version

Результат выполнения команды:

Platform V Pangolin 5.2.0

где:

• Platform V Pangolin — наименование продукта;

• 5.2.0 — версия продукта.

Чтобы получить название и версию PostgreSQL, запустите любую команду с ключом --version, например:

Команда:

pg_ctl --version

Результат выполнения команды:

pg_ctl (PostgreSQL) 13.4

Для серверной части#

Для получения названия и версии продукта серверной части подключитесь к серверу Platform V Pangolin, чтобы:

• узнать версию Platform V Pangolin:

  Команда:

  SELECT product_version();
  

  Результат выполнения команды:

      product_version
  ---------------------------
  Platform V Pangolin 5.1.0
  (1 row)
  

• узнать версию PostgreSQL:

  Команда:

  SELECT version();
  

  Результат выполнения команды:

                                                  version
  ---------------------------------------------------------------------------------------------------------
  PostgreSQL 13.4 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44), 64-bit
  (1 row)
  

  Примечание:

  Вывод может отличаться от приведенного в примере.

Получение информации о сборке продукта#

Чтобы получить информацию о сборке продукта Platform V Pangolin, запустите любую команду с ключом --product_build_info, например:

Команда:

pg_ctl --product_build_info

Результат выполнения команды:

build 54 (22:27:09 05.02.2022) commit cbb7a012923abe4143bc029c6ae7fe31be636ee5

где:

• 54 — порядковый номер сборки продукта;

• 22:27:09 05.02.2022 — время и дата сборки продукта;

• cbb7a012923abe4143bc029c6ae7fe31be636ee5 — хеш-сумма исходных кодов продукта (идентификатор коммита в git репозитории продукта).

Пример вывода информации о сборке продукта для psql:

Команда:

SELECT product_build_info();

Результат выполнения команды:

build 54 (22:27:09 05.02.2022) commit cbb7a012923abe4143bc029c6ae7fe31be636ee5

Примечание:

Вывод может отличаться, но будет сохранена структура и формат.

Получение хеш-суммы внутренней версии компонента продукта#

Для postgresql можно получить хеш-сумму с помощью параметра --product_component_hash, например:

Команда:

pg_ctl --product_component_hash

Результат выполнения команды:

ae6aec146801794bb9d95c3821ca039bff6ea7d4

Интерфейс администратора безопасности Pangolin#

Интерфейс администратора безопасности включает в себя следующие функции:

• Действия с политиками:

  • pm_get_policies - вывод списка политик;

  • pm_get_policy_grants - вывод списка разрешений (правил) в составе политики;

  • pm_make_policy - создание политики;

  • pm_grant_to_policy - внесение в политику разрешения на действия над объектом;

  • pm_revoke_from_policy - исключение из политики разрешения на действия над объектом;

  • pm_suspend_object - приостановка действия политики защиты;

  • pm_resume_object - возобновление действия политики защиты;

  • pm_remove_policy - удаление политики защиты.

• Действия с пользователями:

  • pm_get_assigned_policies - вывод списка политик, назначенных пользователю;

  • pm_assign_policy_to_user - назначение политики пользователю;

  • pm_unassign_policy_from_user - изъятие политики у пользователя.

• Действия над объектами:

  • pm_get_protected_objects - вывод списка объектов, находящихся под защитой;

  • pm_protect_object - помещение объекта БД под защиту;

  • pm_unprotect_object - снятие защиты с объекта БД;

  • pm_get_object_access_path - получение информации об эффективных действующих для указанных объекте и роли ограничениях защиты и разрешениях на доступ к объекту под защитой.

• Действия для администраторов безопасности:

  • pm_create_security_admin - создание учетной записи администратора безопасности;

  • pm_set_security_admin_password - изменение пароля учетной записи администратора безопасности;

  • pm_grant_security_admin - назначение пользователя администратором безопасности;

  • pm_revoke_security_admin - снятие с пользователя политики администратора безопасности;

  • pm_unblock_security_admin - разблокировка заблокированной учетной записи администратора безопасности.

Интерфейс управления парольными политиками: PL/pgSQL API#

Все запросы к базе выполняются через SPI интерфейс (то есть не через внутренний API АС Platform V Pangolin), так как вероятность изменения SQL интерфейса меньше.

Настройки механизма хранятся в файле postgresql.conf. Данный файл также содержит значения по умолчанию для настроек парольной политики. Настройки парольной политики хранятся в таблице pg_pp_policy.

При включенной защите от привилегированных пользователей, в режиме защищенного конфигурирования, параметры парольных политик конфигурируются администратором безопасности в хранилище секретов — HashiCorp Vault, в случае отсутствия KMS-hosts (использования эмулятора) для хранения параметров используются локальные конфигурационные файлы.

Параметры парольной политики хранятся в файле в зависимости от типа конфигурации сервера, если тип конфигурации:

• standalone — в файле $PGDATA/postgresql.conf;

• cluster — в файле /etc/patroni/postgres.yml.

Подробнее о параметрах файла postgresql.conf в разделе «Параметры в postgresql.conf» данного документа.

Внимание!

При подключении через pg_bouncer с включенной сквозной аутентификацией ограниченно действуют парольные политики в части времени действия пароля и количества подключений. Проверка происходит только при первом подключении. Это связано с тем, что при подключении под pg_bouncer создается токен подключения. После получения данного токена следующее переподключение произойдет через server_lifetime.

Сценарии работы с механизмом#

Большинство операций выполняется соответствующими функциями PL/pgSQL (см. «Документация на публичные API», раздел «Функции для работы с парольными политиками»):

• создание парольной политики;

• активация парольной политики;

• деактивация парольной политики;

• отображение парольных политик, примененных к роли;

• отображение всех активных политик;

• разблокировка роли.

Включение механизма (password_policies_enable)#

Параметр password_policies_enable включает (on) или выключает (off) механизм.

Статистика и история по паролю ведется в любом состоянии механизма.

Использование значений настроек парольной политики из файла postgresql.conf (password_policy.deny_default)#

Параметр password_policy.deny_default включает (on) или выключает (off) использование значений для настроек парольной политики из файла postgresql.conf.

Примечание:

Если выключить параметр password_policy.deny_default:

password_policy.deny_default=off

то для всех политик должны быть заданы все обязательные настройки (см. подраздел «Обязательные настройки парольной политики» данного документа).

Управление шифрованием пароля (password_policy.psql_encrypt_password)#

Параметр password_policy.psql_encrypt_password управляет шифрованием пароля при передаче от фронтенда (psql) к базе с помощью команды psql \password .

В случае, если шифрование отключено, пароль передается хешем. Если при этом включены проверки пароля (сам механизм и один из способов проверки пароля), парольными политиками будет вызвана ошибка.

Задание значений по умолчанию для настроек парольной политики#

Все настройки для парольной политики имеют аналог в файле postgresql.conf. Это необходимо для возможности задания значения по умолчанию для настроек парольной политики (см. «Детальная архитектура», раздел «Прочие поведенческие механизмы», подраздел «Вычисление значений настроек для парольной политики пользователя»).

Подробное описание настроек в разделе «Использование значений настроек парольной политики из файла postgresql.conf» данного документа.

Создать новую политику#

Примечание:

Для созданной парольной политики необходимо перечислить параметры с новыми значениями и указать связанные с ними параметры.

Если связанные параметры с основным не будут указаны, то новая политика не применится.

Для создания новой политики последовательно выполните функции:

1. Создания парольной политики.

   Примечание:

   Если какая-либо настройка политики не задана, то ее значение берется из конфигурационного файла.

2. Активации парольной политики.

Функции создания и активации парольной политики описаны в «Документация на публичные API», раздел «Функции для работы с парольными политиками».

Разблокировать роль#

Выполняется соответствующей SQL-функцией (см. «Документация на публичные API», раздел «Функции для работы с парольными политиками»).

Активировать или деактивировать политику#

Выполняется соответствующими SQL-функциями:

• активация парольной политики;

• деактивация парольной политики.

Подробнее о функциях см. «Документация на публичные API», раздел «Функции для работы с парольными политиками»

Изменить настройки политики#

Выполняется соответствующей SQL-функцией (см. «Документация на публичные API», раздел «Функции для работы с парольными политиками»).

При изменении параметров учитывайте зависимости между ними и изменяемую функциональность (см. ниже подраздел «Обязательные настройки парольной политики»). Нельзя изменить параметр roloid.

Сменить политику для роли#

Роли связаны с политиками по идентификатору роли. Изменить политику для роли можно следующими способами:

• удалить старую политику и создать новую политику;

• включить роль в другую роль с нужной политикой.

Подробнее о функциях см. «Документация на публичные API», раздел «Функции для работы с парольными политиками»

Обязательные настройки парольной политики#

Пользовательская функция проверки пароля#

Пользователь может создать PL/pgSQL функцию проверки пароля. Ниже описаны требования к пользовательской функции.

Примечание:

Зашифрованный пароль приходит, если Pangolin подключен к сторонней системе аутентификации.

Параметры для управления транспортными паролями#

Разблокировать и восстановить работу кластера:#

1. Определите, на каком хосте был последний активный лидер. Это можно проверить по логам patroni:

   host1$ sudo journalctl --since "5 hours ago" -u patroni | grep "i am " | tail -1
   Aug 04 22:38:17 tkles-pprb00096.vm.esrt.cloud.sbrf.ru python3[14026]: 2020-08-04 22:38:17,824 INFO: no action. i am the leader with the lock
   host2$ sudo journalctl --since "5 hours ago" -u patroni | grep "i am " | tail -1
   Aug 04 22:38:07 tkles-pprb00094.vm.esrt.cloud.sbrf.ru python3[21032]: 2020-08-04 22:38:07,814 INFO: no action. i am a secondary and i am following a leader
   

   В данном случае лидер был на хосте «host1».

2. Остановите patroni на хосте последнего лидера:

   host1$ sudo systemctl stop patroni
   

3. Запустите PostgreSQL в single user режиме:

   host1$ postgres --single
   

   Если postgres не запускается даже на предположительном лидере и выводит ошибку:

   2020-08-04 23:08:34 MSK [20019]: [1-1] app=,user=,db=,client= LOG: database system was shut down in recovery at 2020-08-04 23:08:30 MSK
   2020-08-04 23:08:34 MSK [20019]: [2-1] app=,user=,db=,client= WARNING: recovery command file "recovery.conf" specified neither primary_conninfo nor restore_command
   2020-08-04 23:08:34 MSK [20019]: [3-1] app=,user=,db=,client= HINT: The database server will regularly poll the pg_wal subdirectory to check for files placed there.
   2020-08-04 23:08:34 MSK [20019]: [4-1] app=,user=,db=,client= FATAL: standby mode is not supported by single-user servers
   

   Уберите файл recovery.conf из $PGDATA и снова выполните запуск:

   host1$ mv $PGDATA/recovery.conf{,.back}
   host1$ postgres --single
   

4. В single user режиме выполните SQL команды от лица пользователя postgres. Для выхода нажмите Ctrl/Cmd-D. Разблокируйте роль postgres:

   select unblock_role('postgres')
   

   Если при попытке разблокировать пользователя postgres выходит ошибка:

   backend> select unblock_role('postgres')
        1: unblock_role        (typeid = 16, len = 1, typmod = -1, byval = t)
       ----
   2022-07-05 11:58:17 MSK [19233]: [2-1] app=[unknown],user=postgres,db=postgres,client=[tty] ERROR:  Cant find role with Oid 10 in password policy cache
   2022-07-05 11:58:17 MSK [19233]: [3-1] app=[unknown],user=postgres,db=postgres,client=[tty] STATEMENT:  select unblock_role('postgres')
   

   Выполните команду для разблокировки пользователя postgres:

   backend> update pg_pp_policy set lockout='f' WHERE roloid = to_regrole('postgres');
   backend>
   

5. Запустите службу Patroni:

   host1$ sudo systemctl start patroni
   

6. Убедитесь, что кластер вернулся в стабильное состояние. В таблице вывода в столбце Role должен быть указан Leader:

   host1$ list
   + Cluster: clustername (6857170778029161231) ----------------------------------------+--------------+---------+----+-----------+
   |                 Member                |                    Host                    |     Role     |  State  | TL | Lag in MB |
   +---------------------------------------+--------------------------------------------+--------------+---------+----+-----------+
   | tkles-pprb00094.vm.esrt.cloud.sbrf.ru | tkles-pprb00094.vm.esrt.cloud.sbrf.ru:5433 | Sync Standby | running |  4 |         0 |
   | tkles-pprb00096.vm.esrt.cloud.sbrf.ru | tkles-pprb00096.vm.esrt.cloud.sbrf.ru:5433 |    Leader    | running |  4 |           |
   +---------------------------------------+--------------------------------------------+--------------+---------+----+-----------+
   

7. Стандартным образом разблокируйте остальных администраторов БД.

Справочник журнальных сообщений#

Параметры в postgresql.conf#

В данном разделе более подробно описаны параметры файла postgresql.conf.

password_policy.policy_enable (Состояние по умолчанию для парольной политики)#

Признак включенной парольной политики:

• on – политика включена;

• off – политика выключена.

password_policy.deny_default#

Запрет использования значений для настроек политик, указанных в файле postgresql.conf:

• on – включить использование значений настроенных политик, указанных в файле postgresql.conf;

• off – выключить использование значений настроенных политик, указанных в файле postgresql.conf.

Настройка хранения паролей#

password_policy.reuse_time#

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

password_policy.in_history#

Максимальное количество сохраненных старых паролей. При достижении максимума добавление еще одного старого пароля приводит к удалению наиболее старого (по pg_pp_history.createtime) из них.

Примечание:

Если задан параметр password_policy.reuse_time, то параметр password_policy.in_history не используется.

Время жизни пароля#

password_policy.max_age#

Время жизни пароля в секундах, после которого пароль считается истекшим.

password_policy.min_age#

Время в секундах, которое должно пройти между двумя изменениями пароля.

password_policy.grace_login_limit#

Максимальное количество аутентификаций, доступных роли после истечения времени жизни пароля.

password_policy.grace_login_time_limit#

Время в секундах после окончания действия пароля, в течение которого он продолжает работать. Если вычисленное значение graceloginlimit=0, то параметр не учитывается.

password_policy.expire_warning#

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

Поведение при неудачной аутентификации#

password_policy.lockout#

Блокировка аккаунта в результате достижения максимума попыток входа с неверным паролем:

• on – включить блокировку;

• off – выключить блокировку.

password_policy.max_failure#

Максимальное количество введенных подряд неверных паролей, при достижении которого вызывается блокировка пароля.

password_policy.failure_count_interval#

Время в секундах, после которого обнуляется количество неверных вводов пароля.

password_policy.lockout_duration#

Время в секундах, на которое блокируется аккаунт в результате достижения максимума попыток входа с неверным паролем.

Синтаксические проверки пароля#

password_policy.check_syntax#

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

• on – включить механизм;

• off – выключить механизм.

password_policy.alpha_numeric#

Минимальное количество цифр в пароле. Если вычисленное значение checksyntax=false, то параметр не учитывается.

password_policy.min_length#

Минимальная длина пароля. Если вычисленное значение checksyntax=false, то параметр не учитывается.

password_policy.min_alpha_chars#

Минимальное количество букв в пароле. Если вычисленное значение checksyntax=false, то параметр не учитывается.

password_policy.min_special_chars#

Минимальное количество символов в пароле, не являющихся буквой или цифрой. Если вычисленное значение checksyntax=false, то параметр не учитывается.

password_policy.min_uppercase#

Минимальное количество прописных букв. Если вычисленное значение checksyntax=false, то параметр не учитывается.

password_policy.min_lowercase#

Минимальное количество строчных букв. Если вычисленное значение checksyntax=false, то параметр не учитывается.

password_policy.max_rpt_chars#

Максимальное количество повторяющихся символов. Если вычисленное значение checksyntax=false, то параметр не учитывается.

Проверка максимального времени неактивности пользователя#

password_policy.track_login#

Запоминать ли время последней аутентификации:

• on – запоминать;

• off – не запоминать.

password_policy.max_inactivity#

Время в секундах после последней аутентификации, после которого роль будет заблокирована.

Использование библиотеки zxcvbn#

password_policy.use_password_strength_estimator#

Включить или выключить использование библиотеки zxcvbn для проверки пароля:

• on – включить механизм;

• off – выключить механизм.

password_policy.password_strength_estimator_score#

Минимальная оценка сложности пароля, допустимая в системе. Если вычисленное значение usepasswordstrengthestimator=false, то параметр не учитывается.

Использование пользовательской функции проверки пароля#

password_policy.custom_function#

Название пользовательской PL/pgSQL функции проверки пароля.

Использование библиотеки cracklib#

password_policy.illegal_values#

Использовать библиотеку cracklib для проверки пароля по списку часто используемых:

• on – включить проверку;

• off – выключить проверку.

Настройка кэширования#

password_policy.pp_cache_dump_interval#

Интервал сохранения данных кэша из памяти на диск (при наличии изменений).

password_policy.pp_cache_init_size#

Размер изначально инициализированного кэша парольных политик в пользователях.

password_policy.pp_cache_soft_max_size#

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

password_policy.pp_cache_max_size#

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

psql_encrypt_password#

Шифрование пароля при передаче от фронтенда (psql) к базе:

• on – включить шифрование;

• off – выключить шифрование.

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

password_policy.deduplicate_ssl_no_ssl_fail_auth_attepmts#

Включение механизма дедупликации повторных попыток подключения psql.

password_policy.allow_hashed_password#

Разрешить задание пароля в виде хеша.

Авторизация и аутентификация#

Pangolin поддерживает несколько типов авторизации и аутентификации пользователей и сервисов (см. документ «Руководство по безопасности» разделы «Идентификация и аутентификация» и «Авторизация»).

В данном разделе более подробно рассмотрены варианты сквозной и двухфакторной авторизации.

Сквозная аутентификация pgBouncer — Pangolin#

В pgBouncer и Pangolin реализован механизм сквозной аутентификации. Программа pgBouncer выступает в режиме проксирования данных аутентификации от клиента к Pangolin и обратно, аутентификация пользователя выполняется только на Pangolin.

Количество итераций обмена данными аутентификации для конкретного пользователя зависит от установленных в файле pg_hba.conf методов аутентификации. Обмен данными аутентификации между pgBouncer и Pangolin выполняется по отдельным сетевым каналам. Количество сетевых каналов зависит от количества баз данных, к которым выполняется подключение пользователей.

Конфигурирование сквозной аутентификации в pgBouncer#

Настроить сквозную аутентификацию в pgBouncer можно с помощью конфигурационных параметров, описанных в данном разделе.

Параметры аутентификации:

• auth_proxy (string) — параметр включает/выключает режим сквозной аутентификации:

  • off — режим сквозной аутентификации выключен, выполняется локальная аутентификация пользователя (значение по умолчанию);

  • on — режим сквозной аутентификации включен, выполняется аутентификация пользователя только на Pangolin;

• auth_failure_threshold (integer) — параметр задает максимальное число НЕ аутентифицированного N раз подряд клиента с идентичными параметрами (тип соединения, адрес клиента, база данных и имя пользователя), при котором будет взведен таймер не активности аутентификации для этого клиента. Значение по умолчанию 0 (выключено);

• auth_inactivity_period (integer) — параметр определяет период не активности аутентификации (в секундах). Это время, в течение которого ранее НЕ аутентифицированному более N раз подряд клиенту при подключении с идентичными параметрами (тип соединения, адрес клиента, база данных и имя пользователя), pgBouncer откажет в обслуживании. Значение по умолчанию 0 (выключено);

• auth_lost_size (integer) — параметр задает максимальное число кэшируемых записей о последних аутентификациях пользователей. Значение по умолчанию 10. Информацию о последних аутентификациях пользователей можно получить с помощью команды show last (см. подробнее в подразделе «Команды вывода информации» текущего раздела);

• log_audit (integer) — включает/выключает аудит. Значение по умолчанию - 0 (выключено).

Параметры подключений:

• auth_port (integer) — номер порта, к которому нужно подключиться для выполнения аутентификации пользователей. Параметр раздела базы данных [databases];

• auth_pool_size (integer) — параметр задает максимальное количество соединений для выполнения аутентификации пользователей. Значение по умолчанию 1. Параметр раздела базы данных [databases].

Пример конфигурации (содержит параметры, связанные со сквозной аутентификацией):

[databases]
* =м host=<ip_address> port=5433 auth_port=5434

[pgbouncer]
 listen_addr = *
 listen_port = 6544
; включена сквозная аутентификация
 auth_proxy = on
; включен audit
 log_audit = 1
; выставлено время выполнения аутентификации
 client_login_timeout = 10
; выставлен порог, по превышению которого пользователь временно блокируется
 auth_failure_threshold = 3
; выставлен период неактивности аутентификации
 auth_inactivity_period = 30
; выставлен размер кешируемых записей о последних аутентификациях пользователей
 auth_last_size = 20

; пользователи, прописанные в userlist, будут выполнять аутентификацию, используя данный метод
 auth_type = scram-sha-256
; в файле userlist содержатся пользователи, выполняющие действия администратора или мониторинг
 auth_file = ./userlist.txt
 admin_users = pgbouncer
 stats_users = stat

Внимание!

Сквозная аутентификация не работает для пользователей, которые указаны в секции [users] конфигурационного файла pgBouncer.

Раздел [users] содержит пары ключ=значение, где в качестве ключа принимается имя пользователя, а в качестве значения — переопределяемые для него параметры конфигурации (в формате строк подключения libpq):

• pool_mode – задает режим пула для всех подключений данного пользователя;

• max_user_connections – задает максимум подключений для пользователя.

Пользователь, для которого переопределен один или оба параметра:

• должен быть указан в параметре stats_users или admin_users;

• должен присутствовать в списке userlist.txt (параметр auth_file) в виде "имя_пользователя" "хеш_пароля_пользователя".

Пример конфигурации (содержит параметры, связанные с использованием секции [users] файла /etc/pgbouncer/pgbouncer.ini):

[pgbouncer]
; в файле userlist содержатся пользователи, выполняющие действия администратора или мониторинг
auth_file = ./userlist.txt
admin_users = pgbouncer
stats_users = user1
[users]
; раздел содержит имя пользователя и переопределяемые для него параметры конфигурации
user1 = pool_mode=session max_user_connections=1

Пользователю user1 при таких настройках будут применены персональные параметры pool_mode и max_user_connections, а аутентификация в базе данных будет выполняться только после аутентификации его в pgBouncer.

Конфигурирование сквозной аутентификации в Pangolin#

Настроить сквозную аутентификацию в Pangolin можно с помощью конфигурационных параметров, описанных в данном разделе.

Параметры аутентификации:

• authentication_proxy (integer) — параметр включает/выключает режим сквозной аутентификации:

  • 0 — режим сквозной аутентификации выключен, не позволяет выполнять аутентификацию пользователей конкретной БД в отдельном потоке (значение по умолчанию);

  • 1 — режим сквозной аутентификации включен, позволяет выполнять аутентификацию пользователей конкретной БД в отдельном потоке;

• auth_handshake_timeout (integer) — параметр определяет максимальное время, за которое должно произойти подтверждение аутентификации (в секундах). Значение по умолчанию 10 сек. Если потенциальный клиент не сможет выполнить подтверждение аутентификации (рукопожатие) за это время, сервер закроет соединение;

• auth_activity_period (integer) — параметр определяет период активности аутентификации (в секундах). Значение по умолчанию 60 сек. Это время, в течение которого ранее аутентифицированный клиент при подключении с идентичными параметрами (тип соединения, адрес клиента, база данных и имя пользователя), выполнит аутентификацию по token.

  Значение передается на pgBouncer и используется для проведения более быстрой аутентификации. Возможные значения:

  • -1 — не используется период активности аутентификации;

  • 0 — период активности аутентификации не имеет ограничений по времени;

  • > 0 — имеет ограничение по времени.

Примечание:

• не рекомендуется выставлять значение auth_activity_period = 0, так как его нельзя сбросить в pgBouncer без перезагрузки;

• выставляемого значения должно хватить, чтобы запустить пул соединений между pgBouncer и Pangolin.

Параметры подключений:

authentication_port (integer) — TCP-порт, открываемый сервером для выполнения аутентификации пользователей (по умолчанию порт — 5433).

Примечание:

Параметр authentication_port (integer) можно задать только при запуске сервера.

Пример конфигурации (содержит параметры связанные со сквозной аутентификацией):

port = 5433

authentication_port = 5434
authentication_timeout 60 # sec
auth_activity_period = 60 # sec

Команды вывода информации#

Для получения информации о статусе или результатах работы механизма сквозной аутентификации были добавлены следующие команды:

• SHOW AUTHSERVERS — показывает информацию о соединениях с сервером аутентификации.

• SHOW AUTHPOOLS — показывает информацию по пулам аутентификации.

  Примечание:

  Новый пул аутентификации создается для каждой базы данных.

• SHOW AUTHUSERS — показывает информацию о пользователях.

• SHOW LAST — показывает информацию об аутентификации последних N пользователей.

  Примечание:

  auth_last_size — по умолчанию команда показывает 10 последних пользователей.

  При превышении этого значения первые записи удаляются, а новые добавляются в конец. Команда не хранит причину, по которой не прошла аутентификация. Ее требуется искать в логах Pangolin или pgBouncer. В каком логе и в какое время - зависит от значений параметров place и connect_time\auth_time.

• SHOW LOCKED_USERS — показывает информацию о заблокированных пользователях.

  Команда показывает временно заблокированных пользователей. Это пользователи с идентичными параметрами: тип соединения, адрес клиента, база данных и имя пользователя, которые не смогли аутентифицироваться N раз подряд (N определяет конфигурационный параметр auth_failure_threshold). Длительность блокировки пользователя определяется конфигурационным параметром auth_inactivity_period.

Подробное описание команд в «Документация на публичные API: PL/pgSQL», раздел «Описание API функциональности сквозной аутентификации».

В утилите psql имелся механизм запоминания ранее выполненных запросов. Этот механизм позволял просмотреть историю ранее выполненных команд и повторно вызвать ранее выполненные запросы.

История запросов хранилась в открытом виде в файле ~/.psql_history. При выполнении запросов, содержащих пароли это могло представлять угрозу безопасности, так как пароли хранились так же в незашифрованном виде.

В связи с новой функциональностью изменяется поведение утилиты psql по сравнению с имеющимся:

• создание и чтение файла ~/.psql_history не производится;

• влияние переменной окружения PSQL_HISTORY на работу утилиты psql отсутствует;

• установка переменной HISTFILE в утилите psql не даёт эффекта.

Реализованная функциональность не приводит к удалению или очищению ранее созданных файлов истории запросов. После обновления продукта рекомендуется (если необходимо) удалить ранее созданные файлы истории, выполнив команду:

rm -f ~/.psql_history

Двухфакторная аутентификация#

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

Пользователь может подключаться к БД:

• непосредственно (или напрямую) к Pangolin;

• через pgBouncer к Pangolin, используя сквозную аутентификацию;

• через pgBouncer к Pangolin, используя базовые механизмы аутентификации.

Сертификат безопасности клиента должен содержать поле CN, содержащее логин клиента и, опционально, поле SubjectAltName, содержащее один или несколько IP-адресов (возможен вариант указания подсети) и (или) DNS-имен клиента.

Для подключения непосредственно к Pangolin, в файле pg_hba.conf необходимо указать метод аутентификации: 2f-scram-sha-256, 2f-md5, 2f-password или 2f-ldap.

Для подключения через pgBouncer к Pangolin, используя сквозную аутентификацию, необходимо:

• в конфигурационных файлах Pangolin:

  • в файле pg_hba.conf необходимо указать метод аутентификации: 2f-scram-sha-256, 2f-md5, 2f-password или 2f-ldap;

  • в файле postgresql.conf указать:

    • authentication_proxy = on;

    • authentication_port = {AUTHPORT};

• в конфигурационном файле pgBouncer указать:

  • auth_port={AUTHPORT};

  • auth_proxy = on;

  • auth_type = scram-sha-256 или md5.

Для подключения через pgBouncer к Pangolin, используя базовые механизмы аутентификации, необходимо в конфигурационном файле pgBouncer указать:

• в конфигурационных файлах Pangolin:

  • в файле pg_hba.conf необходимо указать метод аутентификации: 2f-scram-sha-256, 2f-md5, 2f-password или 2f-ldap;

  • в файле postgresql.conf указать authentication_proxy = off;

• в конфигурационном файле pgBouncer указать:

  • auth_proxy = off;

  • auth_type = 2f-scram-sha-256 (2f-md5, 2f-plain);

• Аутентификация LDAP не поддерживается pgBouncer, поэтому 2f-ldap так же не поддерживается.

Внимание!

Необходимо учитывать, что разрешенными по умолчанию механизмами двухфаторной аутентификации являются 2f-scram-sha-256 и 2f-ldap.

При необходимости использования методов аутентификации 2f-md5 и 2f-password, нужно добавить эти методы в параметр enabled_extra_auth_methods в конфигурационном файле postgresql.conf.

Например:

enabled_extra_auth_methods = '2f-md5,2f-password'

Настройка Pangolin для двухфакторной аутентификации#

Для выполнения двухфакторной аутентификации клиентов требуется:

• в файле postgresql.conf - включить SSL режим и прописать сертификаты:

  ssl = on
  ssl_ca_file = './root.crt'
  ssl_cert_file = './server.crt'
  ssl_key_file = './server.key'
  

• в файле pg_hba.conf указать:

  • тип сети - hostssl;

  • тип аутентификации: 2f-md5 или 2f-scram-sha-256;

  # TYPE  DATABASE        USER            ADDRESS                 METHOD
  hostssl    test           test1             127.0.0.1/32        2f-md5
  hostssl    test           test1             hostname            2f-scarm-sha-256
  

Настройка pgBouncer для двухфакторной аутентификации#

Для выполнения двухфакторной аутентификации клиентов требуется в файле конфигурации pgbouncer.ini (имя файла конфигурации может быть другим) указать:

• параметры подключения SSL/TLS;

• тип аутентификации: 2f-scram-sha-256 или 2f-md5;

Ниже приведен пример конфигурации, когда защищенное соединение выполняется между клиентом и pgBouncer-ом, а между pgBouncer и Pangolin используется обычное соединение.

[pgbouncer]
auth_type = 2f-scram-sha-256

; TLS settings
client_tls_protocols = all
client_tls_sslmode = verify-full
client_tls_ca_file = ./root.crt
client_tls_cert_file = ./server.crt
client_tls_key_file = ./server.key

Настройка сквозной двухфакторной аутентификации#

Все специальные настройки были описаны ранее — необходимо только включить сквозную аутентификацию на pgBouncer с Pangolin.

В файле pgbouncer.ini:

[pgbouncer]
 auth_proxy = on
 auth_type = scram-sha-256

 client_tls_sslmode = verify-ca
 client_tls_key_file = ./server.key
 client_tls_cert_file = ./server.crt
 client_tls_ca_file = ./root.crt

 server_tls_sslmode = verify-full
 server_tls_key_file = ./pgbouncer.key
 server_tls_cert_file = ./pgbouncer.crt
 server_tls_ca_file = ./root.crt
 server_tls_ciphers = normal

[databases]
* = host=localhost port=5432 auth_port=5433  auth_port=5444 auth_pool_size=1

В файле postgresql.conf:

port = 5432
authentication_port = 5433
authentication_timeout = 60 # sec
auth_activity_period = 10 # sec

ssl = on
ssl_key_file = ./server.key
ssl_cert_file = ./server.crt
ssl_ca_file = ./root.crt

Генерация сертификатов#

Для включения SSL между компонентами кластера необходимо подготовить сертификаты и пароль для сервиса статистики haproxy.

Подготовка сертификатов не выполняется инсталлятором Pangolin. Ожидается, что на хосте уже есть сертификаты, которые будут переданы на вход инсталлятору. Инсталлятор сам разместит их в нужных директориях и выдаст права для служебных пользователей (например, etcd).

• Серверный сертификат (необходимо создать для каждого хоста в кластере):

  1. Сгенерируйте ключ:

     openssl genrsa -out server.key 2048
     

  2. Создайте файл конфигурации для создания запроса на подпись сертификата vim server.conf:

     [req]
     req_extensions = v3_req
     distinguished_name = req_distinguished_name
     [req_distinguished_name]
     [ v3_req ]
     basicConstraints = CA:FALSE
     keyUsage = nonRepudiation, digitalSignature, keyEncipherment
     subjectAltName = @alt_names
     [ ssl_client ]
     extendedKeyUsage = clientAuth, serverAuth
     basicConstraints = CA:FALSE
     subjectKeyIdentifier=hash
     authorityKeyIdentifier=keyid,issuer
     subjectAltName = @alt_names
     [ v3_ca ]
     basicConstraints = CA:TRUE
     keyUsage = nonRepudiation, digitalSignature, keyEncipherment
     subjectAltName = @alt_names
     authorityKeyIdentifier=keyid:always,issuer
     [alt_names]
     DNS.1 = tkles-core00133.vm.esrt.cloud.sbrf.ru ## hostname with domain
     IP.1 = 10.53.115.151 ## host ip address
     

  3. Экспортируйте файл конфигурации:

     CONFIG=`echo $PWD/server.conf`
     

  4. Создайте запрос на подпись сертификата. В CN необходимо указать полный hostname:

     openssl req -new -key server.key -out server.csr -subj "/CN=tkles-core00133.vm.esrt.cloud.sbrf.ru" -config ${CONFIG}
     

• Клиентский сертификат:

  1. Сгенерируйте ключ:

     openssl genrsa -out postgres.key 2048
     

  2. Создайте файл конфигурации для создания запроса на подпись сертификата vim client.conf:

     [req]
     req_extensions = v3_req
     distinguished_name = req_distinguished_name
     [req_distinguished_name]
     [ v3_req ]
     basicConstraints = CA:FALSE
     keyUsage = nonRepudiation, digitalSignature, keyEncipherment
     [ ssl_client ]
     extendedKeyUsage = clientAuth
     basicConstraints = CA:FALSE
     subjectKeyIdentifier=hash
     authorityKeyIdentifier=keyid,issuer
     [ v3_ca ]
     basicConstraints = CA:TRUE
     keyUsage = nonRepudiation, digitalSignature, keyEncipherment
     authorityKeyIdentifier=keyid:always,issuer
     

  3. Экспортируйте файл конфигурации:

     CONFIG=`echo $PWD/client.conf`
     

  4. Создайте запрос на подпись сертификата. В CN необходимо указать имя клиента/компонента (postgres, patroni, patronietcd, pgbouncer, haproxy):

     openssl req -new -key postgres.key -out postgres.csr -subj "/CN=postgres" -config ${CONFIG}
     

  Примечание:

  При создании клиентских сертификатов, в поле subjectAltName можно указать IP-адрес или(и) DNS-имя машины (список машин), на которой(ых) будет использоваться сертификат. Также в этом поле можно указать адрес подсети.

Сгенерированные запросы на подпись сертификатов (файлы в формате *.csr) необходимо подписать удостоверяющем центре.

Полученные сертификаты необходимо перевести в формат PEM (например, командой openssl x509 -inform DER -outform PEM -in ./certificate.cer -out ./certificate.crt), расположить в одинаковых директориях на каждом хосте и выдать права - 600 для ключей и 644 для сертификатов, владелец — УЗ ОС postgres.

Наименование сертификатов, с которыми будет работать инсталлятор:

Поскольку в PostgreSQL можно указать только один корневой сертификат, а в нашем случае их два (один — УЦ непосредственно выпустивший сертификат, второй — УЦ выпустивший сертификат для УЦ и имеющий признак CA), необходимо объединить сертификаты корневого и промежуточного УЦ в один:

cat root.crt intermediate.crt > rootCA.crt

Все корневые сертификаты необходимо скопировать в папку /etc/pki/ca-trust/source/anchors и выполнить команду обновления хранилища доверенных корневых сертификатов:

sudo update-ca-trust

Если используется компонент haproxy, то для него необходимо сертификат и приватный ключ объединить в один файл, например, командой:

cat server-key.pem server.pem >> haproxy.pem

Данный сертификат будет использоваться для подключения по HTTPS на сервер статистики.

Настройка компонентов#

Внимание!

В процессе работы инструмента развертывания производится валидация сертификатов на их соответствие требованиям указанным в разделе «Подготовка». После работы инструмента развертывания валидация сертификатов находится на стороне владельца стенда.

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

1. В файле postgres.conf (для стендов в конфигурации standalone-postgresql-pgbouncer). В данном случае необходимо указать путь к подписанным сертификатам для сервера БД:

   ssl = 'on'
   ssl_cert_file = '/home/postgres/sber_ca/server.crt'
   ssl_key_file = '/home/postgres/sber_ca/server.key'
   ssl_ca_file = '/home/postgres/sber_ca/rootCA.crt'
   ssl_crl_file = 'путь до файла со списком отозванных сертифкатов'
   

2. В pgbouncer.ini добавьте секцию TLS-настроек. Между pgbouncer и postgresql настраивается обязательное SSL-соединение, между pgbouncer и клиентом — по требованию клиента. В обоих случаях минимальная версия TLS 1.2 и соответствующие ему шифры (Cipher suites (TLS 1.2): ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384).

   #  TLS settings
   server_tls_protocols = secure
   server_tls_ciphers = secure
   server_tls_sslmode = verify-full
   server_tls_ca_file = /home/postgres/sber_ca/rootCA.crt
   server_tls_cert_file = /home/postgres/sber_ca/pgbouncer.crt
   server_tls_key_file = /home/postgres/sber_ca/pgbouncer.key
   client_tls_protocols = secure
   client_tls_ciphers = secure
   client_tls_sslmode = prefer
   client_tls_ca_file = /home/postgres/sber_ca/rootCA.crt
   client_tls_cert_file = /home/postgres/sber_ca/server.crt
   client_tls_key_file = /home/postgres/sber_ca/server.key
   

3. В etcd.conf значения http переведите в https и добавьте секцию настроек TLS. Аутентификация в БД etcd происходит по паролю, так же необходимо указать сертификат пользователя.

   ETCD_NAME="tkles-core00133"
   ETCD_LISTEN_CLIENT_URLS="https://0.0.0.0:2379"
   ETCD_ADVERTISE_CLIENT_URLS="https://tkles-core00133.vm.esrt.cloud.sbrf.ru:2379"
   ETCD_LISTEN_PEER_URLS="https://0.0.0.0:2380"
   ETCD_INITIAL_ADVERTISE_PEER_URLS="https://tkles-core00133.vm.esrt.cloud.sbrf.ru:2380"
   ETCD_INITIAL_CLUSTER_TOKEN="test"
   ETCD_INITIAL_CLUSTER="tkles-core00133=https://tkles-core00133.vm.esrt.cloud.sbrf.ru:2380,tkles-core00075=https://tkles-core00075.vm.esrt.cloud.sbrf.ru:2380,tkles-core00077=https://tkles-core00077.vm.esrt.cloud.sbrf.ru:2380"
   ETCD_INITIAL_CLUSTER_STATE="new"
   ETCD_DATA_DIR="/var/lib/etcd"
   ETCD_ELECTION_TIMEOUT="5000"
   ETCD_HEARTBEAT_INTERVAL="1000"
   ETCD_ENABLE_V2="false"
   # TLS settings
   ETCD_CIPHER_SUITES="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"
   ETCD_TRUSTED_CA_FILE="/home/postgres/sber_ca/rootCA.crt"
   ETCD_CERT_FILE="/home/postgres/sber_ca/server.crt"
   ETCD_KEY_FILE="/home/postgres/sber_ca/server.key"
   ETCD_PEER_TRUSTED_CA_FILE="/home/postgres/sber_ca/rootCA.crt"
   ETCD_PEER_CERT_FILE="/home/postgres/sber_ca/server.crt"
   ETCD_PEER_KEY_FILE="/home/postgres/sber_ca/server.key"
   ETCD_PEER_CLIENT_CERT_AUTH="true"
   ETCD_PEER_CRL_FILE="путь до файла со списком отозванных сертифкатов"
   

4. В файле конфигурации patroni postgres.yml внесите изменения в секции restapi, etcd3, postgres, pg_hba.

   1. restapi добавить параметры verify_client, cafile, certfile, keyfile - пути до сертификатов. Параметр verify_client: optional - означает, что все запросы «управления» PUT, POST, PATCH, DELETE требуют аутентификации по сертификатам. Параметры allowlist: [] allowlist_include_members: true - означают, что доступ к запросам «управления» есть только у членов кластера и хостов, которые перечислены в allowlist. Запросы GET (только получение сведений о кластере) будут возвращаться без аутентификации.

      restapi:
          listen: 0.0.0.0:8008
          connect_address: tkles-core00133.vm.esrt.cloud.sbrf.ru:8008
          allowlist: []
          allowlist_include_members: true
          verify_client: optional
          cafile: /home/postgres/sber_ca/rootCA.crt
          certfile: /home/postgres/sber_ca/server.crt
          keyfile: /home/postgres/sber_ca/server.key
          authentication:
              username: patroniyml
              password: $enc$gDr8F+Suzo3TToVigCBX2se9MJW3Ie0kqyJ+PClL5UA=
      

   2. В секции etcd добавьте параметры protocol, cacert, cert, key. Соединение с etcd будет осуществляться по протоколу HTTPS.

      etcd:
          hosts: tkles-core00077.vm.esrt.cloud.sbrf.ru:2379,tkles-core00133.vm.esrt.cloud.sbrf.ru:2379,tkles-core00075.vm.esrt.cloud.sbrf.ru:2379
          protocol: https
          cacert: /home/postgres/sber_ca/rootCA.crt
          cert: /home/postgres/sber_ca/patronietcd.crt
          key: /home/postgres/sber_ca/patronietcd.key
          username: patronietcd
          password: $enc$cVrbd96FvJJGAY5dUq6M2Mta1SciGLDvMZ4kJzh831Y=
      

5. В секции postgres в подразделе аутентификации пользователя patroni добавьте параметры sslmode, sslkey, sslcert, sslrootcert и в разделе parameters укажите путь к серверному сертификату. sslmode устанавливается в значение verify-ca из-за особенностей локального подключения.

   postgresql:
       listen: 0.0.0.0:5433
       bin_dir: /usr/pgsql-se-05/bin
       connect_address: tkles-core00133.vm.esrt.cloud.sbrf.ru:5433
       data_dir: /pgdata/05/data/
       create_replica_methods:
           - basebackup
       basebackup:
           format: plain
           wal-method: fetch
       authentication:
           replication:
               username: patroni
               database: replication
               sslmode: verify-ca
               sslkey: /home/postgres/sber_ca/patroni.key
               sslcert: /home/postgres/sber_ca/patroni.crt
               sslrootcert: /home/postgres/sber_ca/rootCA.crt
               sslcrl: "путь к файлу со списком отозванных сертификатов"
           superuser:
               username: patroni
               sslmode: verify-ca
               sslkey: /home/postgres/sber_ca/patroni.key
               sslcert: /home/postgres/sber_ca/patroni.crt
               sslrootcert: /home/postgres/sber_ca/rootCA.crt
               sslcrl: "путь к файлу со списком отозванных сертификатов"
   
           ssl: 'on'
           ssl_cert_file: /home/postgres/sber_ca/server.crt
           ssl_key_file: /home/postgres/sber_ca/server.key
           ssl_ca_file: /home/postgres/sber_ca/rootCA.crt
           ssl_crl_file: "путь к файлу со списком отозванных сертификатов"
   

6. В секции pg_hba смените метод подключения для УЗ patroni с host на hostssl:

   hostssl all patroni 10.53.115.151/32 scram-sha-256
   hostssl all patroni 10.53.115.149/32 scram-sha-256
   hostssl replication patroni 10.53.115.151/32 scram-sha-256
   hostssl replication patroni 10.53.115.149/32 scram-sha-256
   

7. haproxy.cfg - в haproxy активируется режим passthrough, добавляются проверки health-check по SSL (для patroni на порту 8008) без верификации. Доступ к странице статистики осуществляется по протоколу HTTPS с методом аутентификации «логин-пароль». Доступ к серверу статистики, порт 7000, haproxy осуществляется на основе access list, где по-умолчанию ставится localhost, а дополнительные хосты можно прописать в файле настраиваемого конфигурационного файла.

   frontend fe_postgresql
       mode tcp
       option tcplog
       bind *: 5001
       default_backend be_postgres
   
   backend be_postgres
       mode tcp
       option tcplog
       option httpchk OPTIONS /master #
       http-check expect status 200
       default-server inter 3s fall 3 rise 2 on-marked-down shutdown-sessions #
       server tkles-core00133.vm.esrt.cloud.sbrf.ru tkles-core00133.vm.esrt.cloud.sbrf.ru:6544 verify none maxconn 100 check check-ssl port 8008
       server tkles-core00075.vm.esrt.cloud.sbrf.ru tkles-core00075.vm.esrt.cloud.sbrf.ru:6544 verify none maxconn 100 check check-ssl port 8008
   
   listen stats
       mode http
       bind *:7000 ssl crt /home/postgres/sber_ca/haproxy.crt
       stats enable
       stats uri /
       stats auth login:password
       acl whitelist src 10.53.115.151
       tcp-request connection reject if ! whitelist
   

8. Если какой-либо сертификат был просрочен или отозван, необходимо выпустить новый, согласно инструкции описанной в разделе «Генерация сертификатов», и, в случае изменения наименования сертификата, произвести настройку компонента, где данный сертификат был задействован. В случае сохранения имени сертификата, необходимо перезапустить сервисы компонентов после замены файлов сертификатов.

Использование сертификатов PKCS#12 в кластере Pangolin#

В версиях Pangolin до 5.3.0 сертификаты и закрытые ключи, используемые для установки TLS/SSL соединений, хранились в кластере Pangolin в формате, не предусматривающем предъявление секрета для доступа к сертификату и/или закрытому ключу. В версии Pangolin 5.3.0 в целях повышения уровня информационной безопасности вводится авторизация для использования сертификатов и закрытых ключей на промышленных стендах.

Сертификаты и закрытые ключи, используемые в версии Pangolin 5.2.1, приведены в таблице ниже и используются для установления TLS-соединения между компонентами кластера Pangolin:

В Pangolin 5.3.0 данные сертификаты и закрытые ключи, за исключением root.crt и patronietcd.crt/patronietcd.key, хранятся в файловой системе в зашифрованных контейнерах PKCS#12, а парольные фразы для их расшифровки - в зашифрованном виде. Ключ для зашифровывания/расшифровывания парольных фраз генерируется на основе параметров сервера, поэтому файлы с парольными фразами не переносимы между узлами кластера Pangolin. На схеме в документе «Детальная архитектура», раздел «Упрощенная архитектурная схема кластера Pangolin с указанием компонентов, использующих сертификаты в PEM-формате или в контейнере PKCS#12» отмечены применяемые для компонентов кластера файлы контейнеров PKCS#12 с расширением .p12.

Примечание:

Следующая ключевая информация хранится в файловой системе в PEM-формате:

• Сертификаты и закрытые ключи etcd (etcd.crt/etcd.key, patronietcd.crt/patronietcd.key), так как этот компонент не поддерживается командой разработки Pangolin.

• Корневой сертификат, которым подписаны сертификаты etcd (может не совпадать с сертификатом, подписавшим сертификаты компонентов PostgreSQL, PgBouncer и Patroni).

• Корневой сертификат root.crt, которым подписаны сертификаты компонентов PostgreSQL, PgBouncer и Patroni.

Для компонентов кластера введены настроечные параметры для установки пути до конфигурационного файла, включающего путь до контейнера PKCS#12 и парольную фразу в зашифрованном виде:

• в конфигурационном файле patroni postgresql.yml параметр pkcs12_config_path в секциях:

  • restapi:

    • pkcs12_config_path: example.p12.cfg;

  • postgresql:authentication:replication/superuser/rewind:

    • pkcs12_config_path: example.p12.cfg;

  • postgresql:parameters:

    • serverssl.pkcs12_config_path: example.p12.cfg;

• в конфигурационном файле СУБД Pangolin postgresql.conf параметр serverssl.pkcs12_config_path;

• в конфигурационном файле PgBouncer pgbouncer.ini параметры client_tls_pkcs12_config_path и server_tls_pkcs12_config_path;

• в строке подключения psql:

  • pkcs12_config_path (переменная окружения PKCS12_CONFIG_PATH);

  • pkcs12_passphrase (переменная окружения PKCS12_PASSPHRASE) - используется для предоставления парольной фразы без ручного ввода в случае, если в файле .p12.cfg отсутствует поле passphrase. Парольная фраза может быть как в открытом, так и в зашифрованном виде. Парольная фраза зашифровывается утилитой pg_auth_password.

Формат конфигурационного файла .p12.cfg:

{
"pkcs12": "",      // Путь до контейнера PKCS#12
"passphrase": ""   // Парольная фраза, зашифрованная ключом на параметрах сервера, либо в открытом виде
}

Для валидации сертификатов компонентов, выполняющих подключение, по умолчанию используется полная цепочка сертификатов в контейнере PKCS#12, если в конфигурационных файлах не прописаны прежние параметры для установки цепочки доверенных сертификатов:

• в конфигурационном файле patroni postgresql.yml в секциях:

  • restapi:

    • cafile: /path/to/CAfile.pem;

    • capath: /path/to/CAdir (параметр введен в версии 5.3.0);

  • postgresql:authentication:replication/superuser/rewind:

    • sslrootcert: /path/to/CAfile.pem;

    • sslrootpath: /path/to/CAdir (параметр введен в версии 5.3.0);

  • postgresql:parameters:

    • ssl_ca_file: /path/to/CAfile.pem;

    • ssl_ca_path: /path/to/CAdir (параметр введен в версии 5.3.0);

• в конфигурационном файле СУБД Pangolin postgresql.conf:

  • ssl_ca_file = '/path/to/CAfile.pem';

  • ssl_ca_path = '/path/to/CAdir' (параметр введен в версии 5.3.0);

• в конфигурационном файле PgBouncer pgbouncer.ini:

  • client_tls_ca_file = /path/to/CAfile.pem;

  • server_tls_ca_file = /path/to/CAfile.pem;

  • client_tls_ca_path = /path/to/CAdir (параметр введен в версии 5.3.0);

  • server_tls_ca_path = /path/to/CAdir (параметр введен в версии 5.3.0);

• в строке подключения psql:

  • sslrootcert = /path/to/CAfile.pem (переменная окружения PGSSLROOTCERT);

  • sslrootpath = /path/to/CAdir (переменная окружения PGSSLROOTPATH (параметр введен в версии 5.3.0)).

Если один из этих параметров указан, то он будет использоваться для инициализации цепочки доверенных сертификатов для проверки сертификатов: со стороны сервера - клиентского сертификата, со стороны клиента - серверного сертификата. В дополнение к приведенным вариантам поиска доверенных сертификатов добавлен поиск среди доверенных сертификатов операционной системы. Настроечный параметр для этого не требуется.

Примечание:

Клиентские компоненты кластера (psql) используют полную цепочку сертификатов в контейнере PKCS#12 для валидации сертификатов, если в строке подключения параметр sslmode установлен в verify-ca или verify-full.

Порядок поиска доверенных сертификатов:

• если не используются параметры, указывающие на файл, либо директорию с сертификатами: сначала в полной цепочке сертификатов из контейнера PKCS#12, затем в в директории ОС, указанной по умолчанию;

• если используются параметры, указывающие на файл и/или директорию с сертификатами: сначала в файле, содержащем один или несколько доверенных сертификатов, затем в директории, если установлена, и, если в них не удалось найти нужный сертификат, то - в директории ОС, указанной по умолчанию.

Возможность конфигурирования сертификатов через PEM-файлы сохранена.

Реализация интерфейса получения контейнера PKCS#12 и парольной фразы к нему выполнена в виде плагинов (подключаемых модулей). В директории установки Pangolin созданы символические ссылки на плагины:

/usr/pangolin-5.3.0/lib/libpkcs12_exporter_plugin_link.so -> plugins/libpkcs12_exporter_plugin.so
/usr/pangolin-5.3.0/lib/libpkcs12_passphrase_plugin_link.so -> plugins/libpkcs12_passphrase_plugin.so

Для контроля сроков действия сертификатов в контейнерах PKCS#12 предоставляется утилита pkcs12_cert_info. Утилита принимает на вход один аргумент: путь до конфигурационного файла со стратегией получения контейнера PCKS#12 и парольной фразы.

Справка по использованию утилиты:

$ pkcs12_cert_info -h
Usage:
pkcs12_cert_info <option>...
Options:
--help                   [-h]     This help
--pkcs12_config_path     [-p]     Path to config file with info how to get PKCS#12 file

Pangolin product version information:
--product_version        prints product name and version
--product_build_info     prints product build number, date and hash
--product_component_hash prints component hash string

Вывод утилиты включает статус наличия закрытого ключа в контейнере, сроки действия сертификата и атрибуты, идентифицирующие сертификат (имя издателя и общее имя сертификата), а также сроки действия цепочки доверенных сертификатов.

Пример запуска утилиты:

$ pkcs12_cert_info -p /pg_ssl/server.p12.cfg
Certificate:
Issuer: CN=Pangolin_intermediate_CA
Validity
Not Before: Nov  8 10:52:13 2022 GMT
Not After : Nov  5 10:52:13 2032 GMT
Subject: CN=srv-0-154.db.dev.sbt

Private key exists

Certificate chain:
Certificate #1:
Issuer: CN=Pangolin_CA
Validity
Not Before: Nov  8 10:52:13 2022 GMT
Not After : Nov  5 10:52:13 2032 GMT
Subject: CN=Pangolin_intermediate_CA
Certificate #2:
Issuer: CN=Pangolin_CA
Validity
Not Before: Nov  8 10:52:12 2022 GMT
Not After : Nov  5 10:52:12 2032 GMT
Subject: CN=Pangolin_CA

Использование сертификатов в локально хранящихся контейнерах PKCS#12 настраивается путем установки следующих параметров в конфигурационных файлах компонентов кластера:

• в конфигурационном файле patroni postgresql.yml параметр pkcs12_config_path в секциях:

  • restapi;

    • pkcs12_config_path: example.p12.cfg;

  • postgresql:authentication:replication/superuser/rewind;

    • pkcs12_config_path: example.p12.cfg;

  • postgresql:parameters;

    • serverssl.pkcs12_config_path: example.p12.cfg;

• в конфигурационном файле СУБД Pangolin postgresql.conf параметр serverssl.pkcs12_config_path;

• в конфигурационном файле pgBouncer pgbouncer.ini параметры client_tls_pkcs12_config_path и server_tls_pkcs12_config_path.

Изменение данных параметров не требует перезапуска компонентов кластера, достаточно выполнить перечитывание конфигурационных файлов.

Если для подключения к СУБД Pangolin требуется предоставить сертификат, и кластер настроен с использованием контейнеров PKCS#12, хранящихся в файловой системе, то в строке подключения psql необходимо указать параметр pkcs12_config_path с путем до конфигурационного файла .p12.cfg, содержащего путь до контейнера PKCS#12 и парольную фразу в зашифрованном виде.

Примеры запуска утилиты psql:

# В файле /pg_ssl/client.p12.cfg установлена парольная фраза.
$ psql "host=$(hostname -f) port=5433 dbname=postgres user=postgres sslmode=verify-full pkcs12_config_path=/pg_ssl/client.p12.cfg"

# В файле /pg_ssl/client.p12.cfg установлена парольная фраза. Путь до /pg_ssl/client.p12.cfg указан через переменную окружения.
$ PKCS12_CONFIG_PATH=/pg_ssl/client.p12.cfg psql "host=$(hostname -f) port=5433 dbname=postgres user=postgres sslmode=verify-full"

# В файле /pg_ssl/client.p12.cfg парольная фраза не установлена. Парольная фраза передается в строке подключения в зашифрованном виде.
$ psql "host=$(hostname -f) port=5433 dbname=postgres user=postgres sslmode=verify-full pkcs12_config_path=/pg_ssl/client.p12.cfg pkcs12_passphrase=$enc$+tsiUlhEuNw4ASyvN6ta0A==$sys$mKb2BejR/MLUBzZQ2PaFs+zXGHDRljMWqX46w0CMmDWtjPDzwbxwNSfDAmVTT3Wu"

# В файле /pg_ssl/client.p12.cfg парольная фраза не установлена. Парольная фраза передается через переменную окружения в зашифрованном виде.
$ PKCS12_PASSPHRASE='$enc$+tsiUlhEuNw4ASyvN6ta0A==$sys$mKb2BejR/MLUBzZQ2PaFs+zXGHDRljMWqX46w0CMmDWtjPDzwbxwNSfDAmVTT3Wu' psql "host=$(hostname -f) port=5433 dbname=postgres user=postgres sslmode=verify-full pkcs12_config_path=/pg_ssl/client.p12.cfg"

# В файле /pg_ssl/client.p12.cfg парольная фраза не установлена. Требуется ручной ввод парольной фразы.
$ psql "host=$(hostname -f) port=5433 dbname=postgres user=postgres sslmode=verify-full pkcs12_config_path=/pg_ssl/client.p12.cfg"
Enter passphrase for PKCS#12 file:
***

Внимание!

В режиме защищенного конфигурирования (secure_config = on) управление параметром СУБД Pangolin serverssl.pkcs12_config_path выполняется на стороне хранилища секретов.

Если для валидации сертификатов не подходит полная цепочка сертификатов в контейнере PKCS#12, предоставляется возможность использования существующих параметров для установки путей к файлам с полными цепочками доверенных сертификатов или введенных в текущей работе новых параметров для установки директории с доверенными сертификатами:

• в конфигурационном файле Patroni postgresql.yml в секциях:

  • restapi;

    • cafile: /path/to/CAfile.pem;

    • capath: /path/to/CAdir;

  • postgresql:authentication:replication/superuser/rewind;

    • sslrootcert: /path/to/CAfile.pem;

    • sslrootpath: /path/to/CAdir;

  • postgresql:parameters;

    • ssl_ca_file: /path/to/CAfile.pem;

    • ssl_ca_path: /path/to/CAdir;

• в конфигурационном файле СУБД Pangolin postgresql.conf:

  • ssl_ca_file = '/path/to/CAfile.pem';

  • ssl_ca_path = '/path/to/CAdir';

• в конфигурационном файле PgBouncer pgbouncer.ini:

  • client_tls_ca_file = /path/to/CAfile.pem;

  • server_tls_ca_file = /path/to/CAfile.pem;

  • client_tls_ca_path = /path/to/CAdir;

  • server_tls_ca_path = /path/to/CAdir;

• в строке подключения psql:

  • sslrootcert = /path/to/CAfile.pem (переменная окружения PGSSLROOTCERT);

  • sslrootpath = /path/to/CAdir (переменная окружения PGSSLROOTPATH).

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

Пример подготовки директории с доверенными сертификатами:

# Добавление корневого сертификата в директорию с доверенными сертификатами
cp /path/to/panglolin.crt /pg_ssl/root_dir
c_rehash /pg_ssl/root_dir

Пример управления доверенными сертификатами операционной системы CentOS 7.9:

# Добавление корневого сертификата с именем Pangolin_CA в хранилище доверенных сертификатов ОС
sudo cp /path/to/panglolin.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust extract
trust list|grep Pangolin_CA
# Удаление корневого сертификата с именем Pangolin_CA из хранилища доверенных сертификатов ОС
sudo rm /etc/pki/ca-trust/source/anchors/panglolin.crt
sudo update-ca-trust extract
trust list|grep Pangolin_CA

Для контроля сроков действия сертификатов в контейнерах PKCS#12 предоставляется утилита pkcs12_cert_info. Утилита принимает на вход один аргумент: путь до конфигурационного файла со стратегией получения контейнера PCKS#12 и парольной фразы. Вывод утилиты включает статус наличия закрытого ключа в контейнере, сроки действия сертификата и атрибуты, идентифицирующие сертификат (имя издателя и общее имя сертификата), а также сроки действия полной цепочки сертификатов.

В пользовательском конфигурационном файле инсталлятора введены следующие параметры:

• Контейнер PKCS#12, помимо сертификата и закрытого ключа, может содержать полную цепочку сертификатов, включая корневой, которыми подписан сертификат. Для упрощения настройки доверенных SSL/TLS сертификатов в кластере предоставляется возможность использовать цепочку сертификатов из контейнера в качестве доверенных, установив параметр pkcs12_use_ca_chain_from_container в true.

  # Флаг определяет, использовать ли полную цепочку сертификатов в контейнере PKCS#12 в качестве доверенной.
  # Если флаг true, то использовать полную цепочку доверенных сертификатов в контейнере, если есть, в качестве доверенной, иначе - false.
  pkcs12_use_ca_chain_from_container: true
  

• Если вариант с использованием полной цепочки сертификатов из контейнера PKCS#12 не подходит для настройки доверенных SSL/TLS сертификатов, предоставляется возможность установки доверенных сертификатов через следующие параметры:

  pg_certs_pwd:
  root_ca_file: "{{ '' | default('/pg_ssl/root.crt', true) }}" # Использовать PEM файл, который может содержать один или несколько доверенных сертификатов
  root_ca_path: "{{ '' | default('/pg_ssl/root_dir', true) }}" # Использовать подготовленную директорию с доверенными сертификатами
  

• Параметры для поддержки использования сертификатов и закрытых ключей из контейнеров PKCS#12, расположенных в файловой системе:

  # Активация получения контейнера PKCS#12 и парольной фразы к нему из файловой системы.
  # Если флаг true, то устанавливаются плагины libpkcs12_passphrase_plugin.so и libpkcs12_exporter_plugin.so.
  # Если флаг false, то используется прежний подход для получения ключевой информации: из файлов в PEM формате. Плагин не устанавливается.
  pkcs12_plugin_enable: true
  
  pg_certs_pwd:
  # Установка параметра p12_path обязательна при активации флага pkcs12_plugin_enable.
  server_p12:
  p12_path: "{{ '' | default('/home/postgres/ssl/server.p12', true) }}" # Путь в файловой системе к контейнеру PKCS#12 с серверной ключевой парой и цепочкой доверенных сертификатов.
  p12_pass: "{{ '' | default('', true) }}" # Парольная фраза для доступа к контейнеру PKCS#12 (server.p12), зашифрованная средствами Ansible Vault (в ходе установки парольная фраза расшифровывается и сохраняется в файл по пути p12_config_path (см. ниже) в зашифрованном виде на ключе, сгенерированном на параметрах сервера). Параметр обязателен в случае установки параметра p12_path.
  p12_config_path: "{{ '' | default('/home/postgres/ssl/server.p12.cfg', true) }}" # Путь к файлу в JSON-формате, содержащему параметр ("passphrase") для получения парольной фразы для доступа к контейнеру PKCS#12, зашифрованную на ключе, сгенерированном на параметрах сервера, и параметр ("pkcs12") для получения контейнера PKCS#12. Параметр обязателен при установке флага pkcs12_plugin_enable в true.
  
  postgres_p12:
  p12_path: "{{ '' | default('/home/postgres/ssl/client.p12', true) }}" # Путь в файловой системе к контейнеру PKCS#12 с клиентской ключевой парой пользователя postgres и цепочкой доверенных сертификатов
  p12_pass: "{{ '' | default('', true) }}"
  p12_config_path: "{{ '' | default('/home/postgres/ssl/client.p12.cfg', true) }}"
  
  pgbouncer_p12:
  p12_secman_integration: true
  p12_path: "{{ '' | default('/home/postgres/ssl/pgbouncer.p12', true) }}" # Путь в файловой системе к контейнеру PKCS#12 с клиентской ключевой парой pgbouncer и цепочкой доверенных сертификатов для подключения к СУБД Pangolin
  p12_pass: "{{ '' | default('', true) }}"
  p12_config_path: "{{ '' | default('/home/postgres/ssl/pgbouncer.p12.cfg', true) }}"
  
  patroni_p12:
  p12_path: "{{ '' | default('/home/postgres/ssl/patroni.p12', true) }}" # Путь в файловой системе к контейнеру PKCS#12 с клиентской ключевой парой и цепочкой доверенных сертификатов для подключения Patroni к СУБД Pangolin
  p12_pass: "{{ '' | default('', true) }}"
  p12_config_path: "{{ '' | default('/home/postgres/ssl/patroni.p12.cfg', true) }}"
  
  etcd_cert: "{{ '' | default('/home/postgres/ssl/etcd.crt', true) }}" # Путь к сертификату для взаимодействия экземпляров ETCD. Может быть подписан сертификатом, отличным от сертификата, подписавшего сертификаты компонентов PostgreSQL, pgbouncer, Patroni. Тогда потребуется указать путь до корневого сертификата в параметре etcd_root_ca.
  etcd_key: "{{ '' | default('/home/postgres/ssl/etcd.key', true) }}" # Путь к приватному ключу для взаимодействия экземпляров ETCD
  etcd_root_ca: "{{ '' | default('/home/postgres/ssl/root_etcd.crt', true) }}" # Корневой сертификат для проверки действительности сертификатов ETCD
  

  Примечания к ключам словаря pg_certs_pwd:

  • p12_path - путь в файловой системе к контейнеру PKCS#12 с ключевой парой и цепочкой доверенных сертификатов.

  • p12_pass - парольная фраза для доступа к контейнеру PKCS#12, зашифрованная средствами Ansible Vault. В ходе установки парольная фраза расшифровывается и сохраняется в файл по пути p12_config_path в зашифрованном виде на ключе, сгенерированном на параметрах сервера.

  • p12_config_path - путь к файлу в JSON-формате .p12.cfg, содержащему поле passphrase с парольной фразой для доступа к контейнеру PKCS#12 и поле pkcs12 с путем до контейнера PKCS#12. Файл формируется инсталлятором: в поле pkcs12 прописывается путь до контейнера PKCS#12 (из параметра p12_path), в поле passphrase помещается парольная фраза перешифрованная ключом, сгенерированным на основе параметров сервера (из параметра p12_pass). Формат файла:

    {
    "pkcs12": "",      // Путь к контейнеру PKCS#12
    "passphrase": ""   // Парольная фраза, зашифрованная ключом на параметрах сервера, либо в открытом виде
    }
    

  • etcd_root_ca - путь к корневому сертификату ETCD. Параметр является обязательным при настройке SSL между узлами etcd.

• Параметр для выбора способа хранения парольной фразы в конфигурационном файле .p12.cfg, путь до которого указывается в параметре p12_config_path: в зашифрованном или в открытом виде.

  # Флаг, определяющий способ хранения парольной фразы к контейнеру PKCS#12.
  # Если флаг true, то парольная фраза зашифровывается ключом, генерируемым на основе параметров сервера, иначе - парольная фраза в открытом виде.
  pkcs12_encrypt_passphrase: true
  

Отключение функциональности#

Отключение функциональности выполняется переконфигурированием кластера на использование сертификатов в PEM-формате без перезапуска кластера. Достаточно выполнить перечитывание конфигурационных файлов.

Управление сертификатами для Platform V Pangolin с SecMan#

Новый функционал, в целях повышения уровня информационной безопасности, обеспечивает хранение и использование контейнеров PKCS#12 и парольных фраз к ним в хранилище секретов и сертификатов Secret Management System (SecMan) и их ротацию на промышленных стендах. Ротация сертификатов, используемых компонентами кластера, осуществляется командой Fetch сертификата на стороне SecMan в случае приближения к окончанию срока действия сертификата. Периодичность вызова Fetch сертификата определяется стороной Pangolin.

В Pangolin появляется несколько новых конфигурационных файлов. Эти файлы используются следующими компонентами кластера: СУБД Pangolin, pgBouncer и Patroni. Каждый компонент использует свой конфигурационный файл. Данные, указанные в файлах, используются для генерации контейнеров PKCS#12, содержащих сертификат и частный ключ. Контейнер создается и хранится в SecMan и возвращается компоненту кластера по запросу.

Описание файла:

{
"pkcs12": {
"name": "",                // Имя роли
"common_name": "",         // CN для сертификата
"email": "",               // Почтовый адрес владельца сертификата
"alt_names": "",           // Альтернативные имена субъектов в списке, разделенном запятыми. Это могут быть имена хостов или адреса электронной почты
"ip_sans": "",             // Альтернативные имена субъекта IP в списке с разделителями-запятыми. Действителен только в том случае, если роль разрешает IP SAN (по умолчанию)
"other_sans": "",          // Настраиваемые SAN со строкой OID/UTF8
"exclude_cn_from_sans": "" // Параметр, включающий/выключающий возможность исключить common_name из DNS или электронной почты SAN
}
}

Примеры файлов для компонентов кластера:

• Pangolin:

  {
    "pkcs12": {
      "name": "server",
      "common_name": "server",
      "email": "test@test.ru",
      "alt_names": "",
      "ip_sans": "",
      "other_sans": "",
      "exclude_cn_from_sans": ""
    }
  }
  

• pgBouncer:

  {
    "pkcs12": {
      "name": "pgbouncer",
      "common_name": "pgbouncer",
      "email": "test@test.ru",
      "alt_names": "",
      "ip_sans": "",
      "other_sans": "",
      "exclude_cn_from_sans": ""
    }
  }
  

• patroni:

  {
    "pkcs12": {
      "name": "patroni",
      "common_name": "patroni",
      "email": "test@test.ru",
      "alt_names": "",
      "ip_sans": "",
      "other_sans": "",
      "exclude_cn_from_sans": ""
    }
  }
  

Для того, чтобы использовать новые конфигурационные файлы, пути к ним нужно прописать в основных конфигурационных файлах:

• В случае кластера. В файле конфигурации patroni postgresql.yml в параметре pkcs12_config_path в секциях restapi, postgresql/authentication/replication, postgresql/authentication/superuser и postgresql/authentication/rewind, а также в параметре pkcs12_config_path в секции postgresql/parameters:

  restapi:
    pkcs12_config_path: "" # Путь до конфигурационного файла в JSON-формате, содержащего данные для генерации сертификата
  postgresql:
    authentication:
      replication:
        pkcs12_config_path: "" # Путь до конфигурационного файла в JSON-формате, содержащего данные для генерации сертификата
  postgresql:
    authentication:
      superuser:
        pkcs12_config_path: "" # Путь до конфигурационного файла в JSON-формате, содержащего данные для генерации сертификата
  postgresql:
    authentication:
      rewind:
        pkcs12_config_path: "" # Путь до конфигурационного файла в JSON-формате, содержащего данные для генерации сертификата
  postgresql:
    parameters:
      serverssl.pkcs12_config_path: "" # Путь до конфигурационного файла в JSON-формате, содержащего данные для генерации сертификата
  

• В случае standalone конфигурации. В файле конфигурации СУБД Pangolin postgresql.conf (для случая конфигурации standalone) в параметре serverssl.pkcs12_config_path:

  serverssl.pkcs12_config_path = "" # Путь до конфигурационного файла в JSON-формате, содержащего данные для генерации сертификата
  

  Внимание!

  При включенной защите параметров конфигурационный параметр serverssl.pkcs12_config_path должен быть под защитой, а его значение должно устанавливаться только через SecMan.

• В файле конфигурации pgbouncer pgbouncer.ini в параметре client_tls_pkcs12_config_path и server_tls_pkcs12_config_path:

  client_tls_pkcs12_config_path = "" # Путь до конфигурационного файла в JSON-формате, содержащего данные для генерации сертификата
  server_tls_pkcs12_config_path = "" # Путь до конфигурационного файла в JSON-формате, содержащего данные для генерации сертификата
  

Отключению функциональности#

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

Генерация и установка постоянного пароля технологической УЗ#

Расширение psql_rotate_password добавляет функцию генерации случайного пароля, удовлетворяющего парольной политике.

Установка расширения psql_rotate_password#

Установка расширения производится установщиком.

Параметры установщика (указаны значения по умолчанию):

rotate_password.enable: false

rotate_password.num_rounds: 20

Далее рассматривается, что делается в установщике или что необходимо сделать при ручной установке:

1. Установка расширения. Распакуйте файлы расширения в каталог с расширениями, например:

   # tar xzf psql_rotate_password-<version>.tar.gz --directory $(pg_config --sharedir)/extension
   

   Необходимо убедиться, что используется подходящая утилита pg_config.

2. Создание расширения psql_rotate_password. Установите расширение (в схему ext по умолчанию):

   postgres=# CREATE EXTENSION psql_rotate_password schema ext;
   

   Рекомендуется установка для всех БД, для которых необходимо расширение.

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

Настройка параметров#

К настройке предлагается два параметра postgres.conf:

• rotate_password.num_rounds = '20' - количество попыток генерации пароля;

• rotate_password.valid_roles = '' - список пользователей, которые могут быть указаны в параметре этой функции.

Использование функции ротации паролей#

Входные параметры функции rotate_password:

• (обязательный) Oid или имя пользователя;

• (не обязательный) длина пароля (или пароль будет сгенерирован по минимальной длине пароля согласно парольным политикам +0-5 символов).

Выходной параметр: сгенерированный пароль.

Возможные ошибки:

• исчерпано количество попыток генерации пароля;

• синтаксические параметры парольной политики пользователя вместе с переданным параметром длины пароля не позволяют сгенерировать пароль, соответствующий требованиям;

• пользователь не входит в rotate_password.valid_roles;

• ошибка синтаксического анализа rotate_password.valid_roles;

• не найден пользователь.

Отключение функциональности#

Отключение функциональности производится путем удаления расширения:

DROP EXTENSION psql_rotate_password;

Настройка подключения к SecMan для Platform V Pangolin#

Описываемая функциональность:

• обеспечивает настройку параметров подключения к Хранилищу секретов SecMan;

• упрощает процесс изменения параметров для работы с Хранилищем секретов;

• обеспечивает возможность обнаружения ошибок в параметрах подключения к Хранилищу секретов на этапе конфигурирования доступа;

• обеспечивает настройку системы для работы с Хранилищем сертификатов;

• упрощает использование утилиты в автоматизированных скриптах.

• обеспечивает настройку проверки серверного сертификата Хранилища секретов.

Дополнительные параметры для работы с Хранилищем секретов SecMan#

Для подключения и работы с Хранилищем секретов SecMan используются дополнительные параметры:

• Доменное имя - добавляется возможность указания сервера хранилища через доменное имя, а не только через IP-адрес.

• Префикс для пути хранения секретов - добавляется возможность указания префикса для пути хранения kv секретов, согласно иерархии секретов. Префикс должен содержать движок секретов. Путь, используемый для доступа к секретам: /v1/{prefix/}data/{domain/}{cluster id/}{subdomain/}secret_name. Пример заданного префикса: CI03170154_CI03214758/I/SERV/GLOB/SERV/KV.

• Точка входа для urn аутентификации: /auth/точка_входа/login/. Указание точки входа позволяет авторизоваться по LDAP для типа авторизации Userpass (пример, auth/ad/sigma.sbrf.ru/login/). По умолчанию используются:

  • approle - для авторизации AppRole;

  • userpass - для авторизации Userpass.

• Тенант хранилища (x-vault-namespace) - при взаимодействии с Хранилищем секретов по HTTPS тенант указывается в header запроса.

• Протокол взаимодействия с Хранилищем секретов (HTTP или HTTPS, по умолчанию HTTPS).

Утилита setup_kms_credentials позволяет сохранять дополнительные параметры для работы с Хранилищем секретов SecMan. Дополнительные параметры имеют значения по умолчанию или расширяют текущие типы данных. Это обеспечивает обратную совместимость формата шифрованного файла /etc/postgres/enc_connection_settings.cfg (владелец: kmadmin_pg, группа: kmadmin_pg, права: -rw-r--r--). Процесс добавления новых параметров не меняется.

Редактирование параметров для работы с Хранилищем секретов#

В утилиту setup_kms_credentials добавляется новый режим, позволяющий редактировать параметры для работы с Хранилищем секретов в существующих записях. Администратор безопасности запускает утилиту setup_kms_credentials в режиме редактирования параметров. Если хранилище содержит более одной записи, то необходимо указать, какую запись требуется обновить (список записей можно получить в режиме просмотра). После чего поочередно вводятся обновленные параметры. Если пропустить обновление параметра, то он сохраняет предыдущее значение.

Просмотр сохраненных параметров для работы с Хранилищем секретов#

В утилиту setup_kms_credentials добавляется новый режим, позволяющий просматривать сохраненные параметры для работы с Хранилищем секретов. Администратор безопасности запускает утилиту setup_kms_credentials в режиме просмотра параметров и получает список сохраненных параметров (за исключением паролей).

По умолчанию в режиме просмотра происходит проверка сохраненных параметров подключения к Хранилищу секретов. Проверяются только параметры подключения к Хранилищу секретов. Параметры доступа к секретам в данном режиме не проверяются. Чтобы отключить проверку параметров в режиме просмотра, необходимо указать ключ --no-check.

Если в режиме проверки параметров указать ключ --debug, то утилита дополнительно выведет в лог информацию о взаимодействии с Хранилищем секретов (url запроса, http код ответа и т.п.).

Очистка хранилища параметров подключения#

В утилиту setup_kms_credentials добавляется новый режим, позволяющий удалять записи с параметрами для работы с Хранилищем секретов. Для удаления записи необходимо указать ее номер (список записей можно получить в режиме просмотра).

Настройка параметров для работы с Хранилищем сертификатов#

В утилиту setup_kms_credentials добавляется аргумент --purpose, позволяющий настраивать параметры для работы с Хранилищем сертификатов. Аргумент может принимать следующие значения:

• secrets - настройка параметров для работы с Хранилищем секретов. Параметры хранятся в шифрованном файле /etc/postgres/enc_connection_settings.cfg (владелец: kmadmin_pg, группа: kmadmin_pg, права: -rw-r--r--);

• certs - настройка параметров для работы с Хранилищем сертификатов. Параметры хранятся в шифрованном файле /etc/postgres/enc_connection_settings_cert.cfg (владелец: kmadmin_pg, группа: kmadmin_pg, права: -rw-r--r--).

Аргумент --purpose возможно указывать во всех режимах работы утилиты setup_kms_credentials. Если аргумент не указан, то утилита производит настройку параметров для работы с Хранилищем секретов.

Указание параметров для работы с Хранилищем секретов через аргументы командной строки#

В утилиту setup_kms_credentials добавлена возможность передачи параметров (кроме пароля и идентификатора секрета) через аргументы командной строки. Пароль или идентификатор секрета задаются в интерактивном режиме или через перенаправление потока ввода.

Режим позволяет упростить использование утилиты в автоматизированных скриптах.

Настройка проверки серверного сертификата Хранилища секретов#

При взаимодействии с Хранилищем секретов по протоколу HTTPS происходит проверка серверного сертификата. Проверка осуществляется на основании корневого сертификата, путь к которому задается с помощью директории или файла в утилите setup_kms_credentials. Если не задавать путь к корневому сертификату, то его поиск будет осуществляться в системной директории с сертификатами.

Отключение функциональности#

Настройка параметров подключения производится при первоначальной настройке кластера Pangolin или при изменении настроек хранилища секретов (или сертификатов). Специальные команды для отключения функциональности отсутствуют.

Утилита setup_kms_credentials#

Утилита setup_kms_credentials позволяет добавлять, редактировать, удалять и проверять параметры подключения к Хранилищам секретов и сертификатов.

Для вывода доступных режимов работы setup_kms_credentials необходимо выполнить:

setup_kms_credentials --help
Usage:
setup_kms_credentials [mode] <option>...
Options:
--purpose      [-s]     выбор типа хранилища: certs - хранилище сертификатов или secrets - хранилище секретов, значение по умолчанию: secrets
--cluster      [-c]     имя кластера
--host         [-h]     доменное имя или ip адрес хранилища
--port         [-p]     номер порта хранилища
--protocol     [-l]     протокол обмена данными: http (1) или https (2), протокол по умолчанию: https
--prefix       [-x]     путь до хранения секретов на сервере (префикс для пути хранения секретов, по умолчанию: kv)
--namespace    [-n]     тенант хранилища, по умолчанию: пусто
--type         [-t]     тип авторизации: Userpass Auth Method (1) или AppRole Auth Method (2)
--auth         [-a]     точка входа для аутентификации, по умолчанию: userpass
--id           [-i]     логин или  id роли
--root-ca      [-r]     файл или директория, содержащая корневой сертификат для проверки хранилища секретов/сертификатов
--skip-confirm          редактирование или удаление без подтверждения
--index                 индекс записи для режимов редактирования/удаления
--plain                 простой вывод
--no-check              не проверять подключение
--debug                 показать информацию о взаимодействии с Хранилищем
--help                  эта страница помощи

Modes:
setup  - ввести новый набор данных для хранилища (хранилищ) секретов или сертификатов, поведение по умолчанию
show   - показать текущий набор параметров подключений к хранилищам секретов/сертификатов (без паролей и id секретов)
add    - добавить новую запись в набор параметров подключений к хранилищам секретов/сертификатов
delete - удалить запись из набора параметров подключений к хранилищам секретов/сертификатов по номеру записи
edit   - редактировать запись из набора параметров подключений к хранилищам секретов/сертификатов по номеру записи

Pangolin product version information:
--product_version        показать название продукта и версию
--product_build_info     показать номер сборки, дату сборки и хеш
--product_component_hash показать хеш компонента

Для работы с хранилищем сертификатов, при вызове setup_kms_credentials необходимо указывать аргумент --purpose=certs.

Интерактивный режим добавления параметров#

/usr/pangolin-5.2.1/bin/setup_kms_credentials --purpose=certs add
Enter IP address or Domain Name of Secrets storage:
<IP-адрес>
Enter port:
<PID>
Choose protocol type or leave empty to use default (https):
1. http
2. https
   1
   Enter secrets prefix or leave empty to use default (kv):
   <Префикс>
   Enter Secrets storage namespace or leave empty:
   CI00000000_CI00000000
   Choose credentials type:
1. Userpass Auth Method
2. AppRole Auth Method
   1
   Enter auth point or leave empty to use default (userpass):
   userpass
   Enter login:
   adminencryption
   Enter password:
********
Confirm password:
********
Credentials for Secrets storage has been added successfully

Режим добавления параметров через аргументы командной строки#

/usr/pangolin-5.2.1/bin/setup_kms_credentials --purpose=certs add -c test -h <IP-адрес> -p <PID> -l 2 -x <Префикс> -n CI00000000_CI00000000 -t 1 -a userpassTest -i adminencryption -r /pg_ssl
Enter password:
********
Confirm password:
********
Credentials for Secrets storage has been added successfully

Режим просмотра добавленных параметров подключения#

/usr/pangolin-5.2.1/bin/setup_kms_credentials --purpose=certs show
Pangolin cluster ID: test
Root CA path: /pg_ssl
+---------------------------------------------------------------------------------------------------------------------------------------+
|  # | protocol |       host | port | prefix |             namespace |            cred type | auth point |              id |     status |
-----+----------+------------+------+--------+-----------------------+----------------------+------------+-----------------+-------------
|  0 |     http | <IP-адрес> | <PID> | <Префикс> | CI00000000_CI00000000 | Userpass Auth Method |   userpass | adminencryption |         Ok |
|  1 |    https | <IP-адрес> | <PID> | <Префикс> | CI00000000_CI00000000 | Userpass Auth Method |   userpass | adminencryption |         Ok |
+---------------------------------------------------------------------------------------------------------------------------------------+

Режим редактирования добавленных параметров подключения#

В режиме просмотра необходимо определить номер записи, которую следует отредактировать. Например, нужно отредактировать первую запись - изменить тенант хранилища. Передаем аргументом индекс записи: 1 и новый тенант хранилища CI00000001_CI00000001:

/usr/pangolin-5.2.1/bin/setup_kms_credentials --purpose=certs edit --index=1 --plain -n CI00000001_CI00000001
Enter password:
********
Confirm password:
********
+---------------------------------------------------------------------------------------------------------------------------------------+
|  # | protocol |       host | port | prefix |             namespace |            cred type | auth point |              id |     status |
-----+----------+------------+------+--------+-----------------------+----------------------+------------+-----------------+-------------
|  0 |     http | <IP-адрес> | <PID> | <Префикс> | CI00000000_CI00000000 | Userpass Auth Method |   userpass | adminencryption |        N/A |
|  1 |    https | <IP-адрес> | <PID> | <Префикс> | CI00000001_CI00000001 | Userpass Auth Method |   userpass | adminencryption |        N/A | <update data/password>
|  1 |    https | <IP-адрес> | <PID> | <Префикс> | CI00000000_CI00000000 | Userpass Auth Method |   userpass | adminencryption |        N/A | <original>
+---------------------------------------------------------------------------------------------------------------------------------------+
Do you want to edit data? (yes/no)?:
yes
Credentials for Secrets storage has been edited successfully

Режим удаления добавленных параметров подключения#

В режиме просмотра необходимо определить номер записи, которую следует удалить. Например, нужно удалить нулевую запись.

/usr/pangolin-5.2.1/bin/setup_kms_credentials --purpose=certs delete --index=0 --plain
+---------------------------------------------------------------------------------------------------------------------------------------+
|  # | protocol |       host | port | prefix |             namespace |            cred type | auth point |              id |     status |
-----+----------+------------+------+--------+-----------------------+----------------------+------------+-----------------+-------------
|  0 |     http | <IP-адрес> | <PID> | <Префикс> | CI00000000_CI00000000 | Userpass Auth Method |   userpass | adminencryption |        N/A | <delete>
|  1 |    https | <IP-адрес> | <PID> | <Префикс> | CI00000001_CI00000001 | Userpass Auth Method |   userpass | adminencryption |        N/A |
+---------------------------------------------------------------------------------------------------------------------------------------+
Do you want to remove the record? (yes/no)?:
yes
Credentials for Secrets storage has been removed successfully

Архивирование и восстановление#

Для архивирования и восстановления в СУБД Pangolin используется система резервного копирования и репликации. Она включает в себя утилиты для резервного копирования и восстановления (например, pg_probackup), а также для потоковой и логической репликации.

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

Функции системы:

• резервное копирование и восстановление данных Pangolin;

• создание полной резервной копии по расписанию;

• снятие резервных копий с любого сервера кластера высокой доступности;

• возможность хранения метаданных на отдельном служебном сервере;

• дедупликация;

• восстановление состояния на определенный момент времени (в соответствии с политиками хранения копий);

• обеспечение соответствия нефункциональным требованиям к системам уровня Mission critical.

В этом разделе рассматриваются следующие сценарии восстановления из резервной копии:

• Полное восстановление кластера. Например, кластер полностью неработоспособен и требуется восстановление из последней резервной копии всего кластера.

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

• Создание резервного сервера. Например, в результате сбоя на предыдущем резервном сервере БД на нем оказывается недоступна, требуется восстановление из резервной копии.

Описание процесса#

В качестве сетевой централизованной системы хранения резервных копий используется служебная база данных (далее - «Каталог»). Интеграция с Каталогом позволяет выполнять резервное копирование экземпляров Pangolin и связанных с ними файлов журналов записи с опережением (файлы Write Ahead Log, WAL).

Резервное копирование файлов WAL обеспечивает целостность данных Pangolin. Такая резервная копия позволяет использовать таблицы базы данных во время сеанса без каких-либо ограничений.

Резервное копирование с ведомого сервера кластера производится в автоматизированном режиме с помощью клиентского приложения (Далее - «Агент»). Выполняется либо снятие полной резервной копии, либо архива файлов WAL, накопившихся со времени последней резервной копии.

Восстановление инициируется пользователем и предполагает ручное указание параметров восстановления. Pangolin потребуется учетная запись с правами на создание резервных копий: отдельная роль с минимальными правами, необходимыми для выбранной стратегии копирования. Управление функциями резервного копирования Pangolin выполняется специалистами по резервному копированию.

Поддержка резервного копирования настраивается в конфигурационном файле custom_file.yml через параметр SRC (резервная копия системы).

Подход к резервному копированию#

Data Protector выполняет резервное копирование экземпляров Pangolin и связанных файлов WAL, обеспечивая таким образом полное копирование данных. Такой тип резервного копирования позволяет использовать БД во время сеанса снятия резервной копии, в том числе вносить изменения в таблицы.

Поддерживаются следующие типы резервного копирования:

• полная резервная копия, включающая все базы данных в экземпляре Pangolin;

• резервное копирование транзакций в виде файлов WAL, сохраненных со времени предыдущего полного резервного копирования или резервного копирования транзакций.

Необходимая конфигурация параметров Pangolin для начала процесса резервного копирования:

wal_level = replica (или выше)
hot_standby = on
full_pages_writes = on
archive_mode = always
archive_command = 'pg_probackup-11 archive-push -B <локальный каталог копий> --instance <экземпляр> --wal-file-path=%p --wal-file-name=%f --compress --overwrite -j 4'
archive_timeout = 180

Процедуру снятия резервной копии можно автоматизировать с помощью Python-скрипта, расположенного в директории /opt/omni/lbin/. Этот скрипт автоматизирует вызовы pg_start_backup() и pg_stop_backup() и управляет процессом снятия полной резервной копии. При запуске скрипта будет создан отдельный процесс с подключением libpq.

Примечание:

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

Ошибки, возникающие в процессе копирования, заносятся в журнал Pangolin, в приложение backup_session и в файл backup_manager.log в каталоге резервного копирования.

Подход к восстановлению данных#

Pangolin поддерживает различные способы восстановления данных. Перед восстановлением данных необходимо определить следующие аспекты процесса восстановления:

• Область действия:

  • Восстановление всего экземпляра - в таком случае восстановление производится отдельно на каждый сервер, после чего выполняется синхронизация с помощью Patroni.

  • Восстановление ведомого сервера - в таком случае восстановление происходит из резервной копии на последний возможный момент времени.

• Расположение восстанавливаемых данных:

  • Исходное расположение.

  • Другой путь на исходном клиенте.

  • Другой клиент (на него тоже потребуется установить Pangolin).

• Восстановление на определенный момент времени, при условии наличия соответствующей цепочки восстановления (включая полный образ резервной копии и резервную копию соответствующих файлов WAL):

  • На время последней резервной копии транзакции (откат до последнего возможного состояния);.

  • На определенный момент времени по выбору (восстановление на момент времени с повтором).

  • На момент выбранного успешного полного или резервного копирования транзакции.

Необходимая точка восстановления задается через файл конфигурации Patroni, раздел recovery_conf:

• recovery_target_time = <timestamp>;

• recovery_target_inclusive = true (восстанавливать данные до указанной временной отметки включительно (true) или не доходя до нее (false));

• restore_command = <путь к архиву WAL файлов>.

Пока идет процедура восстановления из резервной копии, СУБД должна быть остановлена.

Подход к мониторингу резервных копий#

Часть описанной функциональности реализована через расширение pgse_backup. Это расширение создает схему backup и все остальные объекты.

Для безопасного считывания файлов с историей (backup_state, wal_backup_state) используется функция Pangolin SECURITY DEFINER. Эта функция разрешает доступ к файлам с историей без прав суперпользователя, но в пределах строго фиксированного каталога, чтобы исключить доступ к чтению посторонних файлов.

Пример функции для backup.read_data_history:

CREATE OR REPLACE FUNCTION backup.read_data_history()
RETURNS SETOF backup.data_history_row_type AS

$$

        DECLARE

    filename text;
    json_data text;

        BEGIN

    filename := (SELECT setting FROM backup.settings WHERE name = 'dir') || '/backup_state';
    json_data := pg_read_file(filename);
    if json_data = '' then

        return;
    end if;

    return QUERY SELECT * FROM json_populate_recordset(null::backup.data_history_row_type, json_data::json);


        EXCEPTION

    WHEN undefined_file THEN

        return;
    WHEN invalid_text_representation THEN

        RAISE EXCEPTION '%', SQLERRM
            USING DETAIL = format('history file "%s" might be corrupted', filename),
                  HINT = 'you may need to clean up all backup history with "SELECT backup.reset_history()"';

        END;
$$
LANGUAGE plpgsql SECURITY DEFINER;

Директория, в которой хранятся файлы истории и к которой предоставляется доступ через SECURITY DEFINER, задается через таблицу backup.settings. Эта таблица должна быть доступна только владельцу расширения (Администратору БД)

 CREATE TABLE backup.settings(name text, setting text);

    INSERT INTO backup.settings(name, setting) VALUES ('dir', '/pgarclogs/' ||

-- get major version (11, 12, ...)

(SELECT split_part((SELECT setting FROM pg_settings WHERE name = 'server_version'), '.', 1)));

Для контроля состояния резервных копий используются три представления: backup.data_history, backup.wal_history и backup.history. Представление backup.history сверяет data_history и wal_history и показывает итоговое состояние, как на таблице ниже.

CREATE TYPE backup.data_history_row_type AS (
session_id text,
state text,
tli integer,
start_time text,
start_lsn text,
stop_time text,
stop_lsn text,
duration text,
stop_walfile text COLLATE "C"

);


        CREATE TYPE backup.wal_history_row_type AS (
    session_id text,
    state text,
    start_time text,
    stop_time text,
    duration text,
    info json
);


        CREATE VIEW backup.data_history AS


        SELECT

    s.session_id,
    s.state,
    s.tli,
    TO_TIMESTAMP(s.start_time, 'YYYY-MM-DD HH24:MI:SS') as start_time,
    s.start_lsn,
    TO_TIMESTAMP(s.stop_time, 'YYYY-MM-DD HH24:MI:SS') as stop_time,
    s.stop_lsn,
    TO_TIMESTAMP(s.stop_time, 'YYYY-MM-DD HH24:MI:SS')
        - TO_TIMESTAMP(s.start_time, 'YYYY-MM-DD HH24:MI:SS') as duration,
    s.stop_walfile

        FROM backup.read_data_history() AS s;


        CREATE VIEW backup.wal_history AS


        SELECT

    s.session_id,
    s.state,
    TO_TIMESTAMP(s.start_time, 'YYYY-MM-DD HH24:MI:SS') as start_time,
    TO_TIMESTAMP(s.stop_time, 'YYYY-MM-DD HH24:MI:SS') as stop_time,
    TO_TIMESTAMP(s.stop_time, 'YYYY-MM-DD HH24:MI:SS')
        - TO_TIMESTAMP(s.start_time, 'YYYY-MM-DD HH24:MI:SS') as duration,
    s.info

        FROM backup.read_wal_history() AS s;


        CREATE VIEW backup.history AS


        SELECT

    d.session_id,
    -- $PGDATA has been successfully backed up, look for a valid WAL backup

    CASE WHEN d.state = 'completed' THEN

        COALESCE(
            -- WAL backup done successfully -> mark full backup record as 'completed'

            (SELECT 'completed' FROM backup.wal_history w
                 WHERE
                    w.state = 'completed' AND

                    w.start_time >= d.stop_time AND

                    d.stop_walfile >= w.info -> d.tli::text ->> 'min_segno' AND

                    d.stop_walfile <= w.info -> d.tli::text ->> 'max_segno' LIMIT 1),
            -- WAL backup has not been completed yet, but WAL session was started -> show this in our history

            (SELECT 'wal_backup_started' FROM backup.wal_history w
                 WHERE
                    w.state = 'started' AND

                    w.start_time >= d.stop_time AND

                    d.stop_walfile >= w.info -> d.tli::text ->> 'min_segno'::text COLLATE "C" AND

                    d.stop_walfile <= w.info -> d.tli::text ->> 'max_segno'::text COLLATE "C" LIMIT 1),
            -- WAL backup has not been started (or some WAL session failed) -> show that we are currently waiting for a session

            'waiting_for_wal_backup')
    ELSE d.state END as state,
    d.tli,
    d.start_time,
    d.start_lsn,
    d.stop_time,
    d.stop_lsn,
    d.duration

        FROM backup.data_history d;

Функция очистки истории (должна быть доступна только Администраторам БД):

        CREATE OR REPLACE FUNCTION backup.reset_history()
    RETURNS void AS

$x$

        DECLARE

    dir text := (SELECT setting FROM backup.settings WHERE name = 'dir');
    data_dir text := dir || '/backup_state';
    wal_dir text := dir || '/wal_backup_state';

        BEGIN

    EXECUTE format('COPY (SELECT
        ''''
        ) TO %L', data_dir);
    EXECUTE format('COPY (SELECT
        ''''
        ) TO %L', wal_dir);

        END;
$x$
LANGUAGE plpgsql SECURITY DEFINER;

Развертывание на КТС#

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

1. Создайте директорию PGBACKUP: /pgbackup/11.

2. Установите pg_probackup.

3. Создайте локальный каталог резервных копий: pg_probackup-11 init -B $PGBACKUP. В случае, если каталог не пустой, операция завершится с ошибкой, поэтому перед установкой каталог должен быть очищен.

4. Определите копируемый экземпляр резервных копий: pg_probackup-11 add-instance -B $PGBACKUP -D $PGDATA --instance <название экземпляра>.

5. Установите параметры БД:

   wal_level = replica
   hot_standby = on
   full_pages_writes = on
   archive_mode = always
   archive_command = 'pg_probackup-11 archive-push -B <локальный каталог копий> --instance <инстанс> --wal-file-path=%p --wal-file-name=%f --compress --overwrite -j 4'
   archive_timeout = 180
   

6. Добавьте параметры работы pg_probackup: pg_probackup-11 set-config -B $PGBACKUP -D $PGDATA --instance <название инстанса> -d <имя_базы> -h <локальный сервер> -p <локальный порт> -U <имя_пользователя>.

Примечание:

Установка СРК посредством ДИ выполняется автоматически.

Ролевая модель#

В силу особенностей работы Data Protector необходима выделенная роль для проведения процедуры резервного копирования со следующими разрешениями:

        BEGIN;
CREATE ROLE masteromni WITH LOGIN;
GRANT USAGE ON SCHEMA pg_catalog TO masteromni;
GRANT EXECUTE ON FUNCTION pg_catalog.current_setting(text) TO masteromni;
GRANT EXECUTE ON FUNCTION pg_catalog.pg_is_in_recovery() TO masteromni;
GRANT EXECUTE ON FUNCTION pg_catalog.pg_start_backup(text, boolean, boolean) TO masteromni;
GRANT EXECUTE ON FUNCTION pg_catalog.pg_stop_backup(boolean, boolean) TO masteromni;
GRANT EXECUTE ON FUNCTION pg_catalog.pg_create_restore_point(text) TO masteromni;
GRANT EXECUTE ON FUNCTION pg_catalog.pg_switch_wal() TO masteromni;
GRANT EXECUTE ON FUNCTION pg_catalog.pg_last_wal_replay_lsn() TO masteromni;
GRANT EXECUTE ON FUNCTION pg_catalog.txid_current() TO masteromni;
GRANT EXECUTE ON FUNCTION pg_catalog.txid_current_snapshot() TO masteromni;
GRANT EXECUTE ON FUNCTION pg_catalog.txid_snapshot_xmax(txid_snapshot) TO masteromni;
GRANT EXECUTE ON FUNCTION pg_catalog.pg_control_checkpoint() TO masteromni;

        COMMIT;

В файле pg_hba.conf необходимо разрешить подключение к кластеру баз данных пользователю с именем masteromni.

Восстановление БД из резервной копии#

Внимание!

Для восстановления необходима новая чистая установка Pangolin, полученная в ДИ либо созданная вручную. При наличии доступа к изначальному кластеру, проверить, что полная резервная копия существует:

SELECT * FROM backup.history;

Внимание!

Ниже по тексту используются в качестве параметров clustername и new_clustername. Это общие обозначения, которые необходимо заменить действительными. Получить их можно, например, командой:

etcdctl ls /service

clustername - имя кластера на новом сервере, new_clustername - имя кластера для сервера, с которого снята резервная копия.

system-identifier для файла pg_probackup.conf можно получить на сервере, с которого снята резервная копия командой (clustername в данном случае нужно заменить на имя кластера):

etcdctl get /service/clustername/initialize

Для восстановления БД кластера cluster-patroni-etcd-pgbouncer из резервной копии:

1. Остановите сервис patroni сначала на Standby, потом на Active:

   sudo systemctl stop patroni
   

2. Очистите каталоги data и tablespaces на Standby и Active:

   rm -rf /pgdata/04/data
   rm -rf /pgdata/04/tablespaces
   

3. Очистите хранилище etcd (clustername замените на действительное имя кластера):

   etcdctl rm -r /service/clustername
   

4. Исправьте конфигурационный файл patroni (clustername и new_clustername замените на действительные Active и Standby, добавьте секцию recovery_conf на Active):

   scope: new_clustername
   …
   …
   …
   parameters:
   archive_mode: 'always'
   archive_command: '/usr/pgsql-se-04/bin/pg_probackup archive-push -B /pgarclogs/04 --instance new_clustername --wal-file-path=%p --wal-file-name=%f --compress --overwrite -j 4 --batch-size=100'
   …
   …
   …
   wal_sync_method: 'fsync'
   work_mem: '16384kB'
   …
   …
   is_tde_on: 'off'
   recovery_conf:
   recovery_target_timeline: latest
   standby_mode: off
   restore_command: /usr/pgsql-se-04/bin/pg_probackup archive-get -B /pgarclogs/04 --instance new_clustername --wal-file-path=%p --wal-file-name=%f -j 4 --batch-size=100
   …
   …
   …
   

5. Восстановите на новый сервер со старого каталоги /pgarclogs/04, /pgdata/04/data, /pgdata/04/tablespaces.

6. Скопируйте файл /pgarclogs/04/backups/clustername/pg_probackup.conf в /pgarclogs/04/backups/new_clustername/pg_probackup.conf и исправьте в нем system-identifier (clustername и new_clustername замените на действительные имена кластеров):

   # Backup instance information
   pgdata = /pgdata/04/data
   system-identifier = 6855546122949875180
   xlog-seg-size = 16777216
   # Connection parameters
   pgdatabase = postgres
   pghost = 10.110.34.117
   pgport = 5433
   pguser = backup_user
   

   Примечание:

   IP-адрес и порт (pghost и pgport) указаны в качестве примера.

7. Запустите сервис patroni на Active и убедитесь, что БД запущена и загружаются файлы журналов:

   sudo systemctl start patroni
   less /pgerrorlogs/clustername/postgresql.log
   

8. Запустите сервис patroni на Standby, дождитесь синхронизации и убедитесь, что кластер перешел в синхронный режим:

   sudo systemctl start patroni
   patronictl -c /etc/patroni/postgresql.yml list