postgresql create user: guía práctica para crear, securizar y delegar permisos

La instrucción postgresql create user resume una tarea habitual en la administración de bases de datos: crear cuentas con los permisos adecuados y controlar su acceso. Este texto explica cómo crear usuarios y roles, cuándo usar cada opción, ejemplos concretos y prácticas para minimizar riesgos en entornos de producción.

Entorno y conceptos clave antes de crear usuarios

Antes de ejecutar comandos conviene entender la diferencia entre USER y ROLE en PostgreSQL: desde PostgreSQL 8.1 ambos conceptos confluyen en roles, pero la sintaxis CREATE USER es un alias común para CREATE ROLE … LOGIN. Un rol puede agrupar privilegios y otros roles; la estrategia recomendada es crear roles funcionales (por ejemplo, app_readonly) y asignar usuarios a esos roles.

Otros conceptos relevantes:

• LOGIN: permiso que permite autenticar como ese rol.
• SUPERUSER: privilegio potente, debe reservarse para administración.
• CREATEDB y CREATEROLE: banderas para delegar creación de bases o roles.
• VALID UNTIL: permite establecer expiración de contraseña.
• pg_hba.conf: controla métodos de autenticación y orígenes; crear un usuario no garantiza acceso si la regla en pg_hba.conf no lo permite.

Comandos y ejemplos prácticos

Crear un usuario básico desde psql (con sesión del superusuario o un rol con createrole):

CREATE USER web_user WITH PASSWORD ‘S3cur3P@ssw0rd’;

Equivalente usando CREATE ROLE:

CREATE ROLE web_user WITH LOGIN PASSWORD ‘S3cur3P@ssw0rd’;

Crear un usuario con restricciones y propiedades:

CREATE ROLE report_ro WITH LOGIN PASSWORD ‘reporT2026’ NOSUPERUSER NOCREATEDB NOCREATEROLE CONNECTION LIMIT 10 VALID UNTIL ‘2026-12-31’;

Asignar un rol funcional y otorgar permisos:

GRANT SELECT ON ALL TABLES IN SCHEMA public TO report_ro;

Habilitar herencia de permisos (por defecto los roles heredan):

ALTER ROLE app_user IN ROLE app_readonly;

Eliminar o deshabilitar un usuario:

DROP ROLE old_user; o para bloquear temporalmente ALTER ROLE temp_user NOLOGIN;

Conectar desde la línea de comandos para probar

Usando psql:

• psql -h db.example.com -U web_user -d mydb (se solicitará la contraseña o se usará el método configurado por pg_hba.conf).

Configuración de autenticación y seguridad

Crear usuarios es solo la mitad del trabajo; la otra mitad es asegurar cómo se autentican y desde dónde pueden hacerlo.

Recomendaciones clave:

• Preferir scram-sha-256 si el cliente y el servidor lo soportan. Establecer password_encryption = scram-sha-256 en postgresql.conf antes de crear contraseñas nuevas.
• No usar contraseñas en texto plano en scripts. Para automatización, usar variables de entorno seguras o sistemas de vault.
• Limitar conexiones con CONNECTION LIMIT y mediante reglas de pg_hba.conf por red o usuario.
• Evitar asignar SUPERUSER salvo cuando sea imprescindible para tareas administrativas.
• Usar roles intermedios para permisos en lugar de conceder privilegios de forma individual a cada usuario.

Ejemplo de una entrada típica en pg_hba.conf para permitir solo conexiones SSL desde una subred de aplicaciones:

hostssl mydb app_subnet 192.168.10.0/24 scram-sha-256

Casos de uso: mini-casos y decisiones prácticas

1) Usuario para una aplicación web

• Crear rol con LOGIN, sin SUPERUSER ni CREATEDB, conexión limitada y contraseña fuerte. Delegar permisos mediante un rol funcional que tenga acceso a las tablas necesarias.

2) Usuario de solo lectura para BI

