sqlpostgresqlcreate-rolepermissions

CREATE ROLE en PostgreSQL: usuarios, grupos y herencia de permisos

Como una sola sentencia CREATE ROLE modela personas y grupos: LOGIN frente a NOLOGIN, pertenencia a roles, herencia y atributos como CREATEDB.

3 min de lecturaReferencesql · postgresql · create-role · permissions · security · users

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".

-- 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 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.

-- 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 con SET 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, 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.

-- 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 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.

Practica con ejercicios reales

Resuelve ejercicios en el entrenador de SQL con corrección instantánea y pistas.

Abrir el entrenador