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

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

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

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

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

Примечание:

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

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

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

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

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

Команда:

pg_ctl --product_version

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

Platform V Pangolin {version}

где:

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

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

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

Команда:

pg_ctl --version

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

pg_ctl (PostgreSQL) {PostgreSQL version}

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

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

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

  Команда:

  SELECT product_version();
  

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

      product_version
  ---------------------------
  Platform V Pangolin SE {version}
  (1 row)
  

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

  Команда:

  SELECT version();
  

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

                                                  version
  ---------------------------------------------------------------------------------------------------------
  PostgreSQL {PostgreSQL version} 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 - разблокировка заблокированной учетной записи администратора безопасности.

Pangolin Pooler. Рекомендации по настройке и использованию#

Pangolin Pooler используется для снижения количества соединений с БД, потому что каждая сессия БД потребляет ресурсы ОЗУ и ЦПУ.

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

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

• Повышается утилизация ЦПУ и ОЗУ-сервера вплоть до OОM killer.

Оптимальное количество соединений с БД фиксируется параметром max_connections, и его значение должно определяться на этапе нагрузочного тестирования, исходя из профиля нагрузки и возможностей КТС.

Рекомендуется начинать со значения max_connections = GREATEST(4 x CPU cores, 100).

При проведении нагрузочного тестирования важно определить тот порог max_connections, после которого производительность СУБД перестает расти.

Pangolin Pooler рекомендуется использовать, когда приложение создает клиентских подключений больше, чем полученное на этапе тестирования значение max_connections (max_client_conn>max_connections) для оптимизации производительности СУБД и экономии ресурсов ОЗУ и ЦПУ-сервера.

Следует придерживаться следующих правил:

• Значение max_db_connections <= max_connections-superuser_reserved_connections-30.

• Выставление параметров min_pool_size = default_pool_size позволяет избежать накладных расходов на повторное открытие и закрытие соединений.

Пример хорошей конфигурации, когда один пользователь (ТУЗ) работает с одной БД:

• max_client_conn = 1000;

• pool_mode = transaction;

• min_pool_size = 200;

• default_pool_size = 200;

• max_db_connections = 200;

• max_user_connections = 200.

Стоит обратить внимание, что параметр default_pool_size задается для пары пользователь/БД, поэтому для каждой созданной БД или подключаемого пользователя потенциально может открываться default_pool_size * total databases * total users соединений. Это необходимо учитывать при настройке параметров max_db_connections и max_user_connections, которые задаются независимо от пользователя и БД соответственно. В таких случаях рекомендуется явно ограничивать количество подключений через параметр pool_size в секции databases для каждой созданной БД.

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

Работа через Pangolin Pooler замедляет отклик от БД в среднем на 5%, так как весь входящий и исходящий трафик проходит через него.

Pangolin Pooler не рекомендуется использовать:

• Когда ядро, на котором работает Pangolin Pooler нагружено более чем на 70%.

• В режимах работы pool_mode = session/statement.

• В режимах работы pool_mode = transaction, при OLTP нагрузках с требованиями более 1000-10000 tps и длительностью операции менее 1-10мс из-за накладных расходов при работе с сокетом, который диагностируются ростом sys_time на ЦПУ.

• В конфигурациях, когда количество клиентских подключений в пределе достигает количества подключений к БД (max_client_conn = max_db_connections при использовании одной БД).

• Для OLAP-нагрузок, требующих большого трафика через Pangolin Pooler.

Пример потенциально нежелательной конфигурации, когда один пользователь (ТУЗ) работает с одной БД:

• max_client_conn = 1000 и более;

• default_pool_size = 1000 и более;

• max_db_connections = 1000 и более;

• max_user_connections = 1000 и более.

Стоит обратить внимание, что перед настройкой параметров подключения Pangolin Pooler необходимо убедиться, что параметр СУБД max_connections обеспечивает требуемое количество подключений и в случае необходимости изменить его.

