ApsaraDB for SelectDB:Gérer les permissions de base

Concepts clés

Les propriétés utilisateur sont associées au nom d'utilisateur , et non à une identité utilisateur spécifique. Plusieurs identités partageant le même nom d'utilisateur disposent d'un ensemble unique de propriétés utilisateur.

Rôles intégrés

Lors de l'initialisation d'une instance SelectDB, le système crée automatiquement deux rôles et leurs utilisateurs correspondants.

Vous ne pouvez ni révoquer ni modifier les permissions des rôles ou utilisateurs créés automatiquement.

Si vous avez oublié le mot de passe de l'utilisateur admin et ne parvenez plus à vous connecter à l'instance, réinitialisez-le depuis la console SelectDB. Pour plus d'informations, consultez Réinitialiser le mot de passe d'un utilisateur admin pour une instance.

Types de permissions

Le tableau suivant décrit les types de permissions disponibles ainsi que les niveaux auxquels chacune peut s'appliquer.

Niveaux de permissions

Les permissions s'appliquent aux objets de données selon quatre niveaux de portée.

Les permissions sur les ressources utilisent une portée distincte (RESOURCE resource_name) et ne correspondent pas aux niveaux de données.

Référence de la syntaxe SQL

Permissions ADMIN_PRIV et GRANT_PRIV

ADMIN_PRIV et GRANT_PRIV permettent toutes deux d'accorder des permissions à d'autres utilisateurs, mais leur portée diffère.

• ADMIN_PRIV : Ne peut être accordée ou révoquée qu'au niveau global. Au niveau global, GRANT_PRIV équivaut à ADMIN_PRIV ; utilisez-les avec prudence.

• GRANT_PRIV : Peut être limitée au niveau global, catalogue, base de données ou table. Un utilisateur disposant de GRANT_PRIV à un niveau donné ne peut accorder des permissions que dans cette portée.

Le tableau ci-dessous indique la permission requise pour chaque opération d'administration.

Les utilisateurs disposant de GRANT_PRIV à un niveau non global ne peuvent pas modifier le mot de passe d'un utilisateur existant. Ils peuvent uniquement définir un mot de passe lors de la création d'un nouvel utilisateur.

Pour consulter votre identité utilisateur authentifiée actuelle, exécutez :

SELECT current_user();

Pour connaître votre identité de connexion réelle, exécutez :

SELECT user();

Toutes les permissions s'appliquent à current_user, c'est-à-dire l'identité ayant passé l'authentification.

Par exemple, si vous créez un utilisateur dont l'identité est user1@'192.%' et que user1 se connecte depuis le bloc CIDR 192.168.0.0/16, alors current_user correspond à user1@'192.%' tandis que user vaut user1@'192.168.%'. Toutes les permissions s'appliquent à l'identité current_user.

Propriétés utilisateur

Les propriétés utilisateur contrôlent les limites de ressources et le comportement associés à un nom d'utilisateur donné. Définissez-les avec SET PROPERTY et consultez-les avec SHOW PROPERTY.

Lorsqu'un même paramètre existe à plusieurs niveaux, le système le résout selon l'ordre suivant :

session variable > user property > global variable > default value

Exemples

-- Create the user, allowing login from the 172.10.0.0/16 CIDR block
CREATE USER test_user@'172.10.%' IDENTIFIED BY '123456';

-- Grant read, modify, and import permissions on the table
GRANT SELECT_PRIV, ALTER_PRIV, LOAD_PRIV ON test_db.test_table TO 'test_user'@'172.10.%';

REVOKE SELECT_PRIV ON test_db.* FROM 'test_user'@'172.10.%';

-- Create the role
CREATE ROLE test_role;

-- Grant import permissions on all tables in test_db to the role
GRANT LOAD_PRIV ON test_db.* TO ROLE 'test_role';

-- Assign the role to a user
GRANT "test_role" TO test_user@'172.10.%';

-- Query all properties of a user
SHOW PROPERTY FOR 'test_user';

-- Filter by property name
SHOW PROPERTY FOR 'test_user' LIKE '%max_user_connections%';

-- Set a property
SET PROPERTY FOR 'test_user' 'max_user_connections' = '1000';

DROP USER 'test_user'@'172.10.%';
DROP ROLE test_role;

SHOW GRANTS FOR test_user@'%';

Bonnes pratiques

Remarques d'utilisation

• ADMIN_PRIV ne peut être accordée et révoquée qu'au niveau global.

• Au niveau global, GRANT_PRIV équivaut à ADMIN_PRIV car elle permet d'accorder toutes les permissions. Appliquez-la avec prudence.

• Toutes les permissions s'appliquent à current_user (l'identité authentifiée), et non à l'identité de connexion réelle (user).

FAQ

Que faire si un nom de domaine entre en conflit avec une adresse IP lors de la création d'un utilisateur ?

Supprimez l'utilisateur conflictuel avec DROP USER, puis recréez-le avec l'identité correcte.

En cas de conflit entre un domaine et une IP, créez d'abord l'utilisateur avec l'identité de domaine, puis accordez les permissions au niveau du domaine :

CREATE USER test_user@['domain'];
GRANT SELECT_PRIV ON *.* TO test_user@['domain'];

Si le DNS résout le domaine en IP1 et IP2, et que vous accordez ultérieurement une permission différente à test_user@'IP1', cette identité obtient son propre jeu de permissions. Ainsi, la modification de test_user@['domain'] n'affecte pas test_user@'IP1'.

Que faire si deux identités utilisateur avec des plages IP chevauchantes entrent en conflit ?

Créez l'identité la plus spécifique. Le modèle d'hôte le plus précis est toujours prioritaire.

CREATE USER test_user@'%' IDENTIFIED BY "12345";
CREATE USER test_user@'192.%' IDENTIFIED BY "abcde";

Une tentative de connexion depuis la plage 192.168.0.0/16 correspond à 192.% (priorité supérieure). L'utilisation du mot de passe 12345 depuis cette plage sera rejetée ; utilisez plutôt abcde.

Étapes suivantes

• Accorder à un utilisateur les permissions d'accès aux clusters

• Réinitialiser le mot de passe d'un utilisateur admin pour une instance