Аутентификация

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

Эта страница объясняет, как pg_doorman выбирает метод аутентификации. Подробности настройки смотрите по ссылкам каждого метода ниже.

Обзор методов

МетодКогда использоватьХранит ли секрет в конфиге?
Passthrough (MD5 / SCRAM)По умолчанию. Имя пользователя пула совпадает с пользователем PostgreSQL.Хеш MD5 или SCRAM ClientKey, никогда — открытый пароль
auth_queryМного пользователей, динамическое заведение. Учётные данные ищутся в самом PostgreSQL.Только секрет одного сервисного пользователя
PAMАутентификация на уровне OS (LDAP через pam_ldap, Kerberos, локальные учётки). Только Linux.Нет
JWTДоступ сервиса к базе по короткоживущим токенам, подписанным внешним IdP.Только публичный ключ
TalosJWT с встроенным извлечением роли. Используется в Ozon.Только публичный ключ
pg_hba.confОграничение того, кто откуда может подключаться (сетевой ACL), независимо от метода учётных данных.Нет

LDAP, Kerberos GSSAPI, аутентификация по сертификатам и SCRAM channel binding (scram-sha-256-plus) не поддерживаются. Смотрите Сравнение.

Порядок выбора метода

pg_hba.conf оценивается первым, до любой проверки учётных данных. Правило reject обрывает соединение; правило trust полностью пропускает проверку учётных данных.

После HBA pg_doorman выбирает метод проверки учётных данных в таком порядке:

  1. Talos. Активируется, когда клиент подключается с именем пользователя talos. Пароль клиента разбирается как JWT, из него извлекается роль (owner / read_write / read_only), и соединение продолжается под этой производной идентичностью.
  2. HBA Trust. Если pg_hba.conf совпал с правилом trust, проверки учётных данных не происходит.
  3. PAM. Если у совпавшего пользователя задан auth_pam_service, учётные данные уходят в PAM (только Linux). PAM приоритетнее статического пароля.
  4. SCRAM static. Если password пользователя в конфиге начинается с SCRAM-SHA-256$, pg_doorman запускает SCRAM-аутентификацию.
  5. MD5 static. Если password пользователя начинается с md5, pg_doorman запускает MD5-аутентификацию.
  6. JWT. Если password пользователя начинается с jwt-pkey-fpath:, пароль клиента проверяется как JWT по публичному ключу с диска.

auth_query не входит в этот список выбора — он выполняется до диспетчеризации, чтобы наполнить список пользователей пула хешами, полученными из PostgreSQL. После того как auth_query вернёт значение passwd, выбор метода идёт по префиксу этого значения (SCRAM-SHA-256$ или md5).

Если ни один метод не подошёл к формату пароля, pg_doorman возвращает «Authentication method not supported» и закрывает соединение.

Аутентификация на стороне PostgreSQL: passthrough vs configured

pg_doorman аутентифицируется дважды: один раз как шлюз (клиент → pg_doorman) и один раз как бэкенд (pg_doorman → PostgreSQL). Возможны три варианта:

  • Passthrough (по умолчанию). Хеш MD5 клиента или SCRAM ClientKey переиспользуется для аутентификации на PostgreSQL. В конфиге нет открытого пароля. Требует, чтобы server_username не был задан (или был равен имени клиента).
  • Заданный пользователь бэкенда. Установите server_username и server_password в блоке пользователя. pg_doorman будет аутентифицироваться на PostgreSQL под ними. Используйте, когда имя пользователя пула отвязано от пользователя базы (Talos, JWT, переименование).
  • auth_query в выделенном режиме. Установите server_user внутри блока auth_query. Все динамически найденные пользователи разделят один пул бэкенда, аутентифицированный как server_user. Это размен идентичности бэкенда на пользователя ради эффективности переиспользования пула.

Подробности смотрите в Passthrough, а про выделенный режим — в auth_query.

Ограничение подключений

pg_hba.conf применяется до проверки учётных данных. Распространённые шаблоны:

  • Отвергнуть всё кроме localhost: host all all 0.0.0.0/0 reject, а перед ним host all all 127.0.0.1/32 trust.
  • Требовать TLS для нелокальных соединений: hostssl all all 0.0.0.0/0 scram-sha-256 и hostnossl all all 127.0.0.1/32 trust.
  • ACL по базам: host mydb appuser 10.0.0.0/8 scram-sha-256.

Смотрите pg_hba.conf.

Куда дальше

  • Новая инсталляция? Прочтите Passthrough и Basic usage.
  • Много пользователей с ротируемыми учётными данными? Используйте auth_query.
  • Идентичность сервиса по токенам? Используйте JWT.
  • Аутентификация, интегрированная с OS? Используйте PAM.
  • Ограничения на сетевом уровне? Настройте pg_hba.conf.