• Crear rol report_ro y usar GRANT SELECT. Para nuevos esquemas, usar ALTER DEFAULT PRIVILEGES para que las futuras tablas sean accesibles automáticamente:

ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO report_ro;

3) Usuario de réplica

• Crear rol con REPLICATION y contraseña, y configurar pg_hba.conf para permitir la conexión desde el servidor réplica. Ejemplo:

CREATE ROLE repl_user WITH REPLICATION LOGIN PASSWORD ‘replicaS3c’;

Errores comunes y cómo evitarlos

Evitar estos fallos frecuentes:

• No revisar pg_hba.conf: un usuario puede existir pero no poder conectarse por reglas de autenticación.
• Dar SUPERUSER innecesario: causa riesgo de fuga de datos o cambios no controlados.
• Conceder permisos directos a usuarios en lugar de usar roles. Esto complica auditoría y cambios futuros.
• No usar límites de conexión en usuarios de servicios generados por contenedores o CI, lo que puede provocar agotamiento de conexiones.
• Almacenamiento inseguro de contraseñas en repositorios o scripts no cifrados.

Si se detecta un acceso no autorizado, revocar conexiones y cambiar las credenciales afectadas inmediatamente. Por ejemplo:

ALTER ROLE compromised_user PASSWORD ‘newStrongPass’;

Y si es necesario bloquear acceso temporalmente:

ALTER ROLE compromised_user NOLOGIN;

Buenas prácticas operacionales y mantenimiento

Implementar políticas que reduzcan el riesgo operativo:

1. Gestión centralizada de identidades: integrar PostgreSQL con LDAP/AD o con sistemas de identidad cuando sea posible.
2. Rotación periódica de contraseñas críticas y uso de VALID UNTIL para forzar caducidad.
3. Auditoría: habilitar logging de conexiones y sentencias sensibles (con cuidado por el volumen de datos).
4. Documentar roles y su finalidad: esquema, permisos y dependencias.
5. Pruebas en entorno staging antes de aplicar cambios de roles en producción.

Ejemplo de política sencilla para un proyecto mediano:

• Roles funcionales: app_writer, app_reader, report_ro.
• Usuarios de despliegue: deploy_user con conexión limitada y sin superuser.
• Acceso administrativo: dos superusers con MFA sobre los servidores de administración.

Automatización segura

Para despliegues automatizados usar herramientas de infraestructura como código que soporten integración con secretos (Vault, AWS Secrets Manager). Evitar codificar la contraseña en plantillas y preferir referencias a secretos en tiempo de ejecución.

Resumen práctico y pasos a seguir

Para crear y poner en producción un usuario de aplicación con seguridad mínima recomendada:

1. Definir rol funcional y permisos mínimos necesarios.
2. Configurar postgresql.conf con password_encryption apropiado.
3. Crear el rol con LOGIN y CONNECTION LIMIT: CREATE ROLE app_user WITH LOGIN PASSWORD ‘…’ NOSUPERUSER.
4. Conceder permisos mediante roles: GRANT app_writer TO app_user;
5. Ajustar pg_hba.conf para permitir conexión solo desde las IPs necesarias usando scram-sha-256 o cert.
6. Probar la conexión desde entorno controlado y revisar logs.
7. Documentar y rotar la credencial según la política.

Crear usuarios en PostgreSQL requiere más que ejecutar postgresql create user: implica diseño de permisos, control de autenticación y operaciones de mantenimiento. Implementando roles intermedios, autenticación segura y límites de conexión, se reduce el riesgo y se facilita la administración. Al final, las decisiones deben alinearse con la criticidad del dato y el modelo de despliegue; en muchos casos es preferible invertir tiempo en diseñar una jerarquía de roles antes que otorgar privilegios directamente a cada cuenta.

Para cualquier implementación, verificar siempre la compatibilidad de clientes con scram-sha-256, auditar los accesos y evitar la proliferación de superusuarios. Recordar que la instrucción postgresql create user es el inicio de un proceso operativo y de seguridad, no un fin en sí mismo.