Introduction
PostgreSQL utilise divers mécanismes pour implémenter l'authentification, l'autorisation et la propriété des objets dans les clusters de bases de données. Le concept de rôles est au cœur de ceux-ci.
Les rôles PostgreSQL sont une combinaison des idées des utilisateurs et des groupes en une seule entité flexible. Ils sont la personne que l'utilisateur adopte au sein du système de base de données, sont l'entité par laquelle le système d'authentification accepte ou refuse les connexions et font l'objet de règles de gestion des privilèges de toutes les portées.
Ce guide couvrira les rôles et comment les gérer dans un cluster de bases de données PostgreSQL. Plus précisément, ce guide couvrira la gestion des rôles en ce qui concerne les attributs de rôle. Pour une vue d'ensemble plus large de la façon dont les rôles s'intègrent dans le tableau d'ensemble, consultez l'introduction au guide d'authentification et d'autorisation. Pour savoir comment modifier les privilèges de rôle sur des objets de base de données spécifiques, consultez notre guide sur les attributions de rôle.
Que sont les rôles ?
Dans PostgreSQL, un rôle est un regroupement d'un ensemble spécifique de capacités, d'autorisations et d'entités "détenues". Au lieu d'avoir des concepts distincts d'"utilisateurs" et de "groupes", PostgreSQL utilise des rôles pour représenter ces deux idées. Un rôle peut correspondre à une personne individuelle dans le monde réel, ou il peut fonctionner comme un groupe avec certains accès dont d'autres rôles peuvent devenir membres.
Les rôles sont le point d'ancrage dans PostgreSQL qui détermine à qui s'appliquent les politiques d'authentification et d'autorisation. Toute politique qui ne s'applique pas universellement nécessite une notion d'identité pour définir qui restreindre et qui autoriser. Dans PostgreSQL, cette identité est représentée par des rôles.
Le système d'authentification de PostgreSQL comporte un certain nombre de composants différents, chacun étant lié à des rôles. Afin d'être utilisés pour la connexion initiale au cluster de base de données, les rôles doivent d'abord avoir le LOGIN
ensemble d'attributs. Les règles d'authentification elles-mêmes sont définies dans le fichier de configuration basé sur l'hôte appelé pg_hba.conf
. Chaque règle définit des méthodes d'authentification qui peuvent être limitées au rôle individuel. Pour les rôles configurés pour l'authentification par mot de passe, un attribut de mot de passe doit être défini afin que le système puisse valider le mot de passe utilisateur fourni.
En termes d'autorisation, les rôles sont définis au niveau du cluster de la base de données, ce qui dans PostgreSQL signifie qu'ils sont partagés entre les bases de données. Étant donné que les rôles couvrent plusieurs bases de données, le système d'autorisation contrôle le niveau d'accès de chaque rôle à chaque entité de base de données. Étant donné que les rôles peuvent représenter des groupes de personnes, il existe une grande flexibilité dans la configuration de l'accès.
Les rôles sont également essentiels au concept de propriété d'objet dans PostgreSQL. Chaque base de données et chaque table, par exemple, ont exactement un rôle configuré en tant que propriétaire. Autre que les superusers
, le rôle de propriétaire est le seul rôle qui peut modifier ou supprimer l'objet réel.
En résumé, les rôles sont au cœur de la plupart des opérations de base de données pratiques. Leur flexibilité leur permet d'agir à la fois comme identifiants d'utilisateurs et comme classes d'utilisateurs. Chaque action au sein du cluster de bases de données est vérifiée par rapport aux privilèges du rôle et le succès de chaque connexion au cluster de bases de données est déterminé par le rôle auquel on s'authentifie. Il est important de bien maîtriser la gestion des rôles en raison de son importance dans de nombreuses opérations de base.
Attributs de rôle
Les attributs de rôle sont des indicateurs sur le rôle lui-même qui déterminent certains des principaux privilèges dont il dispose au niveau du cluster de base de données. Ceux-ci peuvent être définis lors de la création initiale du rôle ou modifiés à tout moment par n'importe quel rôle avec les attributs appropriés (SUPERUSER
ou CREATEROLE
dans ce cas).
Les attributs pouvant être appliqués à un rôle incluent :
LOGIN
:autorise les utilisateurs à se connecter initialement au cluster de bases de données à l'aide de ce rôle. LeCREATE USER
ajoute automatiquement cet attribut, tandis queCREATE ROLE
la commande ne le fait pas.SUPERUSER
:permet au rôle de contourner toutes les vérifications d'autorisation, à l'exception du droit de se connecter. Seuls les autresSUPERUSER
les rôles peuvent créer des rôles avec cet attribut.CREATEDB
:permet au rôle de créer de nouvelles bases de données.CREATEROLE
:autorise le rôle à créer, modifier et supprimer d'autres rôles. Cet attribut permet également au rôle d'affecter ou de modifier l'appartenance au rôle. Une exception est qu'un rôle avec leCREATEROLE
l'attribut ne peut pas modifierSUPERUSER
rôles sans avoir également leSUPERUSER
attribut.REPLICATION
:permet au rôle de lancer la réplication en continu. Les rôles avec cet attribut doivent également avoir leLOGIN
attribut.PASSWORD
:Attribue un mot de passe au rôle qui sera utilisé avecpassword
oumd5
mécanismes d'authentification. Cet attribut prend un mot de passe entre guillemets comme argument directement après le mot-clé de l'attribut.INHERIT
:détermine si le rôle hérite des privilèges des rôles dont il est membre. Sans leINHERIT
, les membres doivent utiliserSET ROLE
passer à l'autre rôle afin d'accéder à ces privilèges exclusifs. Cet attribut est défini par défaut pour les nouveaux rôles.
Vous pouvez en savoir plus sur les attributs de rôle en consultant la documentation de PostgreSQL sur les attributs de rôle et le CREATE ROLE
commande.
Qu'est-ce qu'un superuser
rôle ?
Comme mentionné brièvement ci-dessus, un privilège spécial appelé superuser
permet un accès administratif illimité au cluster de bases de données. Ceci est similaire à la root
compte dans les systèmes d'exploitation de type Linux et Unix, mais au niveau de la base de données.
Il doit toujours y avoir au moins un rôle avec superuser
privilèges dans chaque cluster de bases de données. Le superuser
initial compte est créé au cours du processus d'installation. Le nom du superuser
initial compte peut varier en fonction du processus d'installation, mais le plus souvent, ce compte est appelé postgres
.
Il n'est pas recommandé d'effectuer votre travail quotidien en utilisant un compte avec superuser
privilèges, à la fois en raison de son potentiel d'actions destructrices et aussi pour minimiser le risque de compromettre un compte avec un large accès. Au lieu de cela, la plupart du temps, les utilisateurs doivent utiliser des comptes dédiés aux fonctions spécifiques ou aux objets de données avec lesquels ils travaillent, en utilisant uniquement le superuser
comptes lorsqu'un accès plus puissant est requis.
Vérification des attributs de rôle existants
Maintenant que vous avez une idée générale de ce que sont les attributs de rôle et des types de privilèges qu'ils autorisent, vous devez apprendre à trouver les attributs appliqués aux rôles dans PostgreSQL. Cette section vous montrera quelques commandes pour vous aider à trouver les attributs définis sur les rôles en général et sur votre propre rôle actuel en particulier.
Liste de tous les rôles de base de données et leurs attributs
Il existe différentes manières de vérifier les attributs appliqués aux rôles dans l'ensemble du système.
Si vous utilisez le psql
client de ligne de commande, vous pouvez tirer parti de certaines méta-commandes utiles qui vous permettent d'obtenir des informations sur les attributs de rôle sans requête.
Le \du
la méta-commande affiche tous les rôles et leurs attributs :
\du
List of roles Role name | Attributes | Member of-----------+------------------------------------------------------------+----------- postgres | Superuser, Create role, Create DB, Replication, Bypass RLS | {}
Dans ce cas, le postgres
role est le rôle par défaut avec superuser
privilèges configurés pour ce cluster de bases de données.
L'équivalent SQL pour lister les rôles (découvert en passant le -E
ou --echo-hidden
drapeau au démarrage de psql
) est :
SELECT r.rolname, r.rolsuper, r.rolinherit, r.rolcreaterole, r.rolcreatedb, r.rolcanlogin, r.rolconnlimit, r.rolvaliduntil, ARRAY(SELECT b.rolname FROM pg_catalog.pg_auth_members m JOIN pg_catalog.pg_roles b ON (m.roleid = b.oid) WHERE m.member = r.oid) as memberof, r.rolreplication, r.rolbypassrlsFROM pg_catalog.pg_roles rWHERE r.rolname !~ '^pg_'ORDER BY 1;
Une requête similaire qui fournit des informations sur les attributs de rôle (sans le composant d'appartenance au rôle) est présentée ci-dessous. Nous utilisons le psql
méta-commande \x on
pour afficher les résultats verticalement pour une meilleure lisibilité ici :
-- turn on vertical display\x onSELECT * FROM pg_roles WHERE rolname !~ '^pg_';-- turn off vertical display\x off
-[ RECORD 1 ]--+---------rolname | postgresrolsuper | trolinherit | trolcreaterole | trolcreatedb | trolcanlogin | trolreplication | trolconnlimit | -1rolpassword | ********rolvaliduntil | rolbypassrls | trolconfig | oid | 10
Si vous souhaitez uniquement voir quels rôles ont le superuser
attribut, vous pouvez demander une liste explicitement :
SELECT rolname FROM pg_roles WHERE rolsuper;
rolname---------- postgres(1 row)
Alternativement, vous pouvez lister tous les utilisateurs et leur superuser
statut pour une image plus complète :
SELECT usename,usesuper FROM pg_user;
usename | usesuper----------+---------- postgres | t user1 | f(2 rows)
Les mêmes informations peuvent être récupérées en utilisant le paradigme "rôle" de PostgreSQL au lieu de sa superposition "utilisateur" (parfois ambiguë) avec cette requête légèrement plus longue à la place :
SELECT rolname,rolsuper FROM pg_roles WHERE rolname !~ '^pg_';
rolname | rolsuper----------+---------- postgres | t user1 | f(2 rows)
Liste de vos propres attributs
Si vous souhaitez trouver les attributs du rôle que vous utilisez actuellement, vous pouvez facilement filtrer la sortie.
Lors de l'utilisation de psql
méta-commandes, vous pouvez utiliser le USER
variable, qui sera remplacée par le rôle connecté actuel. psql
utilise les deux-points (:
) pour interpoler des variables :
\du :USER
List of roles Role name | Attributes | Member of-----------+------------------------------------------------------------+----------- postgres | Superuser, Create role, Create DB, Replication, Bypass RLS | {}
Pour obtenir une liste montrant les valeurs de tous les attributs de rôle possibles, vous pouvez utiliser une requête comparant le nom du rôle à la valeur renvoyée par le CURRENT_ROLE
Fonction PostgreSQL. Encore une fois, nous utilisons la sortie verticale pour plus de lisibilité :
-- First, turn on vertical output\x onSELECT * FROM pg_roles WHERE rolename = CURRENT_ROLE;-- Change back to normal output\x off
-[ RECORD 1 ]--+---------rolname | postgresrolsuper | trolinherit | trolcreaterole | trolcreatedb | trolcanlogin | trolreplication | trolconnlimit | -1rolpassword | ********rolvaliduntil |rolbypassrls | trolconfig |oid | 10
Pour vérifier simplement si votre rôle actuel a superuser
privilèges, vous pouvez taper :
SHOW is_superuser;
is_superuser-------------- on(1 row)
Vérifiez si vous disposez des privilèges de gestion des rôles
Pour créer, modifier ou supprimer des rôles, vous devez soit avoir un superuser
ou CREATEROLE
privilèges.
Pour vérifier quels rôles au sein du système ont des privilèges de gestion des rôles, tapez :
SELECT rolname as "Users who can manage roles" FROM pg_roles WHERE rolsuper OR rolcreaterole;
Users who can manage roles---------------------------- postgres(1 rows)
Si vous souhaitez simplement savoir si votre rôle actuel dispose de privilèges de gestion des rôles, vous pouvez utiliser à la place :
SELECT 'Yes' AS "Can I manage roles?" FROM pg_roles WHERE rolname = :'USER' AND (rolsuper OR rolcreaterole);
Can I manage roles?--------------------- Yes(1 row)
Créer des rôles
Une fois que vous avez vérifié que vous disposez des privilèges de gestion des rôles, vous pouvez commencer à créer, modifier ou supprimer des rôles dans PostgreSQL.
Une option pour définir des attributs de rôle consiste à les déclarer au moment où vous créez le rôle. Cela vous permet de définir les conditions initiales du rôle, mais vous pouvez toujours les modifier par la suite si vous souhaitez modifier le niveau d'accès du rôle. Vous pouvez trouver plus d'informations sur le CREATE ROLE
commande que nous allons utiliser pour vous familiariser avec la syntaxe de base.
Une façon de créer un rôle est à partir de la ligne de commande. PostgreSQL inclut un createuser
commande qui créera un rôle dans le cluster de base de données avec LOGIN
privilèges.
La syntaxe générale est :
createuser <options> <rolename>
Par exemple, pour créer un rôle nommé admin
avec superuser
privilèges tout en demandant un mot de passe, vous pouvez taper :
createuser --superuser admin
Vous pourrez alors vous connecter en utilisant l'admin
compte selon les méthodes d'authentification décrites dans le pg_hba.conf
fichier.
Pour créer des rôles à l'aide de SQL
, la syntaxe générale ressemble à ceci :
CREATE ROLE <role>;
Les attributs peuvent être définis en les spécifiant après le nom du rôle en utilisant WITH
:
CREATE ROLE <role> WITH <options>;
Par exemple, pour créer un rôle nommé user1
qui peut se connecter avec le mot de passe secretpassword
, vous pouvez taper :
CREATE ROLE "user1" WITH LOGIN PASSWORD 'secretpassword';
Pour plutôt créer un rôle avec superuser
privilèges (vous devez également être un superuser
pour exécuter cette commande avec succès) qui ne peut pas login (l'utilisateur doit utiliser SET ROLE
pour passer à ce rôle), vous pouvez taper :
CREATE ROLE "user2" WITH SUPERUSER;
Modification des rôles existants
Pour modifier les attributs des rôles existants, vous pouvez utiliser le ALTER ROLE
commande à la place. Comme pour la création de rôle, votre rôle actuel doit également avoir soit superuser
ou CREATEROLE
privilèges. Les utilisateurs qui ne disposent pas de ces privilèges ne peuvent utiliser que le ALTER ROLE
commande pour changer son propre mot de passe.
La modification des rôles vous permet de modifier les attributs attribués à un rôle après sa création. Les mêmes attributs mentionnés dans la section de création de rôle peuvent être utilisés avec le ALTER ROLE
syntaxe. Une différence est que chaque type d'attribut peut être annulé en ajoutant le NO
préfixe. Par exemple, pour permettre à un rôle de se connecter au cluster de bases de données, vous pouvez lui donner le LOGIN
attribut. Pour supprimer cette capacité, vous devez modifier le rôle en spécifiant NOLOGIN
.
Le ALTER ROLE
La commande ne modifie que les attributs sont ceux explicitement mentionnés. En d'autres termes, le ALTER ROLE
la commande spécifie les changements aux attributs, et non à un ensemble complet de nouveaux attributs.
Pour autoriser l'user2
rôle pour vous connecter au cluster de bases de données, vous pouvez saisir :
ALTER ROLE "user2" WITH LOGIN;
Gardez à l'esprit que bien que cela permette de se connecter, les méthodes d'authentification autorisées sont toujours contrôlées par le pg_hba.conf
fichier.
Si vous voulez user2
pour pouvoir vous connecter, créer des rôles et créer des bases de données à la place, vous pouvez spécifier ces trois attributs, séparés par des espaces :
ALTER ROLE "user2" WITH LOGIN CREATEROLE CREATEDB;
Pour révoquer le superuser
statut d'un rôle (vous ne pouvez exécuter cette commande qu'en utilisant un autre superuser
rôle), saisissez :
ALTER ROLE "user2" WITH NOSUPERUSER;
Pour changer le mot de passe d'un rôle, vous pouvez taper ce qui suit (tous les rôles doivent pouvoir exécuter cette commande sur leur propre rôle, quel que soit CREATEROLE
ou superuser
privilèges):
ALTER ROLE <role> WITH PASSWORD '<password>';
Bien que la commande ci-dessus fonctionne, si possible, il est préférable d'utiliser le psql
méta-commande pour changer les mots de passe. Le psql
La commande demande automatiquement un mot de passe et le crypte avant de l'envoyer au serveur. Cela permet d'éviter la fuite de données sensibles dans les journaux.
Vous pouvez changer le mot de passe d'un rôle avec psql
en tapant ce qui suit
-- To change your own password\password-- To change the password for another role\password <role>
Vous pouvez également utiliser le ALTER ROLE
commande pour renommer un rôle :
ALTER ROLE <role> RENAME TO <newrole>
N'oubliez pas que vous ne pouvez pas renommer votre rôle de session actuel.
Supprimer des rôles
La suppression d'un rôle existant suit un schéma similaire aux commandes précédentes. Encore une fois, vous devez avoir CREATEROLE
ou superuser
privilèges pour exécuter ces commandes.
Un facteur de complication est que les rôles ne peuvent pas être supprimés s'ils sont toujours référencés par des objets dans la base de données. Cela signifie que vous devez supprimer ou transférer la propriété de tous les objets appartenant au rôle. Ensuite, vous devez également révoquer tous les privilèges supplémentaires dont dispose le rôle sur les objets de la base de données.
Une explication détaillée de la manière de réattribuer et de supprimer les privilèges de manière appropriée est fournie par Erwin Brandstetter sur le site Database Administrators Stack Exchange. Ce même processus est utilisé ci-dessous.
Tout d'abord, vous pouvez réaffecter tous les objets appartenant au rôle à l'aide du REASSIGNED OWNED
commande. Par exemple, si vous vous apprêtez à supprimer le user2
rôle, vous pouvez affecter ses objets au postgres
rôle en tapant :
REASSIGN OWNED BY "user2" TO "postgres";
Maintenant, les objets appartiennent à postgres
, nous pouvons utiliser le DROP OWNED
commande pour révoquer tous les autres privilèges qui nous ont été accordés sur les objets. Cette commande supprime également tous les objets que nous possédons, mais puisque nous venons de les transférer vers le postgres
rôle, le user2
le rôle n'a plus d'objets possédés. Pour cette raison, la commande ne révoquera que les privilèges supplémentaires du rôle :
DROP OWNED BY "user2";
Sans le DROP OWNED
raccourci ci-dessus, vous devrez exécuter REVOKE ALL PRIVILEGES
sur chaque objet individuel ou type d'objet sur lequel le rôle a des privilèges.
Une fois que vous avez révoqué tous les privilèges associés, vous pouvez supprimer le rôle en saisissant :
DROP ROLE "user2";
Se connecter avec psql
Une fois que vous avez configuré un nouveau rôle et que vous avez configuré les détails d'authentification à l'aide de pg_hba.conf
fichier, vous pouvez vous connecter au cluster de bases de données à l'aide de votre nouveau rôle. Le psql
le client de ligne de commande fournit un moyen simple de le faire.
Par défaut, psql
suppose que vous souhaitez vous connecter en utilisant un rôle qui correspond au nom d'utilisateur de votre système d'exploitation. Donc, si vous êtes connecté à votre ordinateur en tant que john
, psql
supposera que vous voulez essayer de vous connecter à la base de données en utilisant un rôle également appelé john
.
Pour remplacer ce comportement, vous pouvez passer le -U
ou --username=
option. Par exemple, si vous souhaitez vous connecter à un rôle appelé kerry
, vous pouvez taper :
psql -U kerry
Le succès du psql
dépendra de l'existence du kerry
rôle, l'accessibilité du serveur auquel vous essayez de vous connecter et les règles d'authentification définies sur le serveur.
Changer de rôle pendant une session
Parfois, vous souhaiterez peut-être adopter temporairement les privilèges et l'identité d'un autre rôle auquel vous avez accès. Par exemple, cela est nécessaire si vous souhaitez obtenir les privilèges d'un rôle dont vous êtes membre si votre rôle actuel n'a pas le INHERIT
attribut.
Pour comprendre comment cela fonctionne, vous devez connaître la terminologie utilisée par PostgreSQL pour catégoriser les rôles actifs :
- Rôle de session :Un rôle de session est le rôle avec lequel vous vous êtes connecté lors de votre connexion initiale au cluster de bases de données PostgreSQL. Il définit vos privilèges initiaux et détermine votre accès au système. Ce rôle doit avoir le
LOGIN
attribut. - Rôle actuel :En revanche, le rôle actuel est le rôle que vous exercez actuellement. Les privilèges associés au rôle actuel, qu'ils soient définis directement ou hérités d'autres rôles, déterminent les actions que vous êtes autorisé à effectuer et les objets auxquels vous avez accès.
Vous pouvez afficher les valeurs de votre session et de votre rôle actuel en saisissant :
SELECT SESSION_USER, CURRENT_USER;
current_user | session_user--------------+-------------- postgres | postgres(1 row)
Alors que la seule façon de changer votre rôle de session est de démarrer une nouvelle connexion en utilisant un rôle différent, vous pouvez changer votre rôle actuel en utilisant le SET ROLE
commande. Le SET ROLE
La commande est utilisée pour jouer temporairement un rôle différent. La commande prend également éventuellement les modificateurs suivants :
SESSION
:Le paramètre par défaut. Cela provoque leSET ROLE
commande pour affecter l'intégralité de la session de base de données.LOCAL
:Ce modificateur obligera la commande à modifier le rôle uniquement pour la transaction en cours.
Pour changer le rôle actuel en user2
rôle (pour le reste de la session), tapez :
SET ROLE "user2";
Si vous vérifiez vos valeurs de session et de rôle actuel, vous verrez que la valeur du rôle actuel a changé :
SELECT SESSION_USER, CURRENT_USER;
current_user | session_user--------------+-------------- user2 | postgres(1 row)
Toutes vos actions utiliseront désormais le user2
rôle comme contexte.
Pour revenir au rôle de session que vous utilisiez précédemment, vous pouvez saisir :
SET ROLE NONE;
Une alternative qui obtient le même résultat est :
RESET ROLE;
Conclusion
Le système de rôles, d'attributs de rôle, d'attributions et d'authentification de PostgreSQL crée un système flexible qui permet aux administrateurs de gérer efficacement les autorisations et l'accès à la base de données. Ce guide décrit ce que sont exactement les rôles et comment ils englobent un large éventail de cas d'utilisation. Il a également expliqué comment créer, modifier et supprimer des rôles et gérer les attributs de rôle qui déterminent leurs capacités globales. Comprendre comment gérer ces identités est nécessaire pour sécuriser vos bases de données et fournir un accès utilisable à vos utilisateurs légitimes.