При создании подключений через HikariCP на стороне приложения в максимальном количестве менее, чем max_connections, рекомендуется подключаться напрямую к БД. Однако в случае, когда суммарное количество клиентских подключений превышает max_connections, рекомендуется использовать Pangolin Pooler с связке с HikariCP, предварительно настроив параметры групп соединений и таймаутов с двух сторон:

• Параметр max_client_conn должен превышать сумму всех возможных подключений с HikariCP = hosts*maximum-pool-size.

• Таймаут на подключение на клиенте должен быть выше, чем на Pangolin Pooler.

Интерфейс управления парольными политиками: 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.

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

Примечание:

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

Под администратором БД понимается роль с правами суперпользователя (например, роль postgres).

Под администратором безопасности понимается роль, которая создана утилитой initprotection, (например, роль sec_admin)

Большинство операций выполняется соответствующими функциями PL/pgSQL:

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

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

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

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

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

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

Включение механизма (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-функциями:

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

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

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

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

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

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

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

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

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

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

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

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

Пользователь может создать 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 функции проверки пароля.

Проверка вхождения пароля в черный список#

password_policy.illegal_values#

Проверить, что пароль не входит в список часто используемых:

• 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#

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

Защита параметров конфигурации#

В рамках функциональности защиты конфигурации реализовано разделение разрешений на некоторые настроечные параметры PostgreSQL.

Настроечные параметры PostgreSQL#

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

Ниже будут описаны внесенные изменения в рамках настройки некоторых из них в режиме защищенного конфигурирования.

Параметры, выведенные из хранения в защищенном хранилище/VAULT#

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

• pg_hba.conf – методы аутентификации и подключения;

• shared_preload_libraries, jit_provider – подгружаемые PostgreSQL библиотеки;

• local_preload_libraries, session_preload_libraries – подгружаемые PostgreSQL библиотеки;

• dynamic_library_path – путь к динамически подгружаемым модулям;

• password_encryption – метод хеширования паролей пользователей.

Параметры, переданные на сторону защищенного хранилища/VAULT#

Параметры, перемещенные в защищенное хранилище:

• allowed_servers – список разрешенных к использованию LDAP и RADIUS серверов;

• ssl – режим работы с SSL;

• encrypt_new_tablespaces – шифрование новых табличных пространств;

  Примечание:

  Параметр действует только при запуске Pangolin и включенном TDE: is_tde_on = on/true.

  В случае, если в качестве значения параметра выбрано значение по умолчанию ddl, новые табличные пространства шифруются только при ручной установке опции is_encrypted = on, по умолчанию шифрование не применяется.

  При выборе значения параметра always, опция is_encryped, передаваемая в команде, игнорируется, так как в этом случае на все таблицы пространства будет применено шифрование.

• enabled_sec_admin_extra_auth_methods – список дополнительно разрешенных к использованию методов аутентификации для ролей администраторов безопасности;

• enabled_extra_auth_methods – список дополнительно разрешенных к использованию методов аутентификации для всех ролей.

  Примечание:

  По умолчанию доступны только методы аутентификации scram-sha-256, ldap, radius. Для применения изменений, достаточно выполнить reload (SIGHUP) Pangolin.

  Значения параметров применяются при аутентификации, так как это единственный этап, когда можно фактически определить принадлежность аутентифицируемой роли к администраторам безопасности. При использовании не разрешенного для роли метода аутентификации она будет завершена с сообщением: Authentication method "<метод аутентификации>" isn't allowed for non security admin role "<роль>". Соответствующая запись с аналогичным сообщением помещается в лог аудита как ошибка открытия соединения.

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

Параметр pg_ident_conf (карты сопоставления пользователей при авторизации) вносится под двойное управление – то есть прописывается одновременно и в VAULT, и в локальном файле. При этом совпадение порядка слов не требуется.

Внимание!

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

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

Для включения 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-{version}/lib/libpkcs12_exporter_plugin_link.so -> plugins/libpkcs12_exporter_plugin.so
/usr/pangolin-{version}/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 требуется добавить параметр 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 множество зависимых от сертификатов команд, необходимых для обновления компонентов кластера.

    Внимание!

    Были реализованы только следующие команды:

    sudo systemctl reload postgresql
    sudo systemctl reload pangolin-manager
    sudo systemctl reload pangolin-pooler
    

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

    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: true
rotate_password.num_rounds: 20

Примечание:

Значения по умолчанию:

rotate_password.enable: false
rotate_password.num_rounds: 20

В случае ручной установки, создайте расширение psql_rotate_password командой:

postgres=# CREATE EXTENSION psql_rotate_password schema ext;

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

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

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

Функция генерации пароля доступна при установленном расширении psql_rotate_password.

Настраиваемые параметры для генерации пароля:

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

  rotate_password.num_rounds = '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;

Настройка подключения к Хранилищу секретов#

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

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

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

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

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

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

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

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

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

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

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

/usr/pangolin-{version}/bin/setup_kms_credentials -c {cluster_id} -h {IP-адрес} -p {Порт} -t {тип авторизации} -i {логин пользователя}

К обязательным параметрам относятся:

• -c - идентификатор кластера;

• -h - IP-адрес узла;

• -p - порт для подключения;

• -t - тип авторизации;

• -i - логин пользователя.

Тип авторизации (значение параметра -t) может принимать значения:

• 1 - для Userpass-авторизации;

• 2 - для Approle-авторизации.

Примечание:

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

Необязательные параметры:

• --purpose - назначение (сертификаты certs или секреты secrets). Значение по умолчанию - secrets;

• --format/-f - формат вывода (json, table - таблица). Значение по умолчанию - table;

• --protocol/-l - протокол (http или https). Значение по умолчанию - https;

• --prefix/-x - префикс пути. Значение по умолчанию - kv;

• --suffix/-u - суффикс пути. По умолчанию передаваемое значение отсутствует.

• --namespace/-n - пространство имен, по умолчанию не задано;

• --auth/-a - точка авторизации, по умолчанию не передается;

• --root-ca/-r - файл или папка с корневым сертификатом для проверки сервера Хранилища секретов. Если не задано, используется ближайшая доступная директория;

• --skip-confirm - настройка ввода, определяющая наличие/отсутствие подтверждения для редактирования или удаления записи;

• --index - индекс записи в режиме редактирования или удаления;

• --plain - вывод информации;

• --no-check - режим для отключения проверки параметров подключения к Хранилищу секретов;

• --debug - показать информацию для отладки.

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

Примечание:

Параметры root-caи suffix являются локальными параметрами отдельной записи. Единственный глобальный параметр - cluster_id.

Утилита setup_kms_credentials обеспечивает возможность задавать значения параметров root-ca и suffix (оба параметра расположены в разделе credentials) для каждого отдельного подключения к хранилищу секретов/сертификатов.

Если файл /etc/postgres/enc_connection_settings.cfg (/etc/postgres/enc_connection_settings_cert.cfg) имеет старый формат, root-ca и suffix не заданы для конкретного подключения, то для обеспечения совместимости утилита дублирует эти два параметра для каждого отдельного подключения.

Если соединение было создано с помощью новой версии программы, а параметры root-ca и suffix не были заданы, то в файл с параметрами подключений к хранилищу секретов/сертификатов /etc/postgres/enc_connection_settings.cfg (/etc/postgres/enc_connection_settings_cert.cfg) будут записаны пустые значения для данных параметров. В выводе команды show для параметра root-ca будет указываться реально используемое (вычисляемое) значение данного параметра для каждой записи, а при выводе в json-формат значение по умолчанию будет соответствовать True в поле root_ca_calculated. В табличном выводе параметр root_ca_calculated не указывается.

Примечание:

Если при добавлении новой записи в файл с параметрами подключения к хранилищу секретов/сертификатов, указать параметр cluster-id, отличный от уже записанного, утилита заканчивает работу с ошибкой: Error: wrong cluster-id {wrong cluster-id}, credentials was set for {correct cluster-id}.

Удаление файла с параметрами подключения к хранилищу секретов/сертификатов#

Утилита setup_kms_credentials удаляет файл /etc/postgres/enc_connection_settings.cfg (/etc/postgres/enc_connection_settings_cert.cfg), если он не содержит записей с параметрами подключения к хранилищу секретов/сертификатов сразу после операции удаления последней записи:

[kmadmin_pg@srv-64-96 ~]$ ls -lh /etc/postgres/enc_connection_settings.cfg
-rw-r--r-- 1 kmadmin_pg kmadmin_pg 328 May  6 10:27 /etc/postgres/enc_connection_settings.cfg

[kmadmin_pg@srv-64-96 ~]$ /usr/pangolin-6.3.0/bin/setup_kms_credentials delete --index=0 --skip-confirm

[kmadmin_pg@srv-64-96 ~]$ ls -lh /etc/postgres/enc_connection_settings.cfg
ls: cannot access '/etc/postgres/enc_connection_settings.cfg': No such file or directory

Если файл был удален, то при последующем создании новой записи с параметрами подключения к хранилищу секретов/сертификатов необходимо заново ввести значение cluster-id:

[kmadmin_pg@srv-64-96 ~]$ /usr/pangolin-6.3.0/bin/setup_kms_credentials add --cluster ZVO --host <IP-адрес> --port 8200 --type 1 -i secmanLogIn --purpose secrets --no-check
Enter password:
**************

Confirm password:
**************

Credentials for Secret storage has been added successfully

При отсутствии файла /etc/postgres/enc_connection_settings.cfg (/etc/postgres/enc_connection_settings_cert.cfg) команда show утилиты setup_kms_credentials выводит сообщение No credentials specified или {} для JSON-формата:

[kmadmin_pg@srv-64-96 ~]$ ls -lh /etc/postgres/enc_connection_settings.cfg
ls: cannot access '/etc/postgres/enc_connection_settings.cfg': No such file or directory

[kmadmin_pg@srv-64-96 ~]$ /usr/pangolin-6.3.0/bin/setup_kms_credentials show
No credentials specified

[kmadmin_pg@srv-64-96 ~]$ /usr/pangolin-6.3.0/bin/setup_kms_credentials show --format=json
{}

Режим deletall#

Режим deleteall используется совместно с флагом --purposeи удаляет файл /etc/postgres/enc_connection_settings.cfg (/etc/postgres/enc_connection_settings_cert.cfg).

Если в качестве значения флага установлено certs (deleteall --purpose=certs), то будет удален файл с параметрами подключения к хранилищу сертификатов /etc/postgres/enc_connection_settings_cert.cfg:

[kmadmin_pg@srv-64-96 ~]$ ls -lh /etc/postgres/enc_connection_settings_cert.cfg
-rw-r--r-- 1 kmadmin_pg kmadmin_pg 376 May  6 11:32 /etc/postgres/enc_connection_settings_cert.cfg

[kmadmin_pg@srv-64-96 ~]$ /usr/pangolin-6.3.0/bin/setup_kms_credentials deleteall --purpose=certs --skip-confirm

[kmadmin_pg@srv-64-96 ~]$ ls -lh /etc/postgres/enc_connection_settings_cert.cfg
ls: cannot access '/etc/postgres/enc_connection_settings_cert.cfg': No such file or directory

[kmadmin_pg@srv-64-96 ~]$ ls -lh /etc/postgres/enc_connection_settings.cfg
-rw-r--r-- 1 kmadmin_pg kmadmin_pg 328 May  6 10:27 /etc/postgres/enc_connection_settings.cfg

Если значение флага соответствует secrets (deleteall --purpose=secrets), то файл с параметрами подключения к хранилищу секретов /etc/postgres/enc_connection_settings.cfg будет удален:

[kmadmin_pg@srv-64-96 ~]$ ls -lh /etc/postgres/enc_connection_settings.cfg
-rw-r--r-- 1 kmadmin_pg kmadmin_pg 328 May  6 10:27 /etc/postgres/enc_connection_settings.cfg

[kmadmin_pg@srv-64-96 ~]$ /usr/pangolin-6.3.0/bin/setup_kms_credentials deleteall --purpose=secrets --skip-confirm

[kmadmin_pg@srv-64-96 ~]$ ls -lh /etc/postgres/enc_connection_settings.cfg
ls: cannot access '/etc/postgres/enc_connection_settings.cfg': No such file or directory

[kmadmin_pg@srv-64-96 ~]$ ls -lh /etc/postgres/enc_connection_settings_cert.cfg
-rw-r--r-- 1 kmadmin_pg kmadmin_pg 376 May  6 11:32 /etc/postgres/enc_connection_settings_cert.cfg

При попытке вызвать команду deleteall, когда файл с параметрами подключения к хранилищу секретов/сертификатов уже удален, команда не выполнится, а в консоль будет выведено сообщение File enc_connection_settings.cfg does not exist или File enc_connection_settings_cert.cfg does not exist, если флаг --purpose при вызове команды был установлен в значение certs:

[kmadmin_pg@srv-64-96 ~]$ ls -lh /etc/postgres/enc_connection_settings.cfg
ls: cannot access '/etc/postgres/enc_connection_settings.cfg': No such file or directory

[kmadmin_pg@srv-64-96 ~]$ /usr/pangolin-6.3.0/bin/setup_kms_credentials deleteall --purpose=secrets --skip-confirm
File enc_connection_settings.cfg does not exist

[kmadmin_pg@srv-64-96 ~]$ ls -lh /etc/postgres/enc_connection_settings_cert.cfg
ls: cannot access '/etc/postgres/enc_connection_settings_cert.cfg': No such file or directory

[kmadmin_pg@srv-64-96 ~]$ /usr/pangolin-6.3.0/bin/setup_kms_credentials deleteall --purpose=certs --skip-confirm
File enc_connection_settings_cert.cfg does not exist

Если не указан флаг --purpose, то утилита закончит работу с ошибкой Error: --purpose not specified:

[kmadmin_pg@srv-64-96 ~]$ /usr/pangolin-6.3.0/bin/setup_kms_credentials deleteall --skip-confirm
Error: --purpose not specified

Мониторинг работы утилиты#

При вызове setup_kms_credentials delete в случае не заданного индекса будет получено сообщение об ошибке:

Error:  Index to delete not specified

При вызове операции delete утилиты setup_kms_credentials на несуществующем хранилище будет получен вывод об ошибке:

Error: File enc_connection_settings.cfg does not exist

Внимание!

Новый формат файлов /etc/postgres/enc_connection_settings.cfg(/etc/postgres/enc_connection_settings_cert.cfg) обратно не совместим с более ранними версиями СУБД Pangolin.

Любые изменения в файле /etc/postgres/enc_connection_settings.cfg(/etc/postgres/enc_connection_settings_cert.cfg): создание, редактирование или удаление записи с параметрами подключения к хранилищу секретов/сертификатов, логируются в syslog:

[kmadmin_pg@srv-64-96 ~]$ /usr/pangolin-6.3.0/bin/setup_kms_credentials add -h <IP-адрес> -p 8200 -u pang -t 1 -r -i adminencryption --no-check
Enter password:
**************
Confirm password:
**************

Credentials for Secret storage has been added successfully

[kmadmin_pg@srv-64-96 ~]$ /usr/pangolin-6.3.0/bin/setup_kms_credentials delete --index 1 --skip-confirm

Credentials for Secret storage has been removed successfully

[kmadmin_pg@srv-64-96 ~]$ exit
[pprb_dev@srv-64-96 ~]$ sudo journalctl -q --since "2024-05-21 15:43:57" --until "2024-05-21 15:44:55" | grep setup_kms_credentials

May 21 15:44:07 srv-64-114.db.dev.sbt setup_kms_credentials[102792]: Credentials for Secret storage has been added successfully
May 21 15:44:50 srv-64-114.db.dev.sbt setup_kms_credentials[102831]: Credentials for Secret storage has been removed successfully

При выполнении команд setup, edit или add утилита setup_kms_credentials осуществляет проверку добавляемой или редактируемой записи с параметрами подключения.

В зависимости от результата проверки, дополнительно к сообщению о произведенном действии, будет выведено сообщение Credentials check ok, если проверка пройдена, или сообщение Credentials check failed, если проверка не пройдена:

[kmadmin_pg@srv-64-96 ~]$ /usr/pangolin-{version}/bin/setup_kms_credentials -c {user} -h <IP-адрес> -p 8200 -u postgresql -t 1 -r -i adminencryption
Enter password:
**************
Confirm password:
**************

Credentials check ok
Credentials for Secret storage has been set successfully

[kmadmin_pg@srv-64-96 ~]$ /usr/pangolin-{version}/bin/setup_kms_credentials add -h <IP-адрес> -p 8200 -r -u -t 1 -i fake_login
Enter password:
**************

Confirm password:
**************

Credentials check failed
Credentials for Secret storage has been added successfully

Для отключения вывода сообщения будет использоваться существующий ключ --no-check:

[kmadmin_pg@srv-64-96 ~]$ /usr/pangolin-{version}/bin/setup_kms_credentials add -h <IP-адрес> -p 8200 -r -u -t 1 -i fake_login --no-check
Enter password:
**************

Confirm password:
**************
Credentials for Secret storage has been added successfully

Ключ --verify учитывает результат проверки при выполнении запрашиваемой операции: если проверка не пройдена, утилита заканчивает работу с ошибкой, запись не добавляется/не изменяется:

[kmadmin_pg@srv-64-96 ~]$ /usr/pangolin-{version}/bin/setup_kms_credentials -c Fake_c_id -h <IP-адрес> -p 8200 -r -u -t 1 -i fake_login --verify
Enter password:
**************

Confirm password:
**************

Credentials check failed
Error: Credentials for Secret storage not set

[kmadmin_pg@srv-64-96 ~]$ /usr/pangolin-{version}/bin/setup_kms_credentials add -h <IP-адрес> -p 8200 -r -u -t 1 -i fake_login --verify
Enter password:
**************

Confirm password:
**************

Credentials check failed
Error: Credentials for Secret storage not added

[kmadmin_pg@srv-64-96 ~]$ /usr/pangolin-{version}/bin/setup_kms_credentials edit --index 0 -h <IP-адрес> -s fake_suffix --verify
Enter password:
**************

Confirm password:
**************

Credentials check failed
Error: Credentials for Secret storage not edited

Ключи --verify и --no-check не совместимы - утилита заканчивает работу с ошибкой, если указать их вместе:

[kmadmin_pg@srv-64-96 ~]$ /usr/pangolin-6.3.0/bin/setup_kms_credentials add -h <IP-адрес> -p 8200 -r -u -t 1 -i fake_login --verify --no-check
Error: keys --verify and --no-check cannot be used together

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

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

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

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

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

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

SELECT check_kms_is_on();

При успешном подключении на выходе функции будет получено значение true, в противном случае — false.

Режимы работы утилиты#

Режимы работы утилиты:

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

• show - показать текущий набор параметров подключений к хранилищам секретов/сертификатов (без паролей и идентификаторов секретов);

• add - добавить новую запись в набор параметров подключений к хранилищам секретов/сертификатов;

• delete - удалить запись из набора параметров подключений к хранилищам секретов/сертификатов по номеру записи;

• edit - редактировать запись из набора параметров подключений к хранилищам секретов/сертификатов по номеру записи.

Примечание:

Начиная с версии 5.4.0, отсутствует обратная совместимость обновления по параметру suffix.

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

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

[user ~]$ /usr/pangolin-{version}/bin/setup_kms_credentials show --plain
Pangolin cluster ID: {cluster_id}
+------------------------------------------------------------------------------------------------------------------------------------------------------------+
|  # | protocol |        host | port |     root CA path |  suffix | prefix | namespace |            cred type | auth point |              id |        status |
-----+----------+-------------+------+------------------+---------+--------+-----------+----------------------+------------+-----------------+----------------
|  0 |    https | <IP-адрес>  | 8200 | /pg_ssl/root_di1 | suffix1 |     kv |           | Userpass Auth Method |   userpass | adminencryption |            Ok |
|  1 |    https | <IP-адрес>  | 8200 | /pg_ssl/root_di2 | suffix2 |     kv |           | Userpass Auth Method |   userpass | adminencryption |            Ok |
+------------------------------------------------------------------------------------------------------------------------------------------------------------+

[kmadmin_pg@srv-64-96 ~]$ /usr/pangolin-{version}/bin/setup_kms_credentials show --purpose=certs --plain
Pangolin cluster ID: test
+-----------------------------------------------------------------------------------------------------------------------------------------------------------------+
|  # | protocol |       host | port |     root CA path |  suffix | prefix |             namespace |            cred type | auth point |              id |  status |
-----+----------+------------+------+------------------+---------+--------+-----------------------+----------------------+------------+-----------------+----------
|  0 |    https | <IP-адрес> | 8203 | /pg_ssl/root_di1 |  pango1 | SBERCA | CI00000000_CI00000000 | Userpass Auth Method |   userpass | adminencryption |      Ok |
|  1 |    https | <IP-адрес> | 8203 | /pg_ssl/root_di2 |  pango2 | SBERCA | CI00000000_CI00000000 | Userpass Auth Method |   userpass | adminencryption |      Ok |
+-----------------------------------------------------------------------------------------------------------------------------------------------------------------+

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

Пример команды просмотра записей в JSON-формате:

[user ~]$ /usr/pangolin-{version}/bin/setup_kms_credentials show --format=json
{
	"cluster_id" : "test",
	"credentials" :
	[
		{
			"auth_point" : "userpass",
			"host" : {IP-адрес},
			"id" : "qewr",
			"namespace" : "",
			"port" : {Порт},
			"prefix" : "kv",
			"protocol" : "HTTPS",
			"status" : "Storage error",
			"type" : "USER_PASS"
		},
		{
			"auth_point" : "userpass",
			"host" : {IP-адрес},
			"id" : "qwer",
			"namespace" : "",
			"port" : {Порт},
			"prefix" : "kv",
			"protocol" : "HTTPS",
			"status" : "Storage error",
			"type" : "USER_PASS"
		}
	],
	"root_ca" : "/pg_ssl",
	"suffix" : ""
}

[user ~]$ /usr/pangolin-{version}/bin/setup_kms_credentials show --purpose=certs --format=json
{
        "cluster_id" : "test",
        "credentials" :
        [
                {
                        "auth_point" : "userpass",
                        "host" : {IP-адрес},
                        "id" : "adminencryption",
                        "namespace" : "CI00000000_CI00000000",
                        "port" : {Порт},
                        "prefix" : "SBERCA",
                        "protocol" : "HTTPS",
                        "root_ca" : "/pg_ssl/root_di1",
                        "root_ca_calculated" : "false",
                        "status" : "Ok",
                        "suffix" : "pango1",
                        "type" : "USER_PASS"
                },
                {
                        "auth_point" : "userpass",
                        "host" : {IP-адрес},
                        "id" : "adminencryption",
                        "namespace" : "CI00000000_CI00000000",
                        "port" : {Порт},
                        "prefix" : "SBERCA",
                        "protocol" : "HTTPS",
                        "root_ca" : "/pg_ssl/root_di2",
                        "root_ca_calculated" : "false",
                        "status" : "Ok",
                        "suffix" : "pango2",
                        "type" : "USER_PASS"
                }
        ]
}