Conceptos básicos de roles

8 ejemplos para roles de PostgreSQL: 6 básicos y 2 intermedios. En PostgreSQL, los roles son el principal universal: los usuarios de inicio de sesión y los paquetes de permisos similares a grupos son del mismo tipo de objeto.

Prerrequisitos

-- Conéctate como un rol que pueda CREAR ROLE (normalmente superusuario o CREATEROLE)
\du

• Prefiere un rol por servicio de aplicación, no contraseñas compartidas de humanos.
• Usa roles de grupo (NOLOGIN) para modelar niveles de permisos.

Ejemplos básicos

1. Crear rol de inicio de sesión

CREATE ROLE app_api LOGIN PASSWORD 'from-vault-rotate-quarterly';
ALTER ROLE app_api CONNECTION LIMIT 50;

• LOGIN permite la autenticación por contraseña o certificado.
• CONNECTION LIMIT limita la desconfiguración descontrolada del pool por rol.
• Almacena las contraseñas en un gestor de secretos; rota al dar de baja.

2. Crear rol de grupo (NOLOGIN)

CREATE ROLE app_readers NOLOGIN;
CREATE ROLE app_writers NOLOGIN;
 
GRANT app_readers TO app_api;
GRANT app_writers TO app_migrator;

• Los roles de grupo contienen privilegios; los roles de inicio de sesión heredan a través de GRANT group TO user.
• SET ROLE permite a un rol de inicio de sesión asumir un grupo temporalmente.
• Modelo: app_api hereda app_readers solo en perfiles de implementación de solo lectura si es necesario.

Relacionado: Patrones GRANT/REVOKE - privilegios de objetos

3. Herencia de roles

CREATE ROLE tenant_admin NOLOGIN;
CREATE ROLE support_agent LOGIN INHERIT PASSWORD 'vault';
 
GRANT tenant_admin TO support_agent;
 
-- support_agent tiene automáticamente los privilegios de tenant_admin cuando INHERIT es true (predeterminado)

• INHERIT (predeterminado): los privilegios de los roles concedidos se aplican automáticamente.
• NOINHERIT: debe usar SET ROLE tenant_admin para activar los privilegios.
• Usa NOINHERIT para roles de "break-glass" auditados en la activación.

4. Listar roles y membresía

\du+
SELECT r.rolname, m.rolname AS member_of
FROM pg_roles r
LEFT JOIN pg_auth_members am ON am.member = r.oid
LEFT JOIN pg_roles m ON m.oid = am.roleid
WHERE r.rolname = 'app_api';

• \du+ muestra atributos: Superusuario, Crear rol, Crear BD, Replicación.
• El gráfico de membresía se vuelve complejo: diagramarlo en la documentación de incorporación.
• pg_roles incluye roles de los que no puedes iniciar sesión.

5. Alterar atributos de rol

ALTER ROLE app_api SET statement_timeout = '30s';
ALTER ROLE app_api SET search_path = app, public;
ALTER ROLE app_migrator CREATEDB;  -- raramente - prefiere concesiones explícitas de base de datos

• Los valores predeterminados de GUC por rol se aplican al iniciar sesión.
• search_path en roles de aplicación evita sorpresas de secuestro de esquemas.
• Evita CREATEDB/CREATEROLE amplios en roles de inicio de sesión de aplicaciones.

6. Eliminar rol de forma segura

-- Reasigna los objetos propiedad primero
REASSIGN OWNED BY old_app TO app_owner;
DROP OWNED BY old_app;
DROP ROLE old_app;

• No se puede eliminar un rol que posee objetos o tiene sesiones activas.
• DROP OWNED elimina privilegios; revisa antes de ejecutar en producción.
• Lista de verificación de baja: reasignar, eliminar membresías, revocar inicio de sesión.

Ejemplos intermedios

7. Jerarquía de roles para entornos

CREATE ROLE app_owner NOLOGIN;
CREATE ROLE app_staging LOGIN PASSWORD 'vault';
CREATE ROLE app_prod LOGIN PASSWORD 'vault';
 
GRANT app_owner TO app_staging, app_migrator;
-- app_prod hereda concesiones más específicas aplicadas por separado

• Mismo código de esquema, diferentes roles de inicio de sesión por entorno.
• CI usa app_migrator; el tiempo de ejecución usa app_api sin derechos DDL.
• Nunca copies el hash de contraseña de producción a staging.

Relacionado: Privilegios predeterminados - las migraciones crean objetos como propietario

8. SET ROLE para elevación auditada

CREATE ROLE ddl_runner NOLOGIN;
GRANT ddl_runner TO deploy_user WITH ADMIN OPTION FALSE;
 
-- Solo en la sesión de migración
SET ROLE ddl_runner;
CREATE TABLE audit.sample (id int);
RESET ROLE;

• SET ROLE se registra en los logs cuando log_line_prefix incluye el usuario y el usuario de la sesión.
• El rol de migración no debe ser el propietario del objeto en tiempo de ejecución si se puede evitar.
• Emparejar con NOINHERIT en deploy_user para una elevación estricta.

Versiones de la pila: Esta página se escribió para PostgreSQL 18.4 (estable 18, mantenimiento 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x y PostGIS 3.5+.