Hologres:Using the schema-level permission model

Prérequis

Avant de commencer, assurez-vous de disposer des éléments suivants :

• Un accès superutilisateur à l'instance Hologres

• Un outil de développement connecté à l'instance (par exemple, HoloWeb ou psql)

Activer SLPM pour une base de données

1. Installez l'extension SLPM. Exécutez cette commande une fois par base de données.

   create extension slpm;

2. Activez SLPM. Assurez-vous qu'aucune instruction SQL n'est en cours d'exécution sur la base de données lorsque vous exécutez cette commande.

   call slpm_enable ();

3. (Facultatif) Migrer depuis le modèle d'autorisations PostgreSQL standard. Si la base de données contient déjà des tables, des vues ou des tables externes gérées selon le modèle PostgreSQL standard, migrez la propriété des objets existants vers SLPM à l'aide de la commande suivante.

   1. Connectez-vous à la console Hologres. Dans le volet de navigation de gauche, cliquez sur Go to HoloWeb.

   2. Cliquez sur Security Center. Sur la page DB Authorization, vérifiez le modèle d'autorisation actuel.

   La fonction slpm_migrate traite jusqu'à 64 utilisateurs par exécution (paramètre ajustable). Si la base de données compte plus d'utilisateurs, exécutez la fonction plusieurs fois jusqu'à ce que toutes les autorisations soient migrées. Pour plus de détails sur les paramètres, consultez slpm_migrate.

   -- Transfer ownership of existing objects to the developer group for SLPM management.
   call slpm_migrate ();

   Pour vérifier quel modèle d'autorisation est actif avant la migration :

Étape 1 : Créer l'utilisateur

Ignorez cette étape si l'utilisateur existe déjà dans l'instance.

-- Create a user.
call slpm_create_user('<account>');

-- Create a user and add them to a group in one step.
call slpm_create_user('<account>', '{dbname}.[admin|{schemaname}.developer|{schemaname}.writer|{schemaname}.viewer]');

Remplacez <account> par l'un des formats suivants :

Pour utiliser un UID d'utilisateur RAM, ajoutez le préfixe p4_. Obtenez l'UID depuis la page Users de la console RAM. Pour en savoir plus sur les formats de compte, consultez Système de comptes.

Étape 2 : Ajouter l'utilisateur à un groupe

call slpm_grant('{dbname}.[admin|{schemaname}.developer|{schemaname}.writer|{schemaname}.viewer]', '<account>');

Si vous avez déjà ajouté l'utilisateur à un groupe lors de sa création, ignorez cette étape.

Exemples :

L'exemple suivant ajoute un compte Alibaba Cloud au groupe admin de mydb.

call slpm_grant('mydb.admin', '197006222995xxx');
call slpm_grant('mydb.admin', 'ALIYUN$xxx');

L'exemple suivant ajoute des utilisateurs au groupe developer du schéma public dans mydb.

call slpm_grant('mydb.public.developer', '197006222995xxx');
call slpm_grant('mydb.public.developer', 'RAM$mainaccount:subuser');

L'exemple suivant ajoute un utilisateur au groupe viewer du schéma lisa dans MYDB (nom de base de données sensible à la casse).

call slpm_grant('"MYDB.lisa.viewer"', '197006222995xxx');
call slpm_grant('mydb.lisa.viewer', '"xxx@aliyun.com"');

call slpm_revoke('{dbname}.[admin|{schemaname}.developer|{schemaname}.writer|{schemaname}.viewer]', '<account>');

call slpm_revoke('dbname.admin', 'p4_564306222995xxx');
call slpm_revoke('dbname.admin', '197006222995xxx');
call slpm_revoke('dbname.admin', '"xxx@aliyun.com"');

call slpm_revoke('mydb.lisa.developer', 'RAM$mainaccount:subuser');
call slpm_revoke('mydb.public.developer', 'p4_564306222995xxx');

call slpm_revoke('"MYDB.SCHEMA1.viewer"', 'p4_564306222995xxx');

DROP ROLE "<account>";

Étape 1 : Désactiver le modèle

Seul un superutilisateur peut désactiver SLPM.

call slpm_disable ();

Après la désactivation :

