PostgreSQL no tiene entidades separadas de "usuario" y "grupo": existe un unico rol universal. La sentencia CREATE ROLE crea tanto a la persona que inicia sesion como al grupo que guarda los privilegios para otros. La unica diferencia esta en los atributos que le adjuntas.
Un rol de login y un rol de grupo
Un rol con el atributo LOGIN puede conectarse al servidor, que es lo que solemos llamar "usuario". Un rol sin LOGIN no puede conectarse y suele servir de contenedor de privilegios, es decir, un "grupo".
CREATE ROLE analyst LOGIN PASSWORD 'secret';
CREATE ROLE app_readonly NOLOGIN;
CREATE USER es solo un sinonimo de CREATE ROLE ... LOGIN. Asi que CREATE USER analyst y CREATE ROLE analyst LOGIN hacen exactamente lo mismo; no hay ningun "tipo de usuario" aparte por debajo.
Demos al grupo acceso de lectura a nuestro esquema:
GRANT SELECT ON users, orders, employees TO app_readonly;
Pertenencia a roles y herencia
Un rol pasa a ser miembro de un grupo con GRANT role TO member. A partir de ahi el atributo INHERIT lo decide todo: si esta activo (el valor por defecto), el miembro usa automaticamente los privilegios del grupo.
GRANT app_readonly TO analyst;
SELECT country, count(*) FROM users GROUP BY country;
Si el rol se crea con NOINHERIT, los privilegios del grupo no se aplican de forma automatica; hay que "ponerselos" de forma explicita con SET ROLE:
CREATE ROLE deploy_bot LOGIN NOINHERIT PASSWORD 'secret';
GRANT app_readonly TO deploy_bot;
SET ROLE app_readonly;
SELECT amount FROM orders WHERE status = 'paid';
RESET ROLE;
Trampa: atributos como SUPERUSER, CREATEDB y LOGIN NUNCA se heredan por pertenencia. Un miembro de un grupo superusuario no se vuelve superusuario. Solo se heredan los privilegios ordinarios (SELECT, INSERT, etc.), nunca los atributos del rol.
Atributos del rol
Los atributos definen que puede hacer un rol a nivel de todo el cluster. Los mas habituales:
LOGIN / NOLOGIN controla si el rol puede conectarse al servidor.
SUPERUSER / NOSUPERUSER decide si el rol omite todas las comprobaciones de permisos. Repartelo con mucha mesura.
CREATEDB permite al rol crear bases de datos.
CREATEROLE permite al rol crear y modificar otros roles.
PASSWORD y VALID UNTIL fijan la contrasena y su fecha de caducidad.
CREATE ROLE etl_owner LOGIN
CREATEDB
PASSWORD 'secret'
VALID UNTIL '2026-12-31';
Puedes cambiar los atributos despues con ALTER ROLE, que tambien es la forma comoda de revocar poderes peligrosos:
ALTER ROLE analyst CONNECTION LIMIT 5;
ALTER ROLE etl_owner NOCREATEDB;
El modelo de "usuarios y grupos"
Un patron practico: crea unos cuantos roles de grupo para conjuntos de privilegios, crea a las personas como roles de login y conectalos mediante pertenencia. Cambiar el acceso despues es un solo GRANT / REVOKE, no editar permisos tabla por tabla para cada individuo.
CREATE ROLE readers NOLOGIN;
CREATE ROLE writers NOLOGIN;
GRANT SELECT ON users, orders TO readers;
GRANT SELECT, INSERT, UPDATE ON orders TO writers;
GRANT readers TO writers;
CREATE ROLE maria LOGIN PASSWORD 'secret';
CREATE ROLE pavel LOGIN PASSWORD 'secret';
GRANT readers TO maria;
GRANT writers TO pavel;
Cuando Pavel deja el equipo de escritura, ejecutas REVOKE writers FROM pavel y el acceso se retira de todas las tablas de golpe.
Diferencias entre motores:
- MySQL no tenia roles antes de la 8.0; ahora tiene
CREATE ROLE y CREATE USER, pero son comandos distintos, y aun hay que activar el rol con SET ROLE o SET DEFAULT ROLE.
- ClickHouse soporta
CREATE ROLE, CREATE USER y GRANT, pero el modelo de privilegios es mas plano, sin herencia profunda a traves de cadenas de roles.
La regla base: adjunta los privilegios a los grupos, haz a las personas miembros de los grupos y reserva SUPERUSER solo para los administradores de la plataforma.
PostgreSQL no tiene entidades separadas de "usuario" y "grupo": existe un unico rol universal. La sentencia
CREATE ROLEcrea tanto a la persona que inicia sesion como al grupo que guarda los privilegios para otros. La unica diferencia esta en los atributos que le adjuntas.Un rol de login y un rol de grupo
Un rol con el atributo
LOGINpuede conectarse al servidor, que es lo que solemos llamar "usuario". Un rol sinLOGINno puede conectarse y suele servir de contenedor de privilegios, es decir, un "grupo".-- a login role: an actual person or service CREATE ROLE analyst LOGIN PASSWORD 'secret'; -- a group role: no login, just holds privileges CREATE ROLE app_readonly NOLOGIN;CREATE USERes solo un sinonimo deCREATE ROLE ... LOGIN. Asi queCREATE USER analystyCREATE ROLE analyst LOGINhacen exactamente lo mismo; no hay ningun "tipo de usuario" aparte por debajo.Demos al grupo acceso de lectura a nuestro esquema:
GRANT SELECT ON users, orders, employees TO app_readonly;Pertenencia a roles y herencia
Un rol pasa a ser miembro de un grupo con
GRANT role TO member. A partir de ahi el atributoINHERITlo decide todo: si esta activo (el valor por defecto), el miembro usa automaticamente los privilegios del grupo.-- analyst now inherits everything app_readonly can do GRANT app_readonly TO analyst; -- as analyst, this just works thanks to inheritance: SELECT country, count(*) FROM users GROUP BY country;Si el rol se crea con
NOINHERIT, los privilegios del grupo no se aplican de forma automatica; hay que "ponerselos" de forma explicita conSET ROLE:CREATE ROLE deploy_bot LOGIN NOINHERIT PASSWORD 'secret'; GRANT app_readonly TO deploy_bot; -- without SET ROLE the SELECT below is denied SET ROLE app_readonly; SELECT amount FROM orders WHERE status = 'paid'; RESET ROLE;Trampa: atributos como
SUPERUSER,CREATEDByLOGINNUNCA se heredan por pertenencia. Un miembro de un grupo superusuario no se vuelve superusuario. Solo se heredan los privilegios ordinarios (SELECT,INSERT, etc.), nunca los atributos del rol.Atributos del rol
Los atributos definen que puede hacer un rol a nivel de todo el cluster. Los mas habituales:
LOGIN/NOLOGINcontrola si el rol puede conectarse al servidor.SUPERUSER/NOSUPERUSERdecide si el rol omite todas las comprobaciones de permisos. Repartelo con mucha mesura.CREATEDBpermite al rol crear bases de datos.CREATEROLEpermite al rol crear y modificar otros roles.PASSWORDyVALID UNTILfijan la contrasena y su fecha de caducidad.CREATE ROLE etl_owner LOGIN CREATEDB PASSWORD 'secret' VALID UNTIL '2026-12-31';Puedes cambiar los atributos despues con
ALTER ROLE, que tambien es la forma comoda de revocar poderes peligrosos:ALTER ROLE analyst CONNECTION LIMIT 5; ALTER ROLE etl_owner NOCREATEDB;El modelo de "usuarios y grupos"
Un patron practico: crea unos cuantos roles de grupo para conjuntos de privilegios, crea a las personas como roles de login y conectalos mediante pertenencia. Cambiar el acceso despues es un solo
GRANT/REVOKE, no editar permisos tabla por tabla para cada individuo.-- groups by responsibility CREATE ROLE readers NOLOGIN; CREATE ROLE writers NOLOGIN; GRANT SELECT ON users, orders TO readers; GRANT SELECT, INSERT, UPDATE ON orders TO writers; -- writers should also be able to read GRANT readers TO writers; -- people CREATE ROLE maria LOGIN PASSWORD 'secret'; CREATE ROLE pavel LOGIN PASSWORD 'secret'; GRANT readers TO maria; GRANT writers TO pavel;Cuando Pavel deja el equipo de escritura, ejecutas
REVOKE writers FROM pavely el acceso se retira de todas las tablas de golpe.Diferencias entre motores:
CREATE ROLEyCREATE USER, pero son comandos distintos, y aun hay que activar el rol conSET ROLEoSET DEFAULT ROLE.CREATE ROLE,CREATE USERyGRANT, pero el modelo de privilegios es mas plano, sin herencia profunda a traves de cadenas de roles.La regla base: adjunta los privilegios a los grupos, haz a las personas miembros de los grupos y reserva
SUPERUSERsolo para los administradores de la plataforma.