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

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

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

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

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

Примечание:

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

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

В данном разделе приведены примеры команд для получения используемой версии Pangolin. Примеры команд одинаковы для любой из используемых ОС.

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

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

Команда:

pg_ctl --product_version

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

Platform V Pangolin 5.2.0

где:

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

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

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

Команда:

pg_ctl --version

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

pg_ctl (PostgreSQL) 13.4

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

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

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

  Команда:

  SELECT product_version();
  

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

      product_version
  ---------------------------
  Platform V Pangolin SE 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)
  

  Примечание:

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

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

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

Команда:

pg_ctl --product_build_info

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

build 54 (22:27:09 05.02.2022) commit {хеш}

где:

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

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

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

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

Команда:

SELECT product_build_info();

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

build 54 (22:27:09 05.02.2022) commit {хеш}

Примечание:

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

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

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

Команда:

pg_ctl --product_component_hash

Интерфейс администратора безопасности 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 Pangolin), так как вероятность изменения SQL интерфейса меньше.

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

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

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

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

• cluster — в файле /etc/pangolin-manager/postgres.yml.

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

Внимание!

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

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

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

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

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

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

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

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

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

Включение механизма (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. Активации парольной политики.

Функции создания и активации парольной политики описаны в документе «Список PL/SQL функций продукта», раздел «Парольные политики».

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

Выполняется соответствующей SQL-функцией (см. «Список PL/SQL функций продукта» раздел «Парольные политики»).

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

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

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

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

Подробнее о функциях для данной функциональности в документе «Список PL/SQL функций продукта», раздел «Парольные политики».

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

Выполняется соответствующей SQL-функцией (см. «Список PL/SQL функций продукта» раздел «Парольные политики»).

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

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

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

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

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

Подробнее о функциях в документе «Список PL/SQL функций продукта», раздел «Парольные политики».

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

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

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

Примечание:

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

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

Разблокирование и восстановление работы кластера#

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

   host1$ sudo journalctl --since "5 hours ago" -u pangolin-manager | grep "i am " | tail -1
   Aug 04 22:38:17 <Адрес сервера> 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 pangolin-manager | grep "i am " | tail -1
   Aug 04 22:38:07 <Адрес сервера> python3[21032]: 2020-08-04 22:38:07,814 INFO: no action. i am a secondary and i am following a leader
   

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

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

   host1$ sudo systemctl stop pangolin-manager
   

3. Запустите Pangolin в однопользовательском режиме:

   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. Запустите службу Pangolin Manager.:

   host1$ sudo systemctl start pangolin-manager
   

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

   host1$ list
   + Cluster: clustername (6857170778029161231) ----------------------------------------+--------------+---------+----+-----------+
   |                 Member                |                    Host                    |     Role     |  State  | TL | Lag in MB |
   +---------------------------------------+--------------------------------------------+--------------+---------+----+-----------+
   | <Адрес сервера>                       | <Адрес сервера>:5433                       | Sync Standby | running |  4 |         0 |
   | <Адрес сервера>                       | <Адрес сервера>: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 поддерживает несколько типов авторизации и аутентификации пользователей и сервисов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание:

Увеличение значения auth_failure_threshold потенциально увеличит количество обработок отказов в подключении и соответствующих записей в логах, при обычных условиях эксплуатации это не должно приводить к отказу Pangolin Pooler.

Увеличение auth_inactivity_period позволяет избежать увеличения обработок отказов в подключении на указанное время.

Одной единицей подключения (клиентом) считается соединение с определенным набором (сочетанием) параметров: логин/пароль пользователя, имя БД для подключения, IP-адрес клиента, тип соединения. Клиент считается ранее пытавшимся подключиться, по этому же сочетанию, только без передачи пароля. Блокировка пользователя происходит по этим учетным данным подключения, то есть любое изменение данного сочетания будет считаться попыткой соединения нового пользователя.

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

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

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

Примечание:

Общее количество соединений не должно превышать значения authentication_max_workers, раздел «Конфигурирование сквозной аутентификации в Pangolin».

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

[databases]
* = host=<IP-адрес> 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] конфигурационного файла Pangolin Pooler.

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

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

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

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

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

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

