Autenticación, pg_hba.conf y TLS en PostgreSQL | Nicolás Garzón
Autenticar una conexión responde tres preguntas: desde dónde llega, qué identidad presenta y mediante qué método se valida. TLS protege el canal; no reemplaza roles ni permisos.
Texto
Copiar cliente → red/TLS → pg_hba.conf → método de autenticación → role → permisos/RLSpg_hba.conf decide qué combinaciones de database, role y origen pueden intentar autenticarse.
Texto
Copiar hostssl appdb app_runtime 10.0.0.0/8 scram-sha-256
Tipo de conexión.
Database.
Role.
Dirección.
Método.
Las reglas se evalúan en orden; la primera coincidencia decide.
Preferido para passwords modernos. Configura:
SQL
Copiar SET password_encryption = 'scram-sha-256' ; y rota passwords antiguos.
Autenticación mediante certificado cliente. Útil para identidades de máquina con PKI operada correctamente.
En conexiones locales, compara usuario del sistema operativo.
No exige autenticación. Solo es aceptable en entornos locales muy controlados; no en redes productivas.
Método legado. Planifica migración a SCRAM.
hostssl exige TLS. Verifica:
Certificado del servidor.
Cadena confiable.
Hostname.
Versiones/ciphers.
Renovación.
Texto
Copiar sslmode=verify-fulles la garantía fuerte: cifra y verifica identidad/hostname. require cifra, pero puede no validar adecuadamente al servidor.
No los guardes en repositorio.
Usa secret manager.
Rota.
Identidad distinta por servicio y entorno.
Evita cuentas compartidas.
Limita duración cuando el proveedor soporte tokens temporales.
El password nunca debe aparecer en logs ni URLs mostradas.
Cambios en pg_hba.conf suelen requerir reload:
SQL
Copiar SELECT pg_reload_conf( ) ; Errores de sintaxis pueden consultarse en views/versiones compatibles como pg_hba_file_rules. Prueba una sesión nueva antes de cerrar la administrativa.
Reglas con nombres pueden depender de resolución y reverse DNS. Para infraestructura crítica, entiende latencia y comportamiento; CIDRs suelen ser más previsibles.
Managed services pueden ocultar pg_hba.conf y ofrecer allowlists, IAM auth o proxies. El modelo sigue siendo:
Texto
Copiar control de red + identidad + cifrado + privilegiosNo asumas que “es privado” elimina TLS.
Mapeo con pg_ident.conf puede relacionar identidad externa y role. Necesita lifecycle de certificados, revocación y protección de keys.
no pg_hba.conf entry: ninguna regla coincide o se exige SSL/no SSL distinto.
password authentication failed: role/password/método.
Certificate verify failed: CA, hostname, expiración.
Timeout: red, firewall, listener o pool.
Diagnostica por capas; no cambies a trust para “probar”.
listen_addresses solo donde corresponda.
Firewall/security groups.
TLS verify-full.
SCRAM.
Roles mínimos.
connection_limit por role cuando aporte.
Logs de conexiones con cuidado de volumen.
Actualizaciones y certificados vigentes.
Una regla amplia antes de otra específica la vuelve inalcanzable.
Password SCRAM con cliente antiguo incompatible.
Certificado renovado sin reload/restart según configuración.
Pool conserva sesiones después de revocar acceso; termina conexiones cuando sea necesario.
Replicas necesitan reglas propias.
0.0.0.0/0 con password débil.
sslmode=require tratado como verificación completa.
Roles compartidos.
Trust en producción.
Editar HBA sin sesión de respaldo.
Confundir autenticación con autorización.
Origen permitido mínimo.
Método fuerte.
TLS verify-full.
Role específico.
Secret rotation.
Test de denegación.
Logs y alertas.
Runbook de certificado.
Acceso de emergencia auditado.
¿Por qué importa el orden de HBA?
¿Qué añade verify-full?
¿Por qué TLS no basta?
¿Qué diferencia hay entre SCRAM y permisos?
Ver respuestas
La primera regla coincidente decide.
Verifica certificado y hostname además de cifrar.
Un canal seguro no limita qué puede hacer el role autenticado.
SCRAM valida identidad; permisos autorizan operaciones.
SQL injection y consultas parametrizadas separa datos no confiables de la estructura ejecutable.