pg_hba.conf #
La autenticación de clientes está controlada por un archivo de configuración,
que tradicionalmente se denomina
pg_hba.conf y se almacena en el directorio de
datos del clúster de la base de datos.
(HBA significa host-based authentication, autenticación basada en host). Se instala un archivo
pg_hba.conf por defecto cuando el directorio de datos
es inicializado por initdb. Sin embargo,
es posible colocar el archivo de configuración de autenticación en otro lugar;
consulta el parámetro de configuración hba_file.
El archivo pg_hba.conf se lee al arrancar y cuando
el proceso principal del servidor recibe una señal
SIGHUP.
Si editas el archivo en un sistema activo, tendrás que enviar una señal al postmaster
(utilizando pg_ctl reload, llamando a la función SQL
pg_reload_conf(), o utilizando kill
-HUP) para que vuelva a leer el archivo.
La afirmación anterior no es cierta en Microsoft Windows: allí, cualquier
cambio en el archivo pg_hba.conf se aplica inmediatamente
a las nuevas conexiones subsiguientes.
La vista del sistema
pg_hba_file_rules
puede ser útil para probar previamente los cambios en el archivo pg_hba.conf,
o para diagnosticar problemas si la carga del archivo no tuvo los efectos
deseados. Las filas de la vista con campos
error no nulos indican problemas en las
líneas correspondientes del archivo.
El formato general del archivo pg_hba.conf es
un conjunto de registros, uno por línea. Se ignoran las líneas en blanco, al igual que cualquier
texto posterior al carácter de comentario #.
Un registro puede continuarse en la línea siguiente finalizando la línea con
una barra invertida. (Las barras invertidas no son especiales excepto al final de una línea).
Un registro está formado por una serie de campos separados por espacios y/o tabuladores.
Los campos pueden contener espacios en blanco si el valor del campo está entre comillas dobles.
Poner entre comillas una de las palabras clave en un campo de base de datos, usuario o dirección (por ejemplo,
all o replication) hace que la palabra pierda su significado
especial y simplemente coincida con una base de datos, usuario o host con ese nombre.
La continuación de línea con barra invertida se aplica incluso dentro de texto entre comillas o comentarios.
Cada registro de autenticación especifica un tipo de conexión, un rango de direcciones IP de cliente (si es relevante para el tipo de conexión), un nombre de base de datos, un nombre de usuario y el método de autenticación que se utilizará para las conexiones que coincidan con estos parámetros. Se utiliza el primer registro con un tipo de conexión coincidente, dirección de cliente, base de datos solicitada y nombre de usuario para realizar la autenticación. No hay “fall-through” (continuación al siguiente) o “backup” (respaldo): si se elige un registro y la autenticación falla, no se consideran los registros siguientes. Si ningún registro coincide, se deniega el acceso.
Cada registro puede ser una directiva include o un registro de autenticación.
Las directivas include especifican archivos que se pueden incluir y que contienen
registros adicionales. Los registros se insertarán en lugar de las
directivas include. Las directivas include solo contienen dos campos:
la directiva include, include_if_exists o
include_dir y el archivo o directorio a
incluir. El archivo o directorio puede ser una ruta relativa o absoluta, y puede
estar entre comillas dobles. Para la forma include_dir, se incluirán todos los archivos
que no empiecen por un . y terminen por
.conf. Los múltiples archivos dentro de un directorio de inclusión
se procesan por orden de nombre de archivo (según las reglas de configuración regional de C,
es decir, los números antes que las letras, y las letras mayúsculas antes que las minúsculas).
Un registro puede tener varios formatos:
localdatabaseuserauth-method[auth-options] hostdatabaseuseraddressauth-method[auth-options] hostssldatabaseuseraddressauth-method[auth-options] hostnossldatabaseuseraddressauth-method[auth-options] hostgssencdatabaseuseraddressauth-method[auth-options] hostnogssencdatabaseuseraddressauth-method[auth-options] hostdatabaseuserIP-addressIP-maskauth-method[auth-options] hostssldatabaseuserIP-addressIP-maskauth-method[auth-options] hostnossldatabaseuserIP-addressIP-maskauth-method[auth-options] hostgssencdatabaseuserIP-addressIP-maskauth-method[auth-options] hostnogssencdatabaseuserIP-addressIP-maskauth-method[auth-options] includefileinclude_if_existsfileinclude_dirdirectory
El significado de los campos es el siguiente:
localEste registro coincide con los intentos de conexión que utilizan sockets de dominio Unix. Sin un registro de este tipo, las conexiones por socket de dominio Unix no están permitidas.
host
Este registro coincide con los intentos de conexión realizados mediante TCP/IP.
Los registros host coinciden con los intentos de
conexión SSL o no-SSL, así como con
los intentos de conexión cifrados con GSSAPI o no
cifrados con GSSAPI.
Las conexiones TCP/IP remotas no serán posibles a menos que el servidor
se inicie con un valor adecuado para el parámetro de configuración
listen_addresses, ya que el comportamiento por defecto
es escuchar las conexiones TCP/IP únicamente en la dirección de bucle
retorno local localhost.
hostsslEste registro coincide con los intentos de conexión realizados mediante TCP/IP, pero solo cuando la conexión se realiza con cifrado SSL.
Para hacer uso de esta opción, el servidor debe haber sido construido con
soporte de SSL. Además, SSL debe estar
habilitado configurando el parámetro de configuración ssl (consulta
Section 18.9 para más información).
De lo contrario, el registro hostssl se ignora, excepto por
el registro de una advertencia de que no puede coincidir con ninguna conexión.
hostnossl
Este tipo de registro tiene el comportamiento opuesto a hostssl;
solo coincide con los intentos de conexión realizados a través de
TCP/IP que no utilizan SSL.
hostgssencEste registro coincide con los intentos de conexión realizados mediante TCP/IP, pero solo cuando la conexión se realiza con cifrado GSSAPI.
Para hacer uso de esta opción, el servidor debe haber sido construido con
soporte de GSSAPI. De lo contrario,
el registro hostgssenc se ignora, excepto para registrar
una advertencia de que no puede coincidir con ninguna conexión.
hostnogssenc
Este tipo de registro tiene el comportamiento opuesto a hostgssenc;
solo coincide con los intentos de conexión realizados a través de
TCP/IP que no utilizan cifrado GSSAPI.
database
Especifica con qué nombre(s) de base de datos coincide este registro. El valor
all especifica que coincide con todas las bases de datos.
El valor sameuser especifica que el registro
coincide si la base de datos solicitada tiene el mismo nombre que el
usuario solicitado. El valor samerole especifica que
el usuario solicitado debe ser miembro del rol con el mismo
nombre que la base de datos solicitada. (samegroup es una
ortografía obsoleta pero aún aceptada de samerole).
Los superusuarios no se consideran miembros de un rol a efectos de
samerole a menos que sean miembros explícitos
del rol, directa o indirectamente, y no solo por el hecho de ser superusuarios.
El valor replication especifica que el registro
coincide si se solicita una conexión de replicación física, sin embargo, no
coincide con conexiones de replicación lógica. Ten en cuenta que las conexiones de
replicación física no especifican ninguna base de datos en particular, mientras que
las conexiones de replicación lógica sí la especifican.
De lo contrario, este es el nombre de una base de datos específica de
PostgreSQL o una expresión regular.
Se pueden proporcionar múltiples nombres de base de datos y/o expresiones regulares
separándolos con comas.
Si el nombre de la base de datos comienza con una barra diagonal (/), el
resto del nombre se trata como una expresión regular.
(Consulta Section 9.7.3.1 para más detalles sobre la
sintaxis de expresiones regulares de PostgreSQL).
Se puede especificar un archivo independiente que contenga nombres de bases de datos y/o expresiones
regulares anteponiendo @ al nombre del archivo.
user
Especifica con qué nombre(s) de usuario de la base de datos coincide
este registro. El valor all especifica que
coincide con todos los usuarios. De lo contrario, este es el nombre de un
usuario de base de datos específico, una expresión regular (cuando comienza con una barra
diagonal (/)), o un nombre de grupo precedido por +.
(Recuerda que no hay una distinción real entre usuarios y grupos
en PostgreSQL; una marca + realmente significa
“coincidir con cualquiera de los roles que son miembros directos o indirectos
de este rol”, mientras que un nombre sin la marca + coincide
solo con ese rol específico). Para este propósito, un superusuario solo se
considera miembro de un rol si es explícitamente miembro
del rol, directa o indirectamente, y no solo por el hecho de
ser superusuario.
Se pueden proporcionar múltiples nombres de usuario y/o expresiones regulares
separándolos con comas.
Si el nombre de usuario comienza con una barra diagonal (/), el
resto del nombre se trata como una expresión regular.
(Consulta Section 9.7.3.1 para más detalles sobre la
sintaxis de expresiones regulares de PostgreSQL).
Se puede especificar un archivo independiente que contenga nombres de usuario y/o expresiones regulares
anteponiendo @ al nombre del archivo.
addressEspecifica la(s) dirección(es) de la máquina cliente con la(s) que coincide este registro. Este campo puede contener un nombre de host, un rango de direcciones IP o una de las palabras clave especiales mencionadas a continuación.
Un rango de direcciones IP se especifica utilizando la notación numérica estándar
para la dirección inicial del rango, luego una barra diagonal (/)
y una longitud de máscara CIDR. La longitud de la máscara
indica el número de bits de orden superior de la dirección IP del cliente
que deben coincidir. Los bits a la derecha de estos deben ser cero
en la dirección IP proporcionada.
No debe haber ningún espacio en blanco entre la dirección IP, la
/ y la longitud de la máscara CIDR.
Ejemplos típicos de un rango de direcciones IPv4 especificado de esta manera son
172.20.143.89/32 para un único host, o
172.20.143.0/24 para una red pequeña, o
10.6.0.0/16 para una más grande.
Un rango de direcciones IPv6 podría ser ::1/128
para un único host (en este caso la dirección de bucle de retorno IPv6) o
fe80::7a31:c1ff:0000:0000/96 para una red pequeña.
0.0.0.0/0 representa todas las
direcciones IPv4, y ::0/0 representa todas las
direcciones IPv6.
Para especificar un único host, utiliza una longitud de máscara de 32 para IPv4 o
128 para IPv6. En una dirección de red, no omitas los ceros finales.
Una entrada proporcionada en formato IPv4 coincidirá únicamente con conexiones IPv4, y una entrada proporcionada en formato IPv6 coincidirá únicamente con conexiones IPv6, incluso si la dirección representada está en el rango IPv4-en-IPv6.
También puedes escribir all para que coincida con cualquier dirección IP,
samehost para que coincida con cualquiera de las direcciones IP del propio
servidor, o samenet para que coincida con cualquier dirección en cualquier
subred a la que el servidor esté directamente conectado.
Si se especifica un nombre de host (cualquier cosa que no sea un rango de direcciones IP
o una palabra clave especial se trata como un nombre de host),
ese nombre se compara con el resultado de una resolución inversa de nombres
de la dirección IP del cliente (por ejemplo, búsqueda DNS inversa, si se utiliza DNS).
Las comparaciones de nombres de host no distinguen entre mayúsculas y minúsculas.
Si hay coincidencia, se realiza una resolución directa de nombres (por ejemplo, búsqueda
DNS directa) en el nombre de host para comprobar si alguna de las direcciones a las que se resuelve es
igual a la dirección IP del cliente. Si ambas direcciones coinciden,
entonces se considera que la entrada coincide. (El nombre de host que se
utiliza en pg_hba.conf debe ser el que devuelva la
resolución de dirección a nombre de la dirección IP del cliente; de lo contrario,
la línea no coincidirá. Algunas bases de datos de nombres de host permiten asociar
una dirección IP con múltiples nombres de host, pero el sistema operativo solo devolverá
un nombre de host cuando se le pida resolver una dirección IP).
Una especificación de nombre de host que comienza con un punto
(.) coincide con un sufijo del nombre de host real.
De este modo, .example.com coincidiría con
foo.example.com (pero no solo con
example.com).
Cuando se especifican nombres de host en pg_hba.conf, debes
asegurarte de que la resolución de nombres sea razonablemente rápida. Puede ser ventajoso
configurar un caché local de resolución de nombres como
nscd. Además, es posible que desees habilitar el parámetro de configuración
log_hostname para ver el nombre de host del cliente en lugar de la dirección
IP en el registro.
Estos campos no se aplican a los registros local.
A veces los usuarios se preguntan por qué los nombres de host se manejan
de esta manera aparentemente complicada, con dos resoluciones de nombres
que incluyen una búsqueda inversa de la dirección IP del cliente. Esto
complica el uso de la característica en caso de que la entrada DNS inversa
del cliente no esté configurada o devuelva algún nombre de host no deseado.
Se hace principalmente por eficiencia: de esta manera, un intento de conexión
requiere como máximo dos búsquedas de resolución, una inversa y otra directa.
Si hay un problema de resolución con alguna dirección, se convierte únicamente en
el problema de ese cliente. Una hipotética implementación alternativa que solo
realizara búsquedas directas tendría que resolver cada nombre de host mencionado en
pg_hba.conf durante cada intento de conexión.
Eso podría ser bastante lento si se listan muchos nombres.
Y si hay un problema del resolver con uno de los nombres de host,
se convierte en el problema de todos.
Además, es necesaria una búsqueda inversa para implementar la característica de coincidencia de sufijos, ya que es necesario conocer el nombre de host real del cliente para compararlo con el patrón.
Ten en cuenta que este comportamiento es consistente con otras implementaciones populares de control de acceso basado en nombres de host, como el Servidor HTTP Apache y TCP Wrappers.
IP-addressIP-mask
Estos dos campos pueden utilizarse como alternativa a la notación
IP-address/mask-length.
En lugar de especificar la longitud de la máscara, la máscara real se especifica en una
columna independiente. Por ejemplo, 255.0.0.0 representa una longitud de máscara
CIDR IPv4 de 8, y 255.255.255.255 representa una longitud de máscara
CIDR de 32.
Estos campos no se aplican a los registros local.
auth-method
Especifica el método de autenticación que se utilizará cuando una conexión coincida con
este registro. Las posibles opciones se resumen aquí; los detalles
se encuentran en la sección Section 20.3. Todas las opciones
se escriben en minúsculas y se distinguen entre mayúsculas y minúsculas, por lo que incluso acrónimos como
ldap deben especificarse en minúsculas.
trustPermitir la conexión incondicionalmente. Este método permite a cualquiera que pueda conectarse al servidor de la base de datos PostgreSQL iniciar sesión como cualquier usuario de PostgreSQL que desee, sin necesidad de contraseña ni de ningún otro tipo de autenticación. Consulta Section 20.4 para más detalles.
reject
Rechazar la conexión incondicionalmente. Esto es útil para
“filtrar” ciertos hosts de un grupo; por ejemplo, una
línea reject podría bloquear la conexión de un host específico,
mientras que una línea posterior permitiría conectarse a los hosts restantes de una
red específica.
scram-sha-256Realizar la autenticación SCRAM-SHA-256 para verificar la contraseña del usuario. Consulta Section 20.5 para más detalles.
md5Realizar la autenticación SCRAM-SHA-256 o MD5 para verificar la contraseña del usuario. Consulta Section 20.5 para más detalles.
El soporte para contraseñas cifradas con MD5 está obsoleto y se eliminará en una futura versión de PostgreSQL. Consulta Section 20.5 para obtener detalles sobre cómo migrar a otro tipo de contraseña.
passwordRequerir que el cliente proporcione una contraseña no cifrada para la autenticación. Dado que la contraseña se envía en texto claro a través de la red, no debería utilizarse en redes no confiables. Consulta la sección Section 20.5 para más detalles.
gssUtilizar GSSAPI para autenticar al usuario. Esto solo está disponible para conexiones TCP/IP. Consulta Section 20.6 para más detalles. Puede utilizarse junto con el cifrado GSSAPI.
sspiUtilizar SSPI para autenticar al usuario. Esto solo está disponible en Windows. Consulta Section 20.7 para más detalles.
identObtener el nombre de usuario del sistema operativo del cliente poniéndose en contacto con el servidor ident del cliente y comprobar si coincide con el nombre de usuario de la base de datos solicitado. La autenticación ident solo puede utilizarse en conexiones TCP/IP. Cuando se especifica para conexiones locales, se utilizará en su lugar la autenticación peer. Consulta la sección Section 20.8 para más detalles.
peerObtener el nombre de usuario del sistema operativo del cliente a partir del sistema operativo y comprobar si coincide con el nombre de usuario de la base de datos solicitado. Esto solo está disponible para conexiones locales. Consulta la sección Section 20.9 para más detalles.
ldapAutenticar utilizando un servidor LDAP. Consulta Section 20.10 para más detalles.
radiusAutenticar utilizando un servidor RADIUS. Consulta Section 20.11 para más detalles.
certAutenticar utilizando certificados de cliente SSL. Consulta Section 20.12 para más detalles.
pamAutenticar utilizando el servicio Pluggable Authentication Modules (PAM) proporcionado por el sistema operativo. Consulta Section 20.13 para más detalles.
bsdAutenticar utilizando el servicio BSD Authentication proporcionado por el sistema operativo. Consulta Section 20.14 para más detalles.
oauthAutorizar y opcionalmente autenticar utilizando un proveedor de identidad OAuth 2.0 de terceros. Consulta la sección Section 20.15 para más detalles.
auth-options
Después del campo auth-method, puede haber campo(s) de
la forma name=value que
especifican opciones para el método de autenticación. Los detalles sobre qué
opciones están disponibles para qué métodos de autenticación aparecen a continuación.
Además de las opciones específicas del método indicadas a continuación, existe una
opción de autenticación independiente del método llamada clientcert, que
puede especificarse en cualquier registro hostssl.
Esta opción se puede configurar como verify-ca o
verify-full. Ambas opciones requieren que el cliente
presente un certificado SSL válido (de confianza), mientras que
verify-full exige además que el
cn (Common Name) del certificado coincida con
el nombre de usuario o con una asignación aplicable.
Este comportamiento es similar al del método de autenticación cert
(consulta Section 20.12) pero permite emparejar
la verificación de los certificados de cliente con cualquier método de autenticación
que admita entradas hostssl.
En cualquier registro que utilice la autenticación por certificado de cliente (es decir, uno
que utilice el método de autenticación cert o uno
que utilice la opción clientcert), puedes especificar
qué parte de las credenciales del certificado de cliente se debe comparar utilizando
la opción clientname. Esta opción puede tener uno
de dos valores. Si especificas clientname=CN, que
es el valor por defecto, el nombre de usuario se compara con el
Common Name (CN) del certificado. Si por el contrario especificas
clientname=DN, el nombre de usuario se compara con todo el
Distinguished Name (DN) del certificado.
Probablemente sea mejor utilizar esta opción junto con un mapa de nombres de usuario.
La comparación se realiza con el DN en formato
RFC 2253.
Para ver el DN de un certificado de cliente en este formato, ejecuta:
openssl x509 -in myclient.crt -noout -subject -nameopt RFC2253 | sed "s/^subject=//"
Se debe tener cuidado al utilizar esta opción, especialmente cuando se utilizan
expresiones regulares para comparar con el DN.
includeEsta línea será reemplazada por el contenido del archivo indicado.
include_if_existsEsta línea será reemplazada por el contenido del archivo indicado si este existe. De lo contrario, se registra un mensaje para indicar que el archivo se ha omitido.
include_dir
Esta línea será reemplazada por el contenido de todos los archivos que se encuentren en
el directorio, siempre que no empiecen por un punto . y terminen
por .conf, procesados por orden de nombre de archivo (según
las reglas de configuración regional de C, es decir, los números antes que las letras, y las letras mayúsculas
antes que las minúsculas).
Los archivos incluidos mediante construcciones @ se leen como listas de nombres,
que pueden estar separados por espacios en blanco o por comas. Los comentarios se
introducen mediante #, al igual que en
pg_hba.conf, y se permiten construcciones @ anidadas.
A menos que el nombre de archivo que sigue a @ sea una ruta absoluta,
se toma como relativa al directorio que contiene el archivo de referencia.
Dado que los registros de pg_hba.conf se examinan
secuencialmente para cada intento de conexión, el orden de los registros es
significativo. Normalmente, los primeros registros tendrán parámetros de coincidencia
de conexión estrictos y métodos de autenticación más débiles, mientras que los registros
posteriores tendrán parámetros de coincidencia más laxos y métodos de autenticación
más fuertes. Por ejemplo, se podría desear utilizar la autenticación trust
para conexiones TCP/IP locales pero requerir una contraseña para las conexiones
TCP/IP remotas. En este caso, un registro que especifique la autenticación
trust para conexiones desde 127.0.0.1 aparecería
antes que un registro que especifique la autenticación por contraseña para un rango
más amplio de direcciones IP de cliente permitidas.
Para conectarse a una base de datos concreta, un usuario no solo debe superar las
comprobaciones de pg_hba.conf, sino que debe tener el
privilegio CONNECT para la base de datos. Si deseas
restringir qué usuarios pueden conectarse a qué bases de datos, suele ser
más fácil controlarlo concediendo/revocando el privilegio CONNECT
que poner las reglas en las entradas de pg_hba.conf.
Algunos ejemplos de entradas de pg_hba.conf se muestran en la sección
Example 20.1. Consulta la siguiente sección para obtener detalles sobre los
diferentes métodos de autenticación.
Example 20.1. Ejemplos de entradas de pg_hba.conf
# Permitir que cualquier usuario del sistema local se conecte a cualquier base de datos con
# cualquier nombre de usuario utilizando sockets de dominio Unix (el valor por defecto para conexiones
# locales).
#
# TYPE DATABASE USER ADDRESS METHOD
local all all trust
# Lo mismo utilizando conexiones TCP/IP de bucle de retorno local.
#
# TYPE DATABASE USER ADDRESS METHOD
host all all 127.0.0.1/32 trust
# Lo mismo que la línea anterior, pero utilizando una columna de máscara de red independiente
#
# TYPE DATABASE USER IP-ADDRESS IP-MASK METHOD
host all all 127.0.0.1 255.255.255.255 trust
# Lo mismo a través de IPv6.
#
# TYPE DATABASE USER ADDRESS METHOD
host all all ::1/128 trust
# Lo mismo utilizando un nombre de host (normalmente cubriría tanto IPv4 como IPv6).
#
# TYPE DATABASE USER ADDRESS METHOD
host all all localhost trust
# Lo mismo utilizando una expresión regular para DATABASE, que permite la conexión
# a cualquier base de datos con un nombre que comience por "db" y termine con un
# número que utilice de dos a cuatro dígitos (como "db1234" o "db12").
#
# TYPE DATABASE USER ADDRESS METHOD
host "/^db\d{2,4}$" all localhost trust
# Permitir a cualquier usuario de cualquier host con dirección IP 192.168.93.x conectarse
# a la base de datos "postgres" con el mismo nombre de usuario que ident reporte para
# la conexión (normalmente el nombre de usuario del sistema operativo).
#
# TYPE DATABASE USER ADDRESS METHOD
host postgres all 192.168.93.0/24 ident
# Permitir a cualquier usuario del host 192.168.12.10 conectarse a la base de datos
# "postgres" si la contraseña del usuario se proporciona correctamente.
#
# TYPE DATABASE USER ADDRESS METHOD
host postgres all 192.168.12.10/32 scram-sha-256
# Permitir a cualquier usuario de los hosts del dominio example.com conectarse a
# cualquier base de datos si la contraseña del usuario se proporciona correctamente.
#
# Requerir autenticación SCRAM para la mayoría de los usuarios, pero hacer una excepción
# para el usuario 'mike', que utiliza un cliente antiguo que no admite la autenticación
# SCRAM.
#
# TYPE DATABASE USER ADDRESS METHOD
host all mike .example.com md5
host all all .example.com scram-sha-256
# A falta de líneas "host" precedentes, estas tres líneas rechazarán todas las conexiones
# de 192.168.54.1 (ya que esa entrada coincidirá primero), pero permitirán conexiones
# cifradas con GSSAPI desde cualquier otro lugar de Internet. La máscara cero hace que no se
# consideren bits de la dirección IP del host, por lo que coincide con cualquier host. Las conexiones
# GSSAPI no cifradas (que pasan a la tercera línea ya que "hostgssenc" solo coincide con conexiones
# GSSAPI cifradas) están permitidas, pero solo desde 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
# Permitir a los usuarios de hosts 192.168.x.x conectarse a cualquier base de datos si
# superan la comprobación ident. Si, por ejemplo, ident dice que el usuario es
# "bryanh" y este solicita conectarse como el usuario de PostgreSQL "guest1", la
# conexión se permite si hay una entrada en pg_ident.conf para el mapa
# "omicron" que dice que "bryanh" tiene permitido conectarse como "guest1".
#
# TYPE DATABASE USER ADDRESS METHOD
host all all 192.168.0.0/16 ident map=omicron
# Si estas son las únicas cuatro líneas para conexiones locales, permitirán a los usuarios
# locales conectarse únicamente a sus propias bases de datos (bases de datos con el mismo nombre
# que su usuario de base de datos) excepto para los usuarios cuyos nombres terminen por "helpdesk",
# administradores y miembros del rol "support", que pueden conectarse a todas las bases de datos.
# El archivo $PGDATA/admins contiene una lista de nombres de administradores. Se requieren
# contraseñas en todos los casos.
#
# TYPE DATABASE USER ADDRESS METHOD
local sameuser all scram-sha-256
local all /^.*helpdesk$ scram-sha-256
local all @admins scram-sha-256
local all +support scram-sha-256
# Las dos últimas líneas anteriores se pueden combinar en una sola línea:
local all @admins,+support scram-sha-256
# La columna de la base de datos también puede utilizar listas y nombres de archivos:
local db1,db2,@demodbs all scram-sha-256