Как проверить срок действия паролей ролей PostgreSQL

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

Представьте: приложение работает, база доступна, но бэкенд внезапно начинает сыпать ошибками вроде “password authentication failed”. Причина банальна: у сервисного пользователя истек срок действия пароля.

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

Давайте проверим, какие записи могут “протухнуть” в ближайший месяц.

SELECT
    rolname AS role_name,
    CASE
        WHEN rolsuper THEN 'Superuser'
        WHEN rolcanlogin THEN 'Service/User'
        ELSE 'Group/Nologin'
    END AS role_type,
    rolvaliduntil AS valid_until,
    ROUND(EXTRACT(EPOCH FROM (rolvaliduntil - now())) / 86400) AS days_left
FROM pg_roles
WHERE rolcanlogin = true
  AND rolvaliduntil IS NOT NULL
  AND rolvaliduntil < (now() + INTERVAL '30 days')
ORDER BY rolvaliduntil ASC;

Что делать с результатами?

Если список пуст — отлично, ваши пароли либо вечные (rolvaliduntil IS NULL), либо действуют еще долго.

Если нашли пользователя с days_left меньше, чем длительность ваших каникул:

• Либо обновите пароль сейчас (с обновлением конфигов приложения).

• Либо продлите срок действия старого пароля (если политики позволяют), чтобы спокойно заняться этим после праздников:

ALTER ROLE service_app VALID UNTIL '2026-02-01 00:00:00+03';

Дата в примере условная. Не продлевайте секрет автоматически: согласуйте действие с политикой безопасности, владельцем сервиса и процессом ротации. Понадобятся права на изменение конкретной роли; набор допустимых ролей зависит от вашей версии PostgreSQL и выданных административных полномочий, а не сводится только к суперпользователю.

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