Пример конфигурации (содержит параметры, связанные с использованием секции [users] файла /etc/pangolin-pooler/pangolin-pooler.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, а аутентификация в базе данных будет выполняться только после аутентификации его в Pangolin Pooler.

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

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

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

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

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

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

• authentication_max_workers (integer) - параметр определяет максимальное число одновременных подключений для выполнения аутентификации пользователей. Значение по умолчанию 16. При значении, равном 0, сквозная аутентификация выполняться не будет.

  Примечание:

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

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

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

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

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

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

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

  Примечание:

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

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

• auth_idle_period (integer) - параметр определяет период простоя процесса сквозной аутентификации (в секундах). Значение по умолчанию 60 сек. Отсчет периода начинается после обработки последнего полученного пакета. После окончания периода будет проверено, нужно ли продолжать работу процесса сквозной аутентификации. Процесс будет прерван, если связанной с ним базы данных нет, или она была удалена или переименована.

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

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 или Pangolin Pooler. В каком логе и в какое время - зависит от значений параметров place и connect_time\auth_time.

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

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

Подробное описание команд приведено в документе «Список PL/SQL функций продукта», раздел «Сквозная аутентификация».

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

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

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

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

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

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

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

rm -f ~/.psql_history

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

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

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

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

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

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

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

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

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

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

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

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

    • authentication_proxy = on;

    • authentication_port = {AUTHPORT};

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

  • auth_port={AUTHPORT};

  • auth_proxy = on;

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

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

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

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

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

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

  • auth_proxy = off;

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

• Аутентификация LDAP не поддерживается Pangolin Pooler, поэтому 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
  

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

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

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

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

Ниже приведен пример конфигурации, когда защищенное соединение выполняется между клиентом и Pangolin Pooler, а между Pangolin Pooler и 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

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

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

В файле pangolin-pooler.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

Управление протоколом LDAPS#

В Pangolin реализована возможность настроить шифрование запросов от сервера Postgres к AD (Active Directory). Для этого нужно настроить протокол LDAPS, использующий LDAP поверх SSL с использованием шифрования TLS. Далее приведены шаги для включения TLS соединения с LDAP.

1. Набор имеющихся корневых AD сертификатов скопируйте на сервер, где будет производиться установка (в случае кластера - и на мастер, и на реплику). Примером директории может быть: etc/pki/ca-trust/source/anchors.

2. Выполните команду sudo update-ca-trust для обновления списка доверенных сертификатов.

3. В файле конфигурации etc/openldap/ldap.conf укажите путь к сертификатам в параметре TLS_CACERTDIR. Также добавьте набор шифров, используемых сервером AD: TLS_CIPHER_SUITE TLSv1.2:!NULL.

4. Отредактируйте раздел hba_rules конфигурационного файла инсталлятора custom_file_template.yml. В нем пропишите параметры подключения к серверу:

   ldapserver="{{ ldap_server }}" ldapport=3268 ldapbasedn="" ldapprefix="cn=" ldapsuffix=" OU=NPA OU=PAM OU=ALL DC=MustBeFilled dc=ru ldap_tls=1
   

5. Запустите установку/обновление Pangolin. Ниже приведен пример строки pg_hba.conf при включенном ldaptls:

   host all +all-sa-pam-group 0.0.0.0/0 ldap ldaptls=1 ldapserver=X.XX.ru ldapport=389 ldapprefix="cn=" ldapsuffix=", OU=NPA, OU=PAM, OU=ALL, OU=XX, DC=X, dc=ru
   

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

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

Подготовка сертификатов не выполняется инсталлятором 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 = <host> ## hostname with domain
     IP.1 = <IP-адрес> ## host ip address
     

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

     CONFIG=`echo $PWD/server.conf`
     

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

     openssl req -new -key server.key -out server.csr -subj "/CN=<host>" -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):

     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.

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

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

cat root.crt intermediate.crt > rootCA.crt

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

sudo update-ca-trust

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

Внимание!

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

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

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

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

2. В pangolin-pooler.ini добавьте секцию TLS-настроек. Между Pangolin Pooler и Pangolin настраивается обязательное SSL-соединение, между Pangolin Pooler и клиентом — по требованию клиента. В обоих случаях минимальная версия 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/ca/rootCA.crt
   server_tls_cert_file = /home/postgres/ca/pgbouncer.crt
   server_tls_key_file = /home/postgres/ca/pgbouncer.key
   client_tls_protocols = secure
   client_tls_ciphers = secure
   client_tls_sslmode = prefer
   client_tls_ca_file = /home/postgres/ca/rootCA.crt
   client_tls_cert_file = /home/postgres/ca/server.crt
   client_tls_key_file = /home/postgres/ca/server.key
   

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

   ETCD_NAME="<hostname>"
   ETCD_LISTEN_CLIENT_URLS="https://<IP-адрес>:2379"
   ETCD_ADVERTISE_CLIENT_URLS="<hostname>:<порт>"
   ETCD_LISTEN_PEER_URLS="https://<IP-адрес>:2380"
   ETCD_INITIAL_ADVERTISE_PEER_URLS="<hostname>:<порт>"
   ETCD_INITIAL_CLUSTER_TOKEN="test"
   ETCD_INITIAL_CLUSTER="<hostname>:<порт>,<hostname>:<порт>,<hostname>:<порт>"
   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/ca/rootCA.crt"
   ETCD_CERT_FILE="/home/postgres/ca/server.crt"
   ETCD_KEY_FILE="/home/postgres/ca/server.key"
   ETCD_PEER_TRUSTED_CA_FILE="/home/postgres/ca/rootCA.crt"
   ETCD_PEER_CERT_FILE="/home/postgres/ca/server.crt"
   ETCD_PEER_KEY_FILE="/home/postgres/ca/server.key"
   ETCD_PEER_CLIENT_CERT_AUTH="true"
   ETCD_PEER_CRL_FILE="путь к файлу со списком отозванных сертификатов"
   

4. В файле конфигурации pangolin-manager 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: <IP-адрес>:8008
          connect_address: <hostname>:<порт>
          allowlist: []
          allowlist_include_members: true
          verify_client: optional
          cafile: /home/postgres/ca/rootCA.crt
          certfile: /home/postgres/ca/server.crt
          keyfile: /home/postgres/ca/server.key
          authentication:
              username: patroniyml
              password: <пароль>
      

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

      etcd:
          hosts: <hostname>:<порт>,<hostname>:<порт>,<hostname>:<порт>
          protocol: https
          cacert: /home/postgres/ca/rootCA.crt
          cert: /home/postgres/ca/patronietcd.crt
          key: /home/postgres/ca/patronietcd.key
          username: patronietcd
          password: <пароль>
      

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

   postgresql:
       listen: <IP-адрес>:5433
       bin_dir: /usr/pgsql-se-05/bin
       connect_address: <hostname>:<порт>
       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/ca/patroni.key
               sslcert: /home/postgres/ca/patroni.crt
               sslrootcert: /home/postgres/ca/rootCA.crt
               sslcrl: "путь к файлу со списком отозванных сертификатов"
           superuser:
               username: patroni
               sslmode: verify-ca
               sslkey: /home/postgres/ca/patroni.key
               sslcert: /home/postgres/ca/patroni.crt
               sslrootcert: /home/postgres/ca/rootCA.crt
               sslcrl: "путь к файлу со списком отозванных сертификатов"
   
           ssl: 'on'
           ssl_cert_file: /home/postgres/ca/server.crt
           ssl_key_file: /home/postgres/ca/server.key
           ssl_ca_file: /home/postgres/ca/rootCA.crt
           ssl_crl_file: "путь к файлу со списком отозванных сертификатов"
   

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

   hostssl all patroni <IP-адрес>/32 scram-sha-256
   hostssl all patroni <IP-адрес>/32 scram-sha-256
   hostssl replication patroni <IP-адрес>/32 scram-sha-256
   hostssl replication patroni <IP-адрес>/32 scram-sha-256
   

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

