create user postgresql: guía práctica y segura para administrar usuarios y roles

create user postgresql es una operación habitual en la administración de bases de datos que requiere entender roles, privilegios y mecanismos de autenticación para no comprometer la seguridad ni la operatividad del servicio. Este texto ofrece instrucciones prácticas, ejemplos reales y criterios para decidir cómo y cuándo crear usuarios en PostgreSQL.

Primeros pasos: distinguir roles, usuarios y mejores prácticas de diseño

PostgreSQL usa el término role para representar cuentas con o sin capacidad de iniciar sesión. Históricamente existe el alias CREATE USER, que es equivalente a CREATE ROLE … LOGIN. Antes de crear una cuenta, conviene definir una política clara:

• Separar cuentas humanas de cuentas de servicio (aplicaciones).
• Crear roles agrupadores para permisos comunes y agregar usuarios a esos roles.
• Evitar conceder SUPERUSER salvo cuando sea absolutamente necesario.
• Usar autenticación fuerte (SCRAM-SHA-256) y rotación periódica de credenciales para servicios críticos.

Diseñar una jerarquía de roles facilita revocar permisos o rotar credenciales sin tocar todas las cuentas individuales: por ejemplo, un rol app_readonly con SELECT en esquemas públicos y un rol app_owner con permisos DDL limitados.

create user postgresql: comandos y opciones

En psql los comandos básicos son directos. Ejemplos útiles:

• Crear un usuario con contraseña: CREATE USER alice WITH PASSWORD ‘S3curePwd’;
• Crear un rol con permiso de inicio de sesión: CREATE ROLE svc_api LOGIN PASSWORD ‘OtroPwd’;
• Crear un rol con permisos de creación de bases: CREATE ROLE dba WITH LOGIN CREATEROLE CREATEDB;
• Establecer límite de conexiones: ALTER ROLE svc_api CONNECTION LIMIT 5;

Algunas opciones clave y su uso:

• LOGIN: permite la autenticación como cuenta; sin este atributo el role funciona solo como agrupador.
• CREATEDB, CREATEROLE, SUPERUSER: otorgar solo cuando sea imprescindible.
• CONNECTION LIMIT: controlar cuántas conexiones simultáneas puede abrir una cuenta para proteger recursos.
• VALID UNTIL: establecer una caducidad para la contraseña, útil en cuentas temporales.

Autenticación y almacenamiento de contraseñas

PostgreSQL soporta métodos en pg_hba.conf como md5 y scram-sha-256. SCRAM ofrece mejor protección frente a ataques offline y está recomendado para nuevas instalaciones. Para usar SCRAM, configurar password_encryption = scram-sha-256 en postgresql.conf y luego crear o alterar la contraseña:

ALTER ROLE alice WITH PASSWORD ‘NuevaPwd’;

Si la configuración de password_encryption cambia, las contraseñas existentes seguirán funcionando; sin embargo, renovar contraseñas permite que se almacenen con el nuevo esquema.

Asignación de permisos prácticos y ejemplos paso a paso

Crear un usuario no es suficiente: hay que conceder permisos sobre objetos. Pasos prácticos para una aplicación web típica:

1. Crear rol agrupador: CREATE ROLE app_group;
2. Dar permisos al grupo: GRANT CONNECT ON DATABASE app_db TO app_group; y GRANT USAGE ON SCHEMA public TO app_group;
3. Conceder permisos por objeto: GRANT SELECT, INSERT, UPDATE ON ALL TABLES IN SCHEMA public TO app_group;
4. Crear usuario de la aplicación y asignarlo al grupo: CREATE ROLE app_user LOGIN PASSWORD ‘AppPwd’; GRANT app_group TO app_user;

También conviene ejecutar ALTER DEFAULT PRIVILEGES para que las futuras tablas heredadas tengan permisos apropiados:

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

Esto evita tener que conceder permisos manualmente cada vez que la aplicación crea nuevas tablas.

Caso práctico: despliegue de una API con roles separados

Escenario: una API que necesita escribir en tablas de transacciones y otra cuenta para consultas analíticas.

• Crear rol de escritura: CREATE ROLE api_writer LOGIN PASSWORD ‘Writ3r’; y GRANT INSERT, UPDATE, DELETE ON TABLE transactions TO api_writer;
• Crear rol de solo lectura para análisis: CREATE ROLE analytics LOGIN PASSWORD ‘ReadOnly’; y GRANT SELECT ON ALL TABLES IN SCHEMA public TO analytics;
• Evitar compartir credenciales entre entornos. En lugar de usar una cuenta con permisos elevados, crear cuentas por entorno (dev/prod) y controlar accesos mediante pg_hba.conf y roles grupales.

Mini-caso: si la API necesita cargar datos masivos, usar un rol con permisos temporales y VALID UNTIL para caducar la contraseña tras la carga automática, y documentar el proceso de rotación.

Errores comunes y cómo resolverlos

Al crear usuarios surgen problemas repetidos que conviene conocer:

• Problema: Usuario no puede conectarse. Solución: revisar pg_hba.conf (método y rango de direcciones) y verificar que el role tiene LOGIN.
• Problema: Permisos insuficientes en nuevas tablas. Solución: aplicar ALTER DEFAULT PRIVILEGES para el creador de objetos o usar roles agrupadores.
• Problema: Uso inadvertido de SUPERUSER. Solución: auditar roles con privilegios elevados y migrar permisos a roles más específicos.
• Problema: Exceso de conexiones por cuentas de servicio. Solución: poner CONNECTION LIMIT y emplear pools de conexión como PgBouncer.

Recomendaciones operativas y de seguridad

Las decisiones al crear usuarios afectan tanto a seguridad como a operativa diaria. Recomendaciones prácticas:

• Imponer políticas de contraseñas y preferir SCRAM-SHA-256. Evitar md5 si es posible.
• Minimizar alcance de permisos y aplicar principio de menor privilegio.
• Usar roles agrupadores para cambios masivos y facilitar auditoría.
• Registrar cambios con herramientas de gestión de configuración (ansible, scripts versionados).
• Controlar accesos desde la red mediante reglas en pg_hba.conf y firewalls; no confiar únicamente en contraseñas.
• Automatizar rotación de credenciales para cuentas de servicio críticas; para apps, usar gestores de secretos (ej.: Vault) en lugar de incrustar credenciales en repositorios.

Para entornos con alta disponibilidad, coordinar la creación de usuarios con procesos de replicación: los roles deben existir en el nodo principal antes de que los clientes intenten autenticarse, y la propagación en replicas depende de la replicación del catálogo.

Cierre: decisiones prácticas antes de ejecutar create user postgresql

Antes de ejecutar create user postgresql, definir la finalidad de la cuenta (humana, servicio o temporal), su ámbito de permisos y el método de autenticación. Aplicar roles agrupadores, limitar conexiones y evitar privilegios de superusuario reduce riesgos operativos. Implementar políticas de rotación y monitorizar inicios de sesión completa el ciclo de seguridad. Con estos criterios, las operaciones de creación y gestión de usuarios serán previsibles, auditables y compatibles con las necesidades reales de la infraestructura.