Файл pg_hba.conf

Описание

Аутентификация клиентов управляется файлом конфигурации, который традиционно называется pg_hba.conf и хранится в каталоге данных кластера баз данных. (HBA расшифровывается как host-based authentication — аутентификация по узлу.) Стандартный файл pg_hba.conf устанавливается при инициализации каталога данных утилитой initdb. Однако файл конфигурации аутентификации можно разместить в любом другом месте; см. параметр конфигурации hba_file.

Общий формат файла pg_hba.conf — набор записей, по одной на строку. Пустые строки игнорируются, как и любой текст после знака отбивки комментария (#). Запись можно продолжить на следующей строке, завершив текущую строку обратным слэшем. (Обратный слэш является спецсимволом только в конце строки.) Запись состоит из ряда полей, разделенных пробелами и/или табуляциями. Поля могут содержать пробелы, если значение поля заключено в кавычки. Если в кавычки берется одно из ключевых слов в поле базы данных, пользователя или адреса (например, all или replication), это слово теряет свое особое значение и просто обозначает базу данных, пользователя или хост с этим именем. Обратный слэш означает перенос строки даже в тексте в кавычках или комментариях.

В каждой записи указывается тип соединения, диапазон IP-адресов клиента (если это важно для типа соединения), имя базы данных, имя пользователя и метод аутентификации, который будет использован для подключения в соответствии с этими параметрами. Первая же запись с соответствующим типом соединения, адресом клиента, требуемой базой данных и именем пользователя используется для аутентификации. Процедуры «передачи управления вниз» или «резервирования» отсутствуют: если выбрана запись и аутентификация провалилась, последующие записи не рассматриваются. Если ни одна запись не подходит, в доступе будет отказано.

Форматы записи и значения полей

Запись может иметь несколько форматов:

local         база_данных  пользователь  метод-аутентификации [параметры-аутентификации]
host          база_данных  пользователь  адрес     метод-аутентификации  [параметры-аутентификации]
hostssl       база_данных  пользователь  адрес     метод-аутентификации  [параметры-аутентификации]
hostnossl     база_данных  пользователь  адрес     метод-аутентификации  [параметры-аутентификации]
hostgssenc    база_данных  пользователь  адрес     метод-аутентификации  [параметры-аутентификации]
hostnogssenc  база_данных  пользователь  адрес     метод-аутентификации  [параметры-аутентификации]
host          база_данных  пользователь  IP-адрес  IP-маска      метод-аутентификации  [параметры-аутентификации]
hostssl       база_данных  пользователь  IP-адрес  IP-маска      метод-аутентификации  [параметры-аутентификации]
hostnossl     база_данных  пользователь  IP-адрес  IP-маска      метод-аутентификации  [параметры-аутентификации]
hostgssenc    база_данных  пользователь  IP-адрес  IP-маска      метод-аутентификации  [параметры-аутентификации]
hostnogssenc  база_данных  пользователь  IP-адрес  IP-маска      метод-аутентификации  [параметры-аутентификации]

Эти поля имеют следующие значения:

local
Эта запись соответствует попыткам подключения через сокеты домена Unix. Без записи этого типа подключения через сокеты домена Unix не допускаются.

host
Эта запись соответствует попыткам подключения по TCP/IP. Записи host соответствуют попыткам подключения с SSL или без SSL, а также попыткам подключения с криптографической защитой GSSAPI или без GSSAPI.

Примечание
Удаленные подключения по TCP/IP будут невозможны, если сервер запущен без соответствующего значения для параметра конфигурации listen_addresses, поскольку по умолчанию система принимает подключения по TCP/IP только для локального loopback-адреса localhost.

hostssl
Эта запись соответствует попыткам подключения по TCP/IP, но только когда это подключение устанавливается с шифрованием SSL.

Чтобы воспользоваться этим параметром, сервер должен быть собран с поддержкой SSL. Более того, SSL должен быть включен параметром конфигурации ssl. В противном случае запись hostssl игнорируется, не считая вывода предупреждения о том, что ей не будут соответствовать никакие подключения.

hostnossl
У этого типа записей поведение противоположно hostssl; ему соответствуют только попытки подключения по TCP/IP без шифрования SSL.

hostgssenc
Эта запись соответствует попыткам подключения по TCP/IP, но только когда это подключение устанавливается с шифрованием GSSAPI.

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

hostnogssenc
У этого типа записей поведение противоположно hostgssenc; ему соответствуют только попытки подключения по TCP/IP без шифрования GSSAPI.

база_данных
Определяет, какому имени (или именам) базы данных соответствует эта запись. Значение all указывает, что она соответствует всем базам данных. Значение sameuser указывает, что эта запись соответствует, если имя запрашиваемой базы данных совпадает с именем запрашиваемого пользователя. Значение samerole указывает, что запрашиваемый пользователь должен быть членом роли с тем же именем, что и у запрашиваемой базы данных. (samegroup — это устаревший, но все еще принимаемый вариант значения samerole.) Суперпользователи считаются членами роли в контексте samerole, только если они явно входят в такую роль, непосредственно или опосредованно; просто быть суперпользователем для этого недостаточно. Значение replication указывает, что эта запись соответствует, если запрашивается подключение физической репликации, однако при этом не соответствует подключениям логической репликации. Обратите внимание, что для подключения физической репликации не указывается никакая конкретная база данных, тогда как для подключений логической репликации она должна указываться. Любое другое значение воспринимается как имя конкретной базы данных QHB. Можно задать несколько имен баз данных, разделив их запятыми. Кроме того, можно задать отдельный файл с именами баз данных, написав имя этого файла после знака @.

пользователь
Определяет, какому имени (или именам) пользователя базы данных соответствует эта запись. Значение all указывает, что она соответствует всем пользователям. Любое другое значение воспринимается либо как имя конкретного пользователя базы данных, либо как имя группы, если написать его после знака +. (Напомним, что в QHB нет никакой разницы между пользователями и группами; знак + фактически означает «соответствует любым ролям, которые непосредственно или опосредованно являются членами этой роли», тогда как имя без знака + соответствует только этой конкретной роли.) По этой причине суперпользователь рассматривается как член роли, только если он явно является членом этой роли, непосредственно или опосредованно; просто быть суперпользователем для этого недостаточно. Можно задать несколько имен пользователей, разделив их запятыми. Кроме того, можно задать отдельный файл с именами пользователей, написав имя этого файла после знака @.

адрес
Задает адрес (или адреса) клиентской машины, которым соответствует эта запись. Это поле может содержать либо имя хоста, либо диапазон IP-адресов, либо одно из упомянутых ниже ключевых слов.

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

Типичные примеры диапазона адресов IPv4, заданных таким образом: 172.20.143.89/32 для одного хоста, 172.20.143.0/24 for для небольшой и 10.6.0.0/16 для более крупной сети. Диапазон адресов IPv6 может выглядеть как ::1/128 для одного хоста (это loopback-адрес IPv6) или как fe80::7a31:c1ff:0000:0000/96 для небольшой сети. 0.0.0.0/0 представляет все адреса IPv4, а ::0/0 — все адреса IPv6. Чтобы указать один хост, используйте длину маски 32 для IPv4 или 128 для IPv6. Не опускайте замыкающие нули в сетевом адресе.

Запись, сделанная в формате IPv4, будет соответствовать только подключениям по IPv4, а запись в формате IPv6 — только подключениям по IPv6, даже если представленный адрес находится в диапазоне IPv4-в-IPv6. Обратите внимание, что записи в формате IPv6 не будут приниматься, если системная библиотека C не поддерживает адреса IPv6.

Также можно написать значение all для соответствия записи любому адресу IP, samehost для соответствия любым IP-адресам данного сервера или samenet для соответствия любому адресу любой подсети, к которой сервер подключен напрямую.

Если задано имя хоста (все, что не является диапазоном адресов IP или специальным ключевым словом, воспринимается как имя хоста), это имя сравнивается с результатом обратного преобразования имени IP-адреса клиента (например, обратного DNS-поиска, если используется DNS). При сравнении имен хостов регистр не учитывается. Если имена совпали, выполняется прямое преобразование имени хоста (например, прямой DNS-поиск) для проверки, совпадает ли какой-либо из разрешенных адресов с IP-адресом клиента. Если двусторонняя проверка пройдена, запись считается соответствующей хосту. (Имя хоста в файле pg_hba.conf должно быть тем, что возвращается при преобразовании IP-адреса клиента в имя, иначе строка не будет соответствовать узлу. Некоторые базы имен хостов позволяют связать один IP-адрес с несколькими именами хостов, но операционная система при запросе на разрешение IP-адреса вернет только одно имя.)

Указание имени хоста, начинающееся с точки (.), соответствует суффиксу актуального имени хоста. Так, .example.com будет соответствовать foo.example.com (а не только example.com).

Когда в pg_hba.conf указываются имена хостов, следует добиться того, чтобы разрешение имен выполнялось достаточно быстро. Для этого может быть полезно установить локальный кэш разрешения имен, например, nscd. Также можно включить параметр конфигурации log_hostname, чтобы видеть в журнале имя хоста клиента вместо IP-адреса.

Эти поля не применимы к записям local.

Примечание
Иногда пользователи задаются вопросом, почему имена хостов обрабатываются таким сложным, на первый взгляд, способом, с разрешениями двух имен, включая обратный поиск IP-адреса клиента. Это усложняет использование этой функциональности в случае, если обратная DNS-запись клиента не установлена или выдает какое-нибудь нежелательное имя хоста. Это сделано, в первую очередь, из соображений эффективности: при таком подходе попытка подключения требует максимум два поиска разрешения, один обратный и один прямой. Если есть проблема разрешения с каким-то адресом, она становится проблемой только этого клиента. Гипотетическая альтернативная реализация, при которой выполнялись бы только прямые поиски, могла бы разрешать все имена хостов, упомянутые в pg_hba.conf во время каждой попытки подключения. Но если перечислено много имен, этот процесс был бы довольно медленным. И в случае наличия проблемы разрешения у одного имени хоста, это становится общей проблемой.

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

Обратите внимание, что это поведение согласуется с другими популярными реализациями управления доступом на основе имен хостов, такими как Apache HTTP Server и TCP Wrappers.

IP-адрес
IP-маска
Эти два поля можно использовать как альтернативу записи IP-адрес/длина-маски. Вместо того, чтобы указывать длину маски, в отдельном столбце указывается сама маска. Например, 255.0.0.0 представляет собой маску CIDR для IPv4 длиной 8 бит, а 255.255.255.255 представляет маску CIDR длиной 32 бита.

Эти поля не применимы к записям local.

метод-аутентификации
Задает метод аутентификации, который будет использован, когда подключение соответствует этой записи. Варианты выбора перечислены ниже; подробности см. в разделе Методы аутентификации.

trust
Разрешить безусловное подключение. Этот метод позволяет любому, кто может подключиться к серверу базы данных QHB, войти под любым желаемым пользователем QHB без необходимости вводить пароль или какой-либо другой аутентификации. Подробности см. в подразделе Аутентификация trust.

reject
Отклонить безусловное подключение. Это полезно для «отфильтровывания» некоторых хостов из группы, например, строка reject может заблокировать подключение от определенного хоста, тогда как следующая строка позволит подключиться остальным хостам в той же сети.

scram-sha-256
Выполнить аутентификацию SCRAM-SHA-256 для проверки пароля пользователя. Подробности см. в подразделе Аутентификация по паролю.

md5
Выполнить аутентификацию SCRAM-SHA-256 или MD5 для проверки пароля пользователя. Подробности см. в подразделе Аутентификация по паролю.

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

gss
Использовать GSSAPI для аутентификации пользователя. Этот метод доступен только для подключений по TCP/IP. Подробности см. в подразделе Аутентификация GSSAPI. Его можно применять в сочетании с шифрованием GSSAPI.

ident
Получить имя пользователя операционной системы клиента, связываясь с сервером ident, и проверить, соответствует ли оно имени пользователя запрашиваемой базы данных. Аутентификацию ident можно использовать только при подключениях по TCP/IP. Если указать этот метод для локальных подключений, вместо него будет применяться аутентификация peer. Подробности см. в подразделе Аутентификация ident.

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

ldap
Провести аутентификацию, используя сервер LDAP. Подробности см. в подразделе Аутентификация LDAP.

radius
Провести аутентификацию, используя сервер RADIUS. Подробности см. в подразделе Аутентификация RADIUS.

cert
Провести аутентификацию, используя клиентские сертификаты SSL. Подробности см. в подразделе Аутентификация по сертификату.

pam
Провести аутентификацию, используя службу подключаемых модулей аутентификации (Pluggable Authentication Modules, PAM), предоставляемую операционной системой. Подробности см. в подразделе Аутентификация PAM.

bsd
Провести аутентификацию, используя службу аутентификации BSD, предоставляемую операционной системой. Подробности см. в подразделе Аутентификация BSD.
.

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

Кроме перечисленных ниже параметров, относящихся к различным методам, есть один общий параметр аутентификации clientcert, который можно задать в любой записи hostssl. Этот параметр может принимать значения verify-ca и verify-full. В обоих случаях требуется, чтобы клиент предоставил действительный (доверенный) сертификат SSL, но вариант verify-full дополнительно требует, чтобы значение cn (Common Name, общее имя) в сертификате соответствовало имени пользователя или применимому сопоставлению. Это поведение схоже с методом аутентификации cert (см. подраздел Аутентификация по сертификату), но позволяет связать проверку сертификатов клиента с любым методом аутентификации, поддерживающим записи hostssl.

В любой записи, где используется аутентификация по сертификату клиента (т. е. в записи с методом аутентификации cert или с параметром clientcert), в параметре clientname можно указать, какая часть учетных данных в сертификате клиента будет сопоставляться при проверке. Этот параметр может принимать одно из двух значений. Если задано значение clientname=CN (это значение по умолчанию), имя пользователя сопоставляется с полем сертификата Common Name (CN). Если задано значение clientname=DN, имя пользователя сопоставляется со всем отличительным именем, Distinguished Name (DN), в сертификате. Этот параметр, вероятно, лучше всего применять в сочетании с сопоставлением пользователя. Сравнение с DN выполняется в формате RFC 2253. Чтобы просмотреть в этом формате поле DN сертификата клиента, выполните

openssl x509 -in myclient.crt -noout --subject -nameopt RFC2253 | sed "s/^subject=//"

Использовать этот параметр следует с осторожностью, особенно когда для сопоставлений с DN применяются регулярные выражения.
.

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

Поскольку записи в pg_hba.conf просматриваются последовательно для каждой попытки подключения, порядок записей имеет большое значение. Обычно более ранние записи содержат жесткие параметры соответствия для подключения и более гибкие методы аутентификации, тогда как в более поздних записях параметры соответствия менее требовательны, а методы аутентификации более строгие. Например, некто желает использовать аутентификацию trust для локальных подключений по TCP/IP, но при этом запрашивать пароль для удаленных подключений по TCP/IP. В этом случае запись, задающая аутентификацию trust для подключений с адреса 127.0.0.1 должна предшествовать записи, задающей аутентификацию по пароль для более широкого диапазона клиентских IP-адресов.

Файл pg_hba.conf прочитывается при запуске системы, а также при получении основным серверным процессом сигнала SIGHUP. При редактировании этого файла во время работы системы необходимо послать сигнал процессу postmaster (воспользовавшись pg_ctl reload, вызвав функцию SQL pg_reload_conf() или выполнив kill -HUP), чтобы он заново прочел файл.

Системное представление pg_hba_file_rules может быть полезно для предварительной проверки изменений в файле pg_hba.conf или для диагностики проблем, если загрузка этого файла не привела к желаемым результатам. Строки в этом представлении, содержащие в поле error не NULL, указывают на проблемы в соответствующих строках файла.

Совет
Чтобы подключиться к определенной базе данных, пользователь должен не только пройти проверки файла pg_hba.conf, но и иметь право CONNECT для этой базы данных. Если требуется ограничить доступ к каким-либо базам данных для определенных пользователей, как правило, этим проще управлять, предоставляя/ отзывая право CONNECT, нежели устанавливая правила в записях pg_hba.conf.

Некоторые примеры записей файла pg_hba.conf показаны в Примере 1 ниже. Более подробную информацию о различных методах аутентификации см. в следующем разделе.

Пример 1. Пример записей pg_hba.conf

# Позволить любому пользователю локальной системы подключаться к любой базе данных,
# используя любое имя пользователя баз данных, через сокеты домена Unix
# (по умолчанию для локальных подключений).
#
# TYPE  DATABASE        USER            ADDRESS                 METHOD
  local all             all                                     trust

# То же самое, но для локальных подключений loopback по TCP/IP.
#
# TYPE  DATABASE        USER            ADDRESS                 METHOD
  host  all             all             127.0.0.1/32            trust

# То же, что и в предыдущей строке, но с указанием сетевой маски в отдельном столбце
#
# TYPE  DATABASE        USER            IP-ADDRESS      IP-MASK             METHOD
  host  all             all             127.0.0.1       255.255.255.255     trust

# То же самое для IPv6.
#
# TYPE  DATABASE        USER            ADDRESS                 METHOD
  host  all             all             ::1/128                 trust

# То же самое, но с использованием имени хоста (обычно охватывает и IPv4, и IPv6).
#
# TYPE  DATABASE        USER            ADDRESS                 METHOD
  host  all             all             localhost               trust

# Позволить любому пользователю любого узла с IP-адресом 192.168.93.x подключаться
# к базе данных «qhb» с тем же именем пользователя, которое сообщает для данного
# подключения ident (как правило, имя пользователя операционной системы).
#
# TYPE  DATABASE        USER            ADDRESS                 METHOD
  host  qhb             all             192.168.93.0/24         ident

# Позволить любому пользователю узла 192.168.12.10 подключаться к базе данных
# «qhb», если передается правильный пароль пользователя.
#
# TYPE  DATABASE        USER            ADDRESS                 METHOD
  host  qhb             all             192.168.12.10/32        scram-sha-256

# Позволить любому пользователю хостов в домене example.com подключаться к
# любой базе данных, если передается правильный пароль пользователя.
#
# Для большинства пользователей требуется аутентификация SCRAM, за исключением
# пользователя 'mike', который использует более старый клиент, не поддерживающий
# аутентификацию SCRAM.
#
# TYPE  DATABASE        USER            ADDRESS                 METHOD
  host  all             mike            .example.com            md5
  host  all             all             .example.com            scram-sha-256

# В случае отсутствия предшествующих строчек с «host», эти три строки откажут
# в любых подключениях с 192.168.54.1 (поскольку эта запись будет сопоставлена
# первой), но разрешат подключения с шифрованием GSSAPI с любых других адресов
# интернета. С нулевой маской ни один бит из IP-адреса узла не учитывается,
# так что этой строке соответствует любой узел. Подключения без GSSAPI (которые
# «опускаются» до третьей строки, поскольку записи "hostgssenc" соответствуют
# только подключения с GSSAPI) разрешены, но только с адреса 192.168.12.10.
#
# TYPE       DATABASE        USER            ADDRESS                 METHOD
  host       all             all             192.168.54.1/32         reject
  hostgssenc all             all             0.0.0.0/0               gss
  host       all             all             192.168.12.10/32        gss

# Позволить пользователям с узлов 192.168.x.x подключаться к любой базе данных,
# если они проходят проверку ident.  Если же ident говорит, к примеру, что это
# пользователь "bryanh" и он запрашивает подключение как пользователь QHB "guest1",
# подключение будет разрешено, если в pg_ident.conf есть запись с сопоставлением
# "omicron", разрешающим пользователю "bryanh" подключаться как "guest1".
#
# TYPE  DATABASE        USER            ADDRESS                 METHOD
  host  all             all             192.168.0.0/16          ident map=omicron

# Если для локальных подключений предусмотрены только эти три строки, они позволят
# локальным пользователям подключаться только к их собственным базам данных (базам
# данных с именами, совпадающими с их именами пользователей баз данных), за
# исключением администраторов и членов роли "support", которые могут подключаться
# ко всем базам данных. Список имен администраторов содержится в файле
# $PGDATA/admins. Пароли требуются в любом случае.
#
# TYPE   DATABASE         USER              ADDRESS               METHOD
  local  sameuser         all                                     md5
  local  all              @admins                                 md5
  local  all              +support                                md5

# Последние две строки выше можно объединить в одну:
  local  all              @admins,+support                        md5

# В столбце DATABASE также можно указывать списки и имена файлов:
  local  db1,db2,@demodbs all                                     md5