Использование сертификатов 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.

Примечание:

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

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

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

• Корневой сертификат root.crt, которым подписаны сертификаты компонентов Pangolin, Pangolin Pooler и Pangolin Manager…

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

• в конфигурационном файле pangolin-manager 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;

• в конфигурационном файле Pangolin Pooler pangolin-pooler.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, если в конфигурационных файлах не прописаны прежние параметры для установки цепочки доверенных сертификатов:

• в конфигурационном файле Pangolin Manager 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);

• в конфигурационном файле Pangolin Pooler pangolin-pooler.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_config_path (-p), параметр включения проверки подписи --verify (-v), опционально путь к корневому сертификату --CAfile (-f), опционально путь к директории с корневым сертификатом --CApath (-d), опциональный параметр отключения поиска в директориях по умолчанию --no-CApath (-n).

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

$ 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
--verify                 [-v]     Check that PKCS#12 certificate trusted by anchor
--CAfile                 [-f]     Path to root/intermediate certificate file
--CApath                 [-d]     Path to root/intermediate certificate directory
--no-CApath              [-n]     Do not use the default directory of trusted certificates.

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

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 настраивается путем установки следующих параметров в конфигурационных файлах компонентов кластера:

• в конфигурационном файле Pangolin Manager 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;

• в конфигурационном файле Pangolin Pooler pangolin-pooler.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, предоставляется возможность использования существующих параметров для установки путей к файлам с полными цепочками доверенных сертификатов или введенных в текущей работе новых параметров для установки директории с доверенными сертификатами:

• в конфигурационном файле Pangolin Manager. 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';

• в конфигурационном файле Pangolin Pooler pangolin-pooler.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 с клиентской ключевой парой Pangolin Pooler и цепочкой доверенных сертификатов для подключения к СУБД 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 с клиентской ключевой парой и цепочкой доверенных сертификатов для подключения Pangolin Manager к СУБД 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. Может быть подписан сертификатом, отличным от сертификата, подписавшего сертификаты компонентов Pangolin, Pangolin Pooler, Pangolin Manager. Тогда потребуется указать путь к корневому сертификату в параметре 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-формате без перезапуска кластера. Достаточно выполнить перечитывание конфигурационных файлов.

Управление сертификатами для Pangolin с Secret Management System#

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

В Pangolin появляется несколько новых конфигурационных файлов. Эти файлы используются следующими компонентами кластера: СУБД Pangolin, Pangolin Pooler и Pangolin Manager. Каждый компонент использует свой конфигурационный файл. Данные, указанные в файлах, используются для генерации контейнеров 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": ""
    }
  }
  

• Pangolin Pooler:

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

• Pangolin Manager:

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

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

• В случае кластера. В файле конфигурации Pangolin Manager 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.

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

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

Ротация сертификатов, получаемых из SecMan#

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

• контролирует срок действия сертификатов, полученных из SecMan;

• обновляет сертификаты на SecMan при приближении конца их срока действия;

• контролирует внешнее изменение сертификатов, обновление на SecMan, а также отзыв сертификата;

• запускает процесс обновления сертификатов на кластере.

Агент pg_certs_rotate_agent#

Агент представляет собой исполняемый файл pg_certs_rotate_agent, который настраивается для работы с конкретным хранилищем сертификатов через систему плагинов. Расположен в директории /opt/pangolin-common/bin/ и запускается отдельной службой pg_certs_rotate_agent.service до запуска служб postgresql.service, pangolin-pooler.service и pangolin-manager.service.

Период проверки сертификатов и их обновления настраивается в конфигурационном файле агента. Первая проверка происходит на его старте. Следующий запуск агента может произойти до окончания заданного промежутка времени, если интервал между датой истечения и датой выпуска одного из сертификатов достигает 80% внутри текущего периода. Таким образом, агент будет запущен в этот момент времени, и следующий период будет отсчитываться уже от этой точки. Если в процессе работы агента произошла ошибка, то его следующий запуск произойдет через заданный в конфигурации период ожидания.

На схеме ниже приведены этапы работы агента:

Если обновление сертификата на SecMan произошло без участия агента, то кластер до следующего запуска агента будет работать со старым сертификатом (в том числе, если сертификат отозван):

Для взаимодействия с SecMan применяется плагин remote_secman_pki_plugin, который использует протокол http/https, а также параметры подключения кластера. Параметры хранятся в зашифрованном хранилище /etc/postgres/enc_connection_settings_cert.cfg. Для расшифровки файла агент использует плагин шифрования.

Процесс инсталляции агента#

Настройка работы агента происходит на этапе установки кластера Pangolin:

Для включения агента ротации сертификатов в конфигурационном файле инсталлятора custom_file_template.yml (см. раздел «Конфигурационные файлы для настройки СУБД Pangolin») требуется добавить параметр enable в yaml-словарь pg_certs_rotate_agent. Все параметры агента сохраняются в конфигурационном файле, который тот использует при инициализации:

• путь к конфигурационному файлу агента задается при помощи параметра agent_config, который находится в pg_certs_rotate_agent. По умолчанию используется конфигурационный файл /etc/postgres/pg_certs_rotate_agent.yaml;