• Les quatre groupes d'utilisateurs ({db}.admin, {db}.{schemaname}.developer, {db}.{schemaname}.writer, {db}.{schemaname}.viewer) conservent leurs autorisations sur les objets existants. Les autorisations ne s'étendent pas aux nouveaux objets.

• PUBLIC reçoit les autorisations suivantes : USAGE et CREATE sur le schéma public ; CONNECT et TEMPORARY sur la base de données ; EXECUTE sur les fonctions et procédures ; USAGE sur les langages et types de données (y compris les domaines).

• PUBLIC ne reçoit pas d'autorisations sur les tables, vues, vues matérialisées, colonnes de table, séquences, wrappers de données distantes, serveurs distants ou schémas non publics. Contactez un superutilisateur pour accorder ces autorisations individuellement.

Étape 2 : Nettoyer les groupes d'utilisateurs (facultatif)

Les groupes d'utilisateurs ne sont pas supprimés automatiquement lors de la désactivation de SLPM. Pour les supprimer, appelez slpm_cleanup.

Assurez-vous qu'aucune instruction SQL n'est en cours d'exécution sur la base de données avant d'appeler slpm_cleanup. La fonction slpm_cleanup transfère la propriété des objets par lots de 64 (paramètre ajustable). Exécutez-la plusieurs fois si nécessaire, mais évitez de dépasser cinq exécutions. Pour plus de détails, consultez slpm_cleanup.

Scénario 1 : Supprimer les groupes d'utilisateurs tout en conservant la base de données.

Exécutez la commande suivante dans la base de données cible en tant que superutilisateur.

call slpm_cleanup('<dbname>');

Scénario 2 : Supprimer les groupes d'utilisateurs après la suppression de la base de données.

Exécutez la commande suivante dans une autre base de données (telle que postgres) en tant que superutilisateur.

call slpm_cleanup('mydb');

Quand utiliser cette fonctionnalité

Un modèle courant d'entrepôt de données consiste à organiser les données en schémas stratifiés, par exemple ODS (Operation Data Store), DWD, DWS (Data Warehouse Service) et ADS, puis à créer des vues récapitulatives dans une couche externe qui joignent des tables provenant de plusieurs couches internes.

Prenons l'exemple suivant où une vue dans le schéma ads joint des tables de ods et de dwd :

La DDL de la vue :

CREATE VIEW ads.customer_total_order_price_view AS
SELECT
    c_name,
    sum(o_totalprice)
FROM
    ods.orders AS o
INNER JOIN dwd.customer AS c
ON o.o_custkey = c.c_custkey
GROUP BY
    1;

Conditions d'autorisation

Dans l'exemple ci-dessus, pour créer ads.customer_total_order_price_view en tant que ads_dev_user :

• Accordez à ads_dev_user l'autorisation developer sur ads.

• Accordez à ads_dev_user l'autorisation viewer sur ods et dwd.

Pour permettre à ads_view_user d'interroger la vue, accordez à ads_view_user l'autorisation viewer sur ads.

Activer la fonctionnalité de vue inter-schémas

Exécutez la commande suivante en tant que superutilisateur.

call slpm_enable_multi_schema_view();

Transférer la propriété de la vue

Une fois la fonctionnalité activée, l'utilisateur qui crée une vue en devient le propriétaire. Seul le propriétaire peut la modifier ou la supprimer. Pour transférer la propriété, par exemple avant de retirer un utilisateur de la base de données, exécutez la commande suivante. Le nouveau propriétaire doit disposer de l'autorisation developer sur le schéma de la vue et de l'autorisation viewer ou supérieure sur tous les schémas source.

-- Syntax
call slpm_alter_view_owner('view_name', '<account>');

-- Example: transfer ownership of ads.customer_total_order_price_view to p4_xxxxx.
call slpm_alter_view_owner('ads.customer_total_order_price_view', 'p4_xxxxx');

Désactiver la fonctionnalité de vue inter-schémas

-- Disable cross-schema view support.
call slpm_disable_multi_schema_view();
-- Transfer all view ownership back to the developer group of each view's schema.
call slpm_migrate();

Après l'exécution de ces commandes, les vues existantes non inter-schémas restent interrogeables et SLPM se comporte normalement. Les vues inter-schémas ne peuvent plus être interrogées.