• путь к директории для лог-файлов задается с помощью параметра log_directory в yaml-словаре pg_certs_rotate_agent. По умолчанию используется путь /var/log/pg_certs_rotate_agent;

• имя лог-файла задается параметром log_filename в yaml-словаре pg_certs_rotate_agent. По умолчанию используется имя pg_certs_rotate_agent;

• уровень логирования задается параметром log_level в yaml-словаре pg_certs_rotate_agent. Возможны уровни: debug | info | warning | error | fatal. По умолчанию используется уровень info;

• методы записи лога задаются параметром log_destination в yaml-словаре pg_certs_rotate_agent. Возможные методы: console, file при любой комбинации методов. По умолчанию используется метод console;

• включить/отключить функцию ротации сертификатов можно с помощью параметра enable_update в словаре pg_certs_rotate_agent:certs. По умолчанию функция включена;

• период проверки сертификатов настраивается при помощи параметра poll_period_in_min, который находится в словаре pg_certs_rotate_agent:certs и задается в минутах. По умолчанию период работы будет равен 60 минутам;

• время ожидания повторного запуска агента в случае ошибки устанавливается в параметре retry_interval_in_sec, который находится в словаре pg_certs_rotate_agent:certs и задается в секундах. По умолчанию таймаут будет равен 30 секундам;

• количество повторных проверок в случае ошибки задается параметром retry_attempts_num, который находится в словаре pg_certs_rotate_agent:certs. По умолчанию настроена одна попытка;

• список сертификатов, за сроком действия которых «следит» агент, определяются группами locations, которые находятся в словаре pg_certs_rotate_agent:certs:watch. В каждой группе задается:

  • в словаре paths множество конфигурационных файлов сертификатов *.p12.cfg;

  • в словаре on_update множество зависимых от сертификатов команд, необходимых для обновления компонентов кластера.

Формат конфигурационного файла инсталлятора для агента ротации:

    pg_certs_rotate_agent:
        # Флаг определяет, запускается ли агент ротации.
        # Если флаг true, то агент будет запущен, иначе - false.
        enable: true
        # Путь к конфигурационному файлу агента в YAML-формате
        agent_config: "{{ '' | default('/etc/postgres/pg_certs_rotate_agent.yaml', true) }}"
        # Путь к директории для лог-файлов
        log_directory: "{{ '' | default('/var/log/pg_certs_rotate_agent', true) }}"
        # Имя лог-файла
        log_filename: "{{ '' | default('pg_certs_rotate_agent', true) }}"
        # Уровень логирования
        log_level: "{{ '' | default('info', true) }}"
        # Методы записи лога
        log_destination:  "{{ '' | default('console', true) }}"

        certs:
            # Включить/выключить автоматическое обновление сертификатов
            enable_update: "{{ '' | default(true, true) }}"
            # Период проверки валидности сертификатов [мин]
            poll_period_in_min: "{{ '' | default(60, true) }}"
            # Таймаут на повторный запуск в случае ошибки [c]
            retry_interval_in_sec: "{{ '' | default(30, true) }}"
            # Количество попыток после неудачи
            retry_attempts_num: "{{ '' | default(1, true) }}"

            # Множество обновляемых сертификатов
            watch:
                - locations:
                    # Множество файлов конфигураций сертификатов
                    paths:
                        - path/to/cert/configuration/1_1
                        - path/to/cert/configuration/1_N
                    # Множество команд, которые требуется выполнить после обновления хотя бы одного из сертификатов
                    on_update:
                        - update command 1_1
                        - update command 1_N

                # Множество файлов конфигураций
                - locations:
                    # Множество обновляемых сертификатов
                    paths:
                        - path/to/cert/configuration/M_1
                        - path/to/cert/configuration/M_N
                    # Множество команд, которые требуется выполнить после обновления хотя бы одного из сертификатов
                    on_update:
                        - update command M_1
                        - update command M_N

Для каждого сертификата существует конфигурационный файл *.p12.cfg. Если кластер получает сертификат из SecMan, то в словаре pkcs12 будут описаны параметры доступа к сертификату на 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
      }
    }

Если кластер использует локальный сертификат, то в словаре pkcs12 будет указан путь к локальному сертификату. Чтобы агент ротации мог обновить файл локального сертификата, необходимо в конфигурационном файле *.p12.cfg добавить словарь secman с описанием параметров доступа к сертификату на SecMan:

    {
      "secman": {
        "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
      }
    }

Настройка параметров запущенного агента#

Примечание:

В случае кластерной конфигурации агент запускается на каждом из его узлов. Далее описывается настройка агента для standalone-конфигурации или при запуске на одном узле.

Чтобы изменить параметры запущенного агента, требуется обновить конфигурационный файл агента, который был указан в процессе инсталляции, и перезагрузить параметры службы pg_certs_rotate_agent.service:

На первом шаге необходимо заполнить конфигурационный файл агента в формате YAML:

    log:
    directory: PATH/TO/LOG/DIRECTORY
    filename: LOG_FILE_NAME
    level: debug | info | warning | error | fatal
    destination: console, file

    certs:
    enable_update: bool
    poll_period_in_min: unsigned integer
    retry_interval_in_sec: unsigned integer
    retry_attempts_num: unsigned integer

    watch:
        - locations:
            paths:
                - PATH/TO/CERT/CONFIGURATION/1
                - PATH/TO/CERT/CONFIGURATION/N
            on_update:
                - bash command 1
                - bash command N

        - locations:
            paths:
                - PATH/TO/CERT/CONFIGURATION/1
                - PATH/TO/CERT/CONFIGURATION/M
            on_update:
                - bash command 1
                - bash command M

Чтобы включить или отключить ротацию сертификатов, требуется установить значение ключа enable_update, который находится в yaml-словаре certs, в значение true или false соответственно.

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

Для изменения времени ожидания с целью перезапуска агента (в случае ошибки) нужно задать новое значение ключа retry_interval_in_sec (в секундах). Ключ расположен в словаре certs.

Чтобы изменить количество повторных попыток в случае ошибки, нужно задать новое значение ключа retry_attempts_num, который находится в yaml-словаре certs.

Список сертификатов для обработки агентом задается в виде групп, определенных через ключ locations. Для каждой группы должна быть определена команда обновления сертификатов на кластере. Если один из сертификатов группы устаревает, обновляется на SecMan или появляется в списке отозванных, то выполняется команда, указанная по ключу on_update.

Далее приведен пример конфигурационного файла агента ротации сертификатов для конфигурации standalone-patroni-etcd-pgbouncer без контроля отозванных сертификатов:

    certs:
      enable_update: true
      poll_period_in_min: 1440
      retry_interval_in_sec: 60
      retry_attempts_num: 1

      watch:
        - locations:
            paths:
                - "/home/postgres/ssl/server.p12.cfg"
                - "/home/postgres/ssl/patroni.p12.cfg"
            on_update:
                - sudo systemctl reload pangolin-manager

        - locations:
            paths:
                - "/home/postgres/ssl/server.p12.cfg"
                - "/home/postgres/ssl/pgbouncer.p12.cfg"
            on_update:
                - sudo systemctl reload pangolin-pooler

При изменении имени конфигурационного файла агента требуется обновить параметры службы pg_certs_rotate_agent.service. Имя файла указывается в качестве аргумента исполняемого файла /opt/pangolin-common/bin/pg_certs_rotate_agent:

   ExecStart=/opt/pangolin-common/bin/pg_certs_rotate_agent --config=/etc/postgres/pg_certs_rotate_agent.yaml

Для применения настроек необходимо перезагрузить службу:

   sudo systemctl restart pg_certs_rotate_agent.service

Процесс обновления сертификатов на SecMan#

При успешном подключении к SecMan, агент запрашивает каждый контролируемый сертификат отдельно, используя метод read. Метод fetch не используется, чтобы исключить автоматический перевыпуск сертификатов без их последующего обновления на кластере. Если интервал между датой истечения и датой выпуска сертификата достигает 80% внутри следующего периода (или если сертификат попал в список отозванных), то агент, используя метод generate, запрашивает его перевыпуск. Если в процессе обновления сертификата произошла ошибка, то следующая попытка откладывается на другую итерацию работы агента через период ожидания, определенный в конфигурационном файле.

Примечание:

Контроль за попаданием сертификатов в список отозванных реализуется в сервисе обновления CRL. Сервис ротации сертификатов сообщает сервису обновления CRL серийные номера используемых на кластере сертификатов. Если сервис обновления CRL находит сертификаты в списке отозванных, то сообщает об этом сервису ротации сертификатов, после чего запускается процесс их обновления на SecMan.

Процесс обновления сертификатов на кластере#

При успешном обновлении на SecMan хотя бы одного сертификата из списка (или если обновление сертификатов на SecMan произошло без участия агента) агент запускает процесс обновления сертификатов на кластере. Для этой проверки он сохраняет серийные номера сертификатов, которые периодически сравнивает с полученными от SecMan.

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

Внимание!

Агент не контролирует ошибки, которые могут произойти в процессе обновления сертификатов на кластере.

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

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

Поддержка CRL в компонентах кластера Pangolin#

CRL представляет собой список сертификатов, которые УЦ пометил как отозванные (при этом сертификаты с истекшим сроком действия не вносятся в этот список). Каждая запись в списке включает идентификатор отозванного сертификата и дату отзыва. Дополнительная информация включает в себя ограничение по времени, если отзыв применяется в течение определенного периода времени, а также причину отзыва.

Начиная с версии 5.4.0, использование файлов CRL поддерживается всеми компонентами кластера, а автоматическое обновление неактуальных файлов CRL доступно как часть функциональности агента ротации сертификатов pg_certs_rotate_agent.

Настройка CRL#

Для поддержки CRL имеются следующие параметры в конфигурационных файлах компонентов:

1. postgresql.conf (Pangolin):

   • ssl_crl_file - путь к файлу CRL, по которому выполняется проверка статуса клиентских сертификатов;

   • ssl_crl_dir - путь к директории с файлами CRL, по которым выполняется проверка аннулирования клиентских сертификатов.

   Примечание:

   При включенной защите параметров ssl_crl_file и ssl_crl_dir инициализируются значениями из защищенного хранилища секретов.

2. Клиентские утилиты, использующие библиотеку libpq (psql):

   • sslcrl (переменная окружения PGSSLCRL) - путь к файлу CRL, по которому выполняется проверка статуса серверных сертификатов;

   • sslcrldir (переменная окружения PGSSLCRLDIR) - путь к директории с файлами CRL, по которым выполняется проверка статуса серверных сертификатов.

3. postgres.yml (Pangolin Manager):

   • в секции restapi:

     • crlfile - путь к файлу CRL;

     • crlpath - путь к директории с файлами CRL, по которым выполняется проверка аннулирования клиентских сертификатов;

   • в секции postgresql/authentication/(replication/rewind/superuser):

     • sslcrldir - путь к директории с файлами CRL, по которым выполняется проверка аннулирования серверного сертификата Pangolin;

   • в секции postgresql/parameters:

     • sslcrldir - путь к каталогу с файлами CRL, по которым выполняется проверка аннулирования клиентских сертификатов;

4. pangolin-pooler.ini (Pangolin Pooler):

   • client_tls_crl_file - путь к файлу CRL;

   • client_tls_crl_path - путь к директории с файлами CRL, по которым выполняется проверка аннулирования клиентских сертификатов;

   • server_tls_crl_file - путь к файлу CRL;

   • server_tls_crl_path - путь к директории с файлами CRL, по которым выполняется проверка аннулирования серверного сертификата Pangolin.

Внимание!

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

Примечание:

Для использования директории c файлами CRL необходимо для каждого из файлов создать в этой директории символические ссылки, названные по хеш-значению от содержимого соответствующего файла CRL. Хеш-значения рассчитываются утилитой c_rehash.

Пример вызова утилиты:

c_rehash /pg_ssl/crl

За подробностями обратитесь к документации OpenSSL.

Для обеспечения автоматического обновления файлов CRL расширяется функциональность агента ротации сертификатов pg_certs_rotate_agent.

Запуск агента выполняется до запуска служб postgresql.service (для конфигурации standalone), pangolin-manager.service (для кластерной конфигурации) и pangolin-pooler.service, чтобы для каждого из компонентов выгрузить файлы CRL из CDP (CRL Distribution Point - точка распространения CRL). Компоненты кластера не запустятся, если файлы CRL прописаны в конфигурационных файлах, но отсутствуют на файловой системе. После выполнения первого цикла выгрузки CRL агент нотифицирует systemd о готовности в случае успешной выгрузки всех файлов CRL, иначе переводит статус службы в failed. Время цикла выгрузки CRL ограничено за счет установки времени ожидания в 30 сек на каждый запрос к CDP.

Примечание:

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

Исполняемый файл агента принимает в качестве аргумента командной строки путь к конфигурационному файлу агента pg_certs_rotate_agent.yml, который расположен в директории /etc/postgres и включает следующие параметры:

• в секции log:

  • directory - путь к директории для лог-файлов (обязательный параметр при выводе лога в файл);

  • filename - имя лог-файла (по умолчанию pg_certs_rotate_agent.log);

  • level - (trace|debug|info|warning|error) - уровень логирования (по умолчанию info);

  • destination - методы записи лога (комбинируются через запятую):

    • console - в стандартный поток вывода или ошибок (в случае запуска под управлением службы - в системный журнал). Значение по умолчанию;

    • file - в файл.

• в секции crl:

  • enable_update (true|false) - включить/выключить автоматическое обновление CRL (по умолчанию false);

  • poll_period_in_min - интервал времени, определяющий период проверки наличия обновленных CRL файлов (задается как целое неотрицательное число в минутах; по умолчанию 60 минут; 0 для отключения периодической проверки CRL). Опрос CDP должен выполняться не реже данного периода;

  • retry_interval_on_expire_in_sec - интервал повторных попыток выгрузки CRL, для которых дата публикации или дата окончания срока действия уже наступили (задается как целое положительное число в секундах, по умолчанию 30 секунд);

  • retry_interval_on_failure_in_sec - интервал времени, через который выполняются повторные попытки выгрузки CRL после неудачи (задается как целое положительное число в секундах, по умолчанию 30 секунд);

  • retry_attempts_num_on_failure - количество попыток выгрузки CRL по списку URI для данного пути расположения файла CRL после неудачи (по умолчанию 1 попытка);

  • crl_file_perm - права доступа, устанавливаемые на выгружаемые файлы CRL (задается в восьмеричном формате, по умолчанию 0644).

• в секции watch:

  • locations - секция включает списки путей до файлов, обновление которых отслеживается (path), а также куда выгружаются новые CRL из CDP (uri):

    • path - путь к файлу CRL;

    • uri - массив URI для выгрузки CRL (основной и резервные);

  • on_update - список выполняемых команд, если файл CRL изменился (перечитывание конфигурации компонентами кластера).

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

log:
  directory: /pgerrorlogs/05/pg_certs_rotate_agent
  filename: pg_certs_rotate_agent.log
  level: info
  destination: console,file

crl:
  enable_update: false
  poll_period_in_min: 60
  retry_interval_on_expire_in_sec: 30
  retry_interval_on_failure_in_sec: 30
  retry_attempts_num_on_failure: 1
  crl_file_perm: 0644

  watch:
  - locations:
    - path: CRLPATH_1
      uri:
      - URI_1
      - URI_N
    - path: CRLPATH_N
      uri:
      - URI_1
      - URI_N
    on_update:
    - sudo systemctl reload postgresql

  - locations:
    - path: CRLPATH_1
      uri:
      - URI_1
      - URI_N
    - path: CRLPATH_N
      uri:
      - URI_1
      - URI_N
    on_update:
    - sudo systemctl reload pangolin-manager

  - locations:
    - path: CRLPATH_1
      uri:
      - URI_1
      - URI_N
    - path: CRLPATH_N
      uri:
      - URI_1
      - URI_N
    on_update:
    - sudo systemctl reload pangolin-pooler

Справка по аргументам командной строки агента:

pg_certs_rotate_agent --help
Allowed options:
  -h [ --help ]                         produce this help message
  -p [ --pid-file ] arg (=/var/run/pg_certs_rotate_agent/pg_certs_rotate_agent.pid)
                                        path to agent's PID file
  -c [ --config ] arg (=/etc/postgres/pg_certs_rotate_agent.yml)
                                        path to agent's configuration file
  -d [ --dry-run ]                      check config file format and exit

Агент поддерживает режим пробного запуска с ключом --dry-run. В этом режиме проверяется корректность конфигурационного файла с последующим завершением выполнения. Результат проверки определяется кодом возврата: 0 - конфигурационный файл валидный, иначе 1. Информация об ошибке выводится в лог.

На старте агент сохраняет PID своего процесса в файл (по умолчанию /var/run/pg_certs_rotate_agent/pg_certs_rotate_agent.pid). Файл с PID процесса используется для предотвращения запуска еще одного экземпляра агента и в команде на ротацию лог-файла. Ротация лог-файлов агента выполняется с помощью утилиты logrotate. Файл конфигурации для logrotate расположен в /etc/logrotate.d/pg_certs_rotate_agent и имеет следующее содержимое:

/pgerrorlogs/05/pg_certs_rotate_agent/pg_certs_rotate_agent.log {
      rotate 10
      dateext
      daily
      missingok
      notifempty
      compress
      create 0640 postgres postgres
      sharedscripts
      postrotate
           [ ! -f /var/run/pg_certs_rotate_agent/pg_certs_rotate_agent.pid ] || /bin/kill -USR1 `cat /var/run/pg_certs_rotate_agent/pg_certs_rotate_agent.pid 2> /dev/null` 2>/dev/null
      endscript
}

Права доступа к директории с логами /pgerrorlogs/05/pg_certs_rotate_agent:

drwxr-x--- 2 postgres postgres

Если включена автоматическая проверка обновления CRL (crl:enable_update), агент в установленное время подключается к первой доступной CDP по HTTP (crl:watch:locations:uri), выгружает файл CRL и сохраняет его в PEM-формате по пути, определенному в параметре crl:watch:locations:path (если файл CRL еще ни разу не выгружался или изменился в точке распространения).

Примечание:

Выгруженный файл CRL с истекшим сроком действия не сохраняется в файловой системе и не удаляется из нее.

Внимание!

Агент не проверяет подпись выгруженного файла CRL. Данную проверку выполняют компоненты кластера, для которых файл CRL предназначен.

Агент создает символическую ссылку на выгруженный файл CRL. Символическая ссылка именуется хеш-значением, рассчитанным по содержимому файла CRL. Если файл CRL до выгрузки нового уже существовал, то символическая ссылка на старый файл удаляется, чтобы не засорять файловую систему, поскольку хеш-значения от старого и нового файлов CRL будут отличаться. Символическая ссылка требуется, чтобы иметь возможность указывать директорию с файлами CRL в конфигурационных файлах компонентов кластера, так как OpenSSL выполняет поиск CRL по хеш-значению.

Если выгруженный файл CRL не является истекшим и не содержит серийные номера сертификатов, находящихся под контролем сервиса ротации сертификатов, агент выполнит команды перечитывания конфигурации соответствующих компонентов (crl:watch:locations:on_update). Если же файл CRL содержит серийные номера таких сертификатов, то соответствующие сертификаты будут перевыпущены сервисом ротации, а команды перечитывания конфигурации выполнятся после процедуры перевыпуска сертификатов.

Внимание!

Агент не контролирует ошибки, которые могут произойти в процессе перечитывания конфигурации компонентами кластера.

Для защиты файлов CRL от их перезаписи агентом в процедуре инициализации SSL контекста в компонентах кластера применяется блокировка на базе flock(). В процессе работы создается временный файл /tmp/.crl.lock. Агент удерживает для него эксклюзивную блокировку на время записи выгруженных CRL-файлов, тогда как компоненты кластера (на старте или при перечитывании параметров) используют для него разделяемую блокировку. Таким образом, компоненты кластера могут одновременно, не мешая друг другу, загружать файлы CRL, блокируясь только при обновлении файлов CRL агентом.

Для каждого файла CRL проверка обновления выполняется:

• при запуске агента;

• с периодичностью, определенной в параметре crl:poll_period_in_min, если значение параметра больше 0;

• в момент следующей публикации CRL (дата в поле CRL файла NextCRLPublish) и через каждый интервал времени, определяемый параметром crl:retry_interval_on_expire_in_sec (если после наступления даты публикации CRL еще не выпущен);

• в момент истечения срока действия CRL (дата в поле CRL файла NextUpdate) и через каждый интервал времени, определяемый параметром crl:retry_interval_on_expire_in_sec, если после истечения срока действия CRL еще не выпущен;

• спустя интервал времени, задаваемый параметром crl:retry_interval_on_failure_in_sec, после неудачной выгрузки;

• по требованию путем перезапуска службы агента (на его старте):

sudo systemctl restart pg_certs_rotate_agent.service

• при выполнении команды reload и изменении конфигурационного файла агента:

  • изменился список URI;

  • добавлена новая команда в crl:watch:locations:on_update;

  • добавлен новый путь к файлу CRL.

sudo systemctl reload pg_certs_rotate_agent.service

Примечание:

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

Процесс инсталляции#

Пути к файлу CRL и директории, содержащей файлы CRL, задаются в конфигурационном файле инсталлятора и одинаковы для всех компонентов кластера. Ниже приведен формат его полей для настройки путей к файлам CRL:

pg_certs_pwd:
  crl_file: "{{ '' | default('/pg_ssl/crl/root.crl', true) }}" # Путь к CRL файлу
  crl_path: "{{ '' | default('/pg_ssl/crl', true) }}"          # Путь к директории с файлами CRL

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

pg_certs_rotate_agent:
  enable: true  # Настроить и запустить службу агента (не учитывается при обновлении агента, только при первичном развертывании)
  agent_config: /etc/postgres/pg_certs_rotate_agent.yml  # Путь к конфигурационному файлу агента в формате YAML
  update_agent_config: false # Обновить файл конфигурации агента (учитывается только при обновлении, значение по умолчанию - False)

  log:
    directory: /pgerrorlogs/05/pg_certs_rotate_agent   # Путь к директории для лог-файлов
    filename: pg_certs_rotate_agent.log                # Имя лог-файла
    level: info                                        # Уровень логирования
    destination: console,file                          # Методы записи лога

  crl:
    enable_update: false                 # Включить/выключить автоматическое обновление CRL
    poll_period_in_min: 60               # Период проверки наличия обновленных CRL файлов
    retry_interval_on_expire_in_sec: 30  # Таймаут для повторной попытки выгрузки CRL после наступления даты публикации CRL или окончания срока действия
    retry_interval_on_failure_in_sec: 30 # Таймаут для повторной попытки выгрузки CRL после неудачи
    retry_attempts_num_on_failure: 1     # Количество попыток выгрузки CRL по списку URI для данного пути расположения файла CRL после неудачи
    crl_file_perm: 0644                  # Права доступа, устанавливаемые на выгружаемые файлы CRL

    watch:
    - locations:
      - path: path/to/crlfile_1  # Путь к обновляемому файлу CRL
        uri:
        - URI_1                  # Основная точка распространения CRL
        - URI_N                  # Резервная точка распространения CRL
      - path: path/to/crlfile_N  # Путь к обновляемому файлу CRL
        uri:
        - URI_1                  # Основная точка распространения CRL
        - URI_N                  # Резервная точка распространения CRL
      on_update:
      - sudo systemctl reload postgresql # Список выполняемых команд, если файл CRL изменился

Примечание:

Установка файлов агента на узел СУБД производится инсталлятором автоматически.

Обновление pg_certs_rotate_agent осуществляется по одному из двух сценариев:

• если агент был ранее установлен в обновляемой версии СУБД Pangolin (например, при переходе с версии СУБД Pangolin 5.4.0 на более высокую):

  • в зависимости от значения параметра update_agent_config, который определяется в конфигурационном файле инсталлятора, автоматически настраивается файл конфигурации агента. По умолчанию значение параметра - False, в этом случае конфигурационный файл агента не заменяется версией конфигурации из файла инсталлятора. При необходимости ее обновления инсталлятором, параметр нужно установить в значение True;

  • в зависимости от состояния службы агента (active/inactive) по окончании обновления версии СУБД служба агента будет либо запущена, либо нет. Проверить статус службы можно следующим способом:

    sudo systemctl status pg_certs_rotate_agent | grep Active
    

    Результат будет иметь следующий вид:

    Active: active (running) since Tue 2023-05-23 15:59:02 MSK; 13s ago
    

    или

    Active: inactive (dead)
    

• если агент не был установлен в обновляемой версии СУБД Pangolin (например, при переходе с версии СУБД Pangolin 5.2.0):

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

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

Примечание:

В рамках механизма обновления версии СУБД скрипт-разведчик проверяет корректность заполнения файла конфигурации pg_certs_rotate_agent.

В файл /etc/sudoers вручную добавляются следующие команды, разрешенные пользователю postgres для выполнения без запроса пароля:

/bin/journalctl -f -u pg_certs_rotate_agent
/usr/bin/systemctl start pg_certs_rotate_agent
/usr/bin/systemctl stop pg_certs_rotate_agent
/usr/bin/systemctl restart pg_certs_rotate_agent
/usr/bin/systemctl reload pg_certs_rotate_agent
/usr/bin/systemctl status pg_certs_rotate_agent
/usr/bin/systemctl reload pangolin-manager
/usr/bin/systemctl reload postgres

В файл конфигурации службы pangolin-manager.service необходимо добавить команду reload:

ExecReload=/bin/kill -HUP $MAINPID

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

Расширение 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;
   

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

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

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

Включение генерации пароля происходит при установке параметра rotate_password.enable в значение true (по умолчанию функциональность отключена, значение параметра - false):

rotate_password.enable: true

Параметры генерации пароля:

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

  rotate_password.valid_roles = '20'`
  

• rotate_password.valid_roles = '' - список пользователей (через запятую), для которых разрешена генерация пароля:

  rotate_password.valid_roles = 'user1, "User-2", user3'
  

При изменении параметров перечитайте конфигурацию (reload).

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

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

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

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

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

Пример генерации пароля для пользователя User-2:

SELECT * FROM rotate_password('User-2');
┌───────────────────────┐
│    rotate_password    │
├───────────────────────┤
│ W+3r#0291h885I`9^JpZ@ │
└───────────────────────┘
(1 row)

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

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

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

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

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

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

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

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

DROP EXTENSION psql_rotate_password;

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

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

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

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

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

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

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

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

Если изменение параметров подключения к хранилищу секретов или сертификатов производится на работающем кластере, то выполните/запустите перечитывание конфигурационных параметров в компонентах кластера. Перезапуск кластера не требуется.

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

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

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

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

• Точка входа для urn аутентификации: /auth/точка_входа/login/. Указание точки входа позволяет авторизоваться по LDAP для типа авторизации Userpass (пример, auth/ad/X.XX.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. Если не задавать путь к корневому сертификату, то его поиск будет осуществляться в системной директории с сертификатами.

Функция check\kms_is_on() (проверка доступности плагина взаимодействия с KMS);#

Специальная проверка, которая показывает, получилось ли выбрать такие значения из файла enc_connection_settions.cfg, содержащего варианты подключения к Хранилищу секретов.

Функция проверяет, что плагин взаимодействия с KMS:

• найден, доступен и подключен к КМС;

• содержит в себе все функции API sKmsConnectionInitialized.

Пример использования:

SELECT check_kms_is_on();

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

Настройка параметров подключения производится при первоначальной настройке кластера 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
--format       [-f]     Формат вывода: table или json, по умолчанию table - человекочитаемый формат
--cluster      [-c]     имя кластера
--host         [-h]     доменное имя или ip адрес хранилища
--port         [-p]     номер порта хранилища
--protocol     [-l]     протокол обмена данными: http (1) или https (2), протокол по умолчанию: https
--prefix       [-x]     путь к хранилищу секретов на сервере (префикс для пути хранения секретов, по умолчанию: kv)
--suffix       [-u]     часть пути к секрету на сервере (по умолчанию: пусто)
--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 показать хеш компонента