GRANT <privilèges>¶

Attribue un ou plusieurs privilèges d’accès à un rôle ou un rôle de base de données sur un objet sécurisable. Les privilèges qui peuvent être accordés sont spécifiques à chaque objet.

Pour plus d’informations sur l’octroi de privilèges sur des objets sécurisables dans un partage, voir GRANT <privilège> … TO SHARE.

Rôles:

Les privilèges qui peuvent être accordés à des rôles sont regroupés dans les catégories suivantes :

Privilèges globaux.
Privilèges pour les objets de compte, comme des moniteurs de ressources, des entrepôts virtuels et des bases de données.
Privilèges pour les schémas.
Privilèges pour les objets de schéma, comme des tables, des vues, des zones de préparation, des formats de fichiers, des UDFs et des séquences.

Rôles de base de données:

Les privilèges qui peuvent être accordés à des rôles de base de données sont regroupés dans les catégories suivantes :

Privilèges pour la base de données qui contient le rôle de base de données.
Privilèges pour les schémas de la base de données qui contient le rôle de base de données.
Privilèges pour les objets de schéma, comme des tables, des vues, des zones de préparation, des formats de fichiers, des UDFs et des séquences dans la base de données qui contient le rôle de base de données.

Pour plus de détails sur les rôles et les objets sécurisables, voir Aperçu du contrôle d’accès.

Variations :: GRANT OWNERSHIP , GRANT <privilège> … TO SHARE
Voir aussi :: REVOKE <privilèges>

Syntaxe¶

Rôles de comptes :

GRANT {  { globalPrivileges         | ALL [ PRIVILEGES ] } ON ACCOUNT
       | { accountObjectPrivileges  | ALL [ PRIVILEGES ] } ON { USER | RESOURCE MONITOR | WAREHOUSE | COMPUTE POOL | DATABASE | INTEGRATION | FAILOVER GROUP | REPLICATION GROUP | EXTERNAL VOLUME } <object_name>
       | { schemaPrivileges         | ALL [ PRIVILEGES ] } ON { SCHEMA <schema_name> | ALL SCHEMAS IN DATABASE <db_name> }
       | { schemaPrivileges         | ALL [ PRIVILEGES ] } ON { FUTURE SCHEMAS IN DATABASE <db_name> }
       | { schemaObjectPrivileges   | ALL [ PRIVILEGES ] } ON { <object_type> <object_name> | ALL <object_type_plural> IN { DATABASE <db_name> | SCHEMA <schema_name> } }
       | { schemaObjectPrivileges   | ALL [ PRIVILEGES ] } ON FUTURE <object_type_plural> IN { DATABASE <db_name> | SCHEMA <schema_name> }
      }
  TO [ ROLE ] <role_name> [ WITH GRANT OPTION ]

Copy

Rôles de base de données :

GRANT {  { CREATE SCHEMA | MODIFY | MONITOR | USAGE } [ , ... ] } ON DATABASE <object_name>
       | { schemaPrivileges         | ALL [ PRIVILEGES ] } ON { SCHEMA <schema_name> | ALL SCHEMAS IN DATABASE <db_name> }
       | { schemaPrivileges         | ALL [ PRIVILEGES ] } ON { FUTURE SCHEMAS IN DATABASE <db_name> }
       | { schemaObjectPrivileges   | ALL [ PRIVILEGES ] } ON { <object_type> <object_name> | ALL <object_type_plural> IN { DATABASE <db_name> | SCHEMA <schema_name> } }
       | { schemaObjectPrivileges   | ALL [ PRIVILEGES ] } ON FUTURE <object_type_plural> IN { DATABASE <db_name> | SCHEMA <schema_name> }
      }
  TO DATABASE ROLE <database_role_name> [ WITH GRANT OPTION ]

Copy

Où :

globalPrivileges ::=
  {
      CREATE {
                ACCOUNT | COMPUTE POOL | DATA EXCHANGE LISTING | DATABASE | FAILOVER GROUP | INTEGRATION
                | NETWORK POLICY | EXTERNAL VOLUME | REPLICATION GROUP | ROLE | SHARE
                | USER | WAREHOUSE
      }
      | APPLY { { AGGREGATION | AUTHENTICATION | MASKING | PACKAGES | PASSWORD | PROJECTION | ROW ACCESS | SESSION } POLICY | TAG }
      | ATTACH POLICY | AUDIT | BIND SERVICE ENDPOINT
      | EXECUTE { ALERT | TASK }
      | IMPORT SHARE
      | MANAGE { GRANTS | LISTING AUTO FULFILLMENT | WAREHOUSES }
      | MODIFY { LOG LEVEL | TRACE LEVEL | SESSION LOG LEVEL | SESSION TRACE LEVEL }
      | MONITOR { EXECUTION | SECURITY | USAGE }
      | OVERRIDE SHARE RESTRICTIONS | PURCHASE DATA EXCHANGE LISTING | RESOLVE ALL
  }
  [ , ... ]

Copy

accountObjectPrivileges ::=
-- For COMPUTE POOL
   { MODIFY | MONITOR | OPERATE | USAGE } [ , ... ]
-- For DATABASE
   { APPLYBUDGET | CREATE { DATABASE ROLE | SCHEMA } | IMPORTED PRIVILEGES | MODIFY | MONITOR | USAGE } [ , ... ]
-- For EXTERNAL VOLUME
   { USAGE } [ , ... ]
-- For FAILOVER GROUP
   { FAILOVER | MODIFY | MONITOR | REPLICATE } [ , ... ]
-- For INTEGRATION
   { USAGE | USE_ANY_ROLE } [ , ... ]
-- For REPLICATION GROUP
   { MODIFY | MONITOR | REPLICATE } [ , ... ]
-- For RESOURCE MONITOR
   { MODIFY | MONITOR } [ , ... ]
-- For USER
   { MONITOR } [ , ... ]
-- For WAREHOUSE
   { APPLYBUDGET | MODIFY | MONITOR | USAGE | OPERATE } [ , ... ]

Copy

schemaPrivileges ::=
ADD SEARCH OPTIMIZATION
| APPLYBUDGET

| CREATE {
      ALERT | DYNAMIC TABLE | EXTERNAL TABLE | FILE FORMAT | FUNCTION | HYBRID TABLE | IMAGE REPOSITORY |
      | ICEBERG TABLE | MATERIALIZED VIEW | MODEL | NETWORK RULE | PIPE | PROCEDURE
      | { AGGREGATION | AUTHENTICATION | MASKING | PACKAGES | PASSWORD | PROJECTION | ROW ACCESS | SESSION } POLICY | SERVICE
      | SECRET | SEQUENCE | STAGE | STREAM | STREAMLIT
      | SNOWFLAKE.CORE.BUDGET |
      | SNOWFLAKE.ML.ANOMALY_DETECTION | SNOWFLAKE.ML.FORECAST
      | TAG | TABLE | TASK | VIEW
  }
| MODIFY | MONITOR | USAGE
[ , ... ]

Copy

schemaObjectPrivileges ::=
  -- For ALERT
     { MONITOR | OPERATE } [ , ... ]
  -- For DYNAMIC TABLE
     MONITOR, OPERATE, SELECT [ , ...]
  -- For EVENT TABLE
     { INSERT | SELECT } [ , ... ]
  -- For FILE FORMAT, FUNCTION (UDF or external function), MODEL, PROCEDURE, SECRET, or SEQUENCE
     USAGE [ , ... ]
  -- For HYBRID TABLE
     { INSERT | SELECT | UPDATE } [ , ... ]
  -- For IMAGE REPOSITORY
     { READ, WRITE } [ , ... ]
  -- For ICEBERG TABLE
     { APPLYBUDGET | DELETE | INSERT | REFERENCES | SELECT | TRUNCATE | UPDATE } [ , ... ]
  -- For PIPE
     { APPLYBUDGET | MONITOR | OPERATE } [ , ... ]
  -- For { AGGREGATION | AUTHENTICATION | MASKING | PACKAGES | PASSWORD | PROJECTION | ROW ACCESS | SESSION } POLICY or TAG
     APPLY [ , ... ]
  -- For SECRET
     READ, USAGE [ , ... ]
  -- For SERVICE
     { USAGE | MONITOR | OPERATE } [ , ... ]
  -- For external STAGE
     USAGE [ , ... ]
  -- For internal STAGE
     READ [ , WRITE ] [ , ... ]
  -- For STREAM
     SELECT [ , ... ]
  -- For STREAMLIT
     USAGE [ , ... ]
  -- For TABLE
     { APPLYBUDGET | DELETE | EVOLVE SCHEMA | INSERT | REFERENCES | SELECT | TRUNCATE | UPDATE } [ , ... ]
  -- For TAG
     READ
  -- For TASK
     { APPLYBUDGET | MONITOR | OPERATE } [ , ... ]
  -- For VIEW
     { REFERENCES | SELECT } [ , ... ]
  -- For MATERIALIZED VIEW
     { APPLYBUDGET | REFERENCES | SELECT } [ , ... ]

Copy

Pour plus de détails sur les privilèges pris en charge pour chaque type d’objet, voir Privilèges de contrôle d’accès.

Paramètres requis¶

object_name: Indique l’identificateur de l’objet sur lequel les privilèges sont accordés.

object_type

Spécifie le type d’objet pour les objets au niveau du schéma.

AGGREGATION POLICY
ALERT
AUTHENTICATION POLICY
DYNAMIC TABLE
EVENT TABLE
EXTERNAL TABLE
FILE FORMAT
FUNCTION
HYBRID TABLE
IMAGE REPOSITORY
ICEBERG TABLE
MASKING POLICY
MATERIALIZED VIEW
MODEL
NETWORK RULE
PACKAGES POLICY
PASSWORD POLICY
PIPE
PROCEDURE
PROJECTION POLICY
ROW ACCESS POLICY
SECRET
SERVICE
SESSION POLICY
SEQUENCE
STAGE
STREAM
TABLE
TAG
TASK
VIEW

object_type_plural

Forme plurielle de object_type (par exemple, TABLES, VIEWS).

Notez que les autorisations globales sur les canaux ne sont pas autorisées.

role_name

Spécifie l’identificateur du rôle du destinataire (c’est-à-dire le rôle auquel les privilèges sont accordés).

database_role_name

Spécifie l’identificateur du rôle de base de données destinataire (c’est-à-dire le rôle auquel les privilèges sont accordés). Si l’identificateur n’est pas complet sous la forme de db_name.database_role_name, la commande recherche le rôle de base de données dans la base de données actuelle de la session.

Tous les privilèges sont limités à la base de données qui contient le rôle de base de données, ainsi qu’aux autres objets de la même base de données.

Paramètres facultatifs¶

FUTURE

Spécifie que les privilèges sont accordés sur les nouveaux objets de base de données ou de schéma (futurs) d’un type spécifié (par exemple, tables ou vues) plutôt que sur les objets existants. Notez que les autorisations futures peuvent être annulées à tout moment en utilisant REVOKE <privilèges> avec les mots-clés ON FUTURE. Tous les privilèges accordés sur des objets existants sont conservés. Pour plus d’informations sur les autorisations futures, voir Futures autorisations sur des objets de base de données ou de schéma dans ce chapitre.

WITH GRANT OPTION

Si spécifié, permet au rôle destinataire d’accorder les privilèges à d’autres rôles.

Par défaut : aucune valeur, ce qui signifie que le rôle destinataire ne peut pas accorder les privilèges à d’autres rôles.

Note

Le paramètre WITH GRANT OPTION ne prend pas en charge le privilège IMPORTED PRIVILEGES. Pour plus d’informations, voir Attribution de privilèges sur une base de données partagée.

Notes sur l’utilisation¶

Les privilèges ne peuvent pas être accordées ou révoquées directement dans une classe. Vous pouvez toutefois créer une instance d’une classe et accorder des rôles d’instance à un rôle de compte. Accorder le privilège CREATE <nom_classe> sur le schéma pour permettre à un rôle de créer une instance d’une classe.
Pour accorder le privilège OWNERSHIP sur un objet (ou tous les objets d’un type spécifié dans un schéma) à un rôle, en transférant la propriété de l’objet d’un rôle à un autre, utilisez plutôt GRANT OWNERSHIP . La commande GRANT OWNERSHIP a une syntaxe différente.
Plusieurs privilèges peuvent être spécifiés pour le même type d’objet dans une seule instruction GRANT (chaque privilège étant séparé par des virgules), ou le mot clé spécial ALL [ PRIVILEGES ] peut être utilisé pour accorder tous les privilèges applicables au type d’objet spécifié. Notez, cependant, que seuls les privilèges détenus et pouvant être accordés par le rôle exécutant la commande GRANT sont réellement accordés au rôle cible. Un message d’avertissement est renvoyé pour tout privilège qui n’a pas pu être accordé.
- Vous ne pouvez pas spécifier ce mot-clé pour les balises.
- Ce mot-clé n’accorde pas de privilèges à une classe si vous essayez d’accorder des privilèges ALL à un schéma. Pour permettre à un rôle de créer des instances d’une classe particulière, accordez le privilège CREATE directement comme indiqué dans l’exemple Classes.
Les privilèges accordés à un rôle particulier sont automatiquement hérités par tous les autres rôles auxquels le rôle est accordé, ainsi que tous les autres rôles de niveau supérieur dans la hiérarchie des rôles. Pour plus de détails, voir Aperçu du contrôle d’accès.
Pour les bases de données, le privilège IMPORTED PRIVILEGES ne s’applique qu’aux bases de données partagées (c’est-à-dire les bases de données créées à partir d’un partage). Pour plus de détails, voir Consommation de données partagées. Notez que le privilège IMPORTED PRIVILEGES ne peut pas être accordé à un rôle de base de données.
Pour les schémas et les objets dans les schémas, une option ALL object_type_plural in container est fournie pour accorder des privilèges sur tous les objets du même type dans le conteneur (c’est-à-dire la base de données ou le schéma). C’est une option pratique ; en interne, la commande est étendue en une série de commandes GRANT individuelles sur chaque objet. Seuls les objets qui existent actuellement dans le conteneur sont concernés.

Toutefois, il est à noter que, dans le modèle de Snowflake, l’octroi de privilèges en lot n’est pas une pratique recommandée. Snowflake vous recommande plutôt de créer un rôle partagé et de l’utiliser pour créer des objets qui sont automatiquement accessibles à tous les utilisateurs auxquels le rôle a été accordé.
Dans les schémas d’accès gérés :
- Le privilège OWNERSHIP sur les objets ne peut être transféré que vers un rôle subordonné du propriétaire du schéma.
Pour les zones de préparation :
- USAGE ne s’applique qu’aux zones de préparation externes.
- READ | WRITE ne s’appliquent qu’aux zones de préparation internes. De plus, pour accorder le privilège WRITE sur une zone de préparation interne, le privilège READ doit d’abord être accordé sur la zone de préparation.
Pour plus de détails sur les zones de préparation externes et internes, voir CREATE STAGE.
Lorsque vous accordez des privilèges à une UDF individuelle ou à une procédure stockée, vous devez spécifier les types de données des arguments, le cas échéant, à l’aide de la syntaxe indiquée ci-dessous :
```
<udf_or_stored_procedure_name> ( [ <arg_data_type> [ , ... ] ] )
```
Copy
Snowflake utilise des types de données d’argument pour résoudre des UDFs ou des procédures stockées qui ont le même nom dans un schéma. Pour plus d’informations, voir Surcharge de procédures et de fonctions.
Pour les tables dynamiques, le rôle récepteur doit se voir accordé le privilège USAGE sur la base de données et le schéma qui contient la table dynamique, ainsi que sur l’entrepôt utilisé pour actualiser la table. Pour plus d’informations, voir Contrôle de l’accès aux tables dynamiques.

Exigences en matière de contrôle d’accès¶

Accorder des privilèges sur des objets individuels:

En général, un rôle possédant l’un des ensembles de privilèges suivants peut accorder des privilèges sur un objet à d’autres rôles :

Le privilège MANAGE GRANTS global.

Seuls les rôles système SECURITYADMIN et ACCOUNTADMIN ont le privilège MANAGE GRANTS ; cependant, le privilège peut être accordé à des rôles personnalisés.
Le privilège OWNERSHIP sur l’objet. Lors de l’accord de privilèges sur des objets de schéma (par exemple, des tables et des vues), le rôle doit avoir le privilège USAGE sur la base de données et le schéma parents.
Si un privilège a été accordé à un rôle dont le paramètre WITH GRANT OPTION est inclus dans l’instruction GRANT <privilèges> … TO ROLE, le rôle peut accorder le même privilège à d’autres rôles.

Dans les schémas d’accès géré, (c’est-à-dire les schémas créés avec la syntaxe CREATE SCHEMA … WITH MANAGED ACCESS), les propriétaires d’objets perdent la capacité de prendre des décisions d’attribution. Seul le propriétaire du schéma (c’est-à-dire le rôle doté du privilège OWNERSHIP sur le schéma) ou un rôle doté du privilège global MANAGE GRANTS peut octroyer des privilèges sur les objets du schéma.

Notez qu’un rôle qui détient le privilège global MANAGE GRANTS peut accorder des privilèges supplémentaires au rôle actuel (concédant).

Définition des autorisations sur les futurs objets d’un type spécifié:

Niveau base de données

Le privilège global MANAGE GRANTS est requis pour accorder des privilèges sur des objets futurs dans une base de données. Seuls les rôles système SECURITYADMIN et ACCOUNTADMIN ont le privilège MANAGE GRANTS ; cependant, le privilège peut être accordé à des rôles personnalisés.

Niveau de schéma

Dans les schémas d’accès géré (c’est-à-dire les schémas créés à l’aide de la syntaxe CREATE SCHEMA … WITH MANAGED ACCESS), soit le propriétaire du schéma (c’est-à-dire le rôle avec le privilège OWNERSHIP sur le schéma) ou un rôle avec le privilège global MANAGE GRANTS peut accorder des privilèges sur de futurs objets dans le schéma.

Dans les schémas standards, le privilège global MANAGE GRANTS est requis pour accorder des privilèges sur des objets futurs au sein du schéma.

Pour plus d’informations sur la définition des attributions sur les futurs objets d’un type spécifié, consultez Futures autorisations sur des objets de base de données ou de schéma (dans cette rubrique).

Futures autorisations sur des objets de base de données ou de schéma¶

Les remarques de cette section s’appliquent lors de l’affectation d’autorisations futures à des objets d’un schéma ou d’une base de données ; c’est-à-dire lorsque vous utilisez le mot clé ON FUTURE.

Pour plus d’informations, voir les schémas d’accès gérés.

Considérations¶

Lorsque les autorisations futures sont définies sur le même type d’objet pour une base de données et un schéma dans la même base, les autorisations au niveau du schéma ont priorité sur les autorisations au niveau de la base de données et les autorisations au niveau de la base de données sont ignorées. Ce comportement s’applique aux privilèges sur les objets futurs accordés à un rôle ou à différents rôles.

Par exemple, les instructions suivantes accordent des privilèges différents sur les objets du même type au niveau de la base de données et du schéma.

Accorder le privilège SELECT sur tous les futurs schémas de la base de données d1 au rôle r1 :
```
GRANT SELECT ON FUTURE TABLES IN DATABASE d1 TO ROLE r1;
```
Copy
Accorder les privilèges INSERT et DELETE sur toutes les futures tables créées dans le schéma d1.s1 au rôle r2.
```
GRANT INSERT,DELETE ON FUTURE TABLES IN SCHEMA d1.s1 TO ROLE r2;
```
Copy
Les autorisations futures attribuées au rôle r1 sont complètement ignorées. Lorsque de nouvelles tables sont créées dans le schéma d1.s1, seuls les privilèges futurs définis dans les tables du rôle r2 sont autorisés.
Les autorisations futures au niveau de la base de données s’appliquent aux schémas d’accès réguliers et gérés.

Restrictions et limitations¶

Une seule autorisation future du privilège OWNERSHIP est autorisée sur chaque type d’objet sécurisable.

Les autorisations futures ne peuvent pas être définies sur les objets des types suivants :
- Pool de calcul
- Fonction externe
- Référentiel d’images
- Objets de politique :
  - Politique d’agrégation
  - Politique de masquage
  - Politique de paquets
  - Politique de projection
  - Politique d’accès aux lignes
  - Politique de session
- Balise

Une attribution future du privilège OWNERSHIP sur des objets d’un type spécifié dans une base de données ne s’applique pas aux nouveaux objets dans un schéma d’accès géré.
Les restrictions suivantes s’appliquent aux attributions futures sur des objets d’un schéma d’accès géré :
- Une autorisation future du privilège OWNERSHIP sur des objets ne peut être appliquée qu’à un rôle subordonné du propriétaire du schéma (c’est-à-dire le rôle qui dispose du privilège OWNERSHIP sur le schéma).
- Avant que la propriété d’un schéma d’accès géré ne soit transférée à un rôle différent, toutes les autorisations futures ouvertes du privilège OWNERSHIP doivent être révoquées à l’aide de REVOKE <privilèges> et des mots clés ON FUTURE.
Les autorisations futures ne sont pas appliquées lors du changement de nom ou de l’échange d’une table.
Les autorisations futures sont prises en charge sur les zones de préparation nommées avec les restrictions suivantes :
- Le privilège WRITE ne peut pas être spécifié sans le privilège READ.
- Le privilège READ ne peut pas être révoqué si le privilège WRITE est présent.
- Pour les zones de préparation internes, seules les autorisations futures avec le privilège READ ou WRITE sont matérialisées.
- Pour les zones de préparation externes, seules les autorisations futures avec les privilèges USAGE sont matérialisées.

Exemples¶

Rôles¶

Accorder les privilèges nécessaires à l’exploitation (c’est-à-dire suspendre ou reprendre) de l’entrepôt virtuel report_wh au rôle analyst :

GRANT OPERATE ON WAREHOUSE report_wh TO ROLE analyst;

Copy

Comme dans l’exemple précédent, mais permet aussi au rôle analyst d’accorder le privilège à d’autres rôles :

GRANT OPERATE ON WAREHOUSE report_wh TO ROLE analyst WITH GRANT OPTION;

Copy

Accorder le privilège SELECT sur toutes les tables existantes dans le schéma mydb.myschema au rôle analyst :

GRANT SELECT ON ALL TABLES IN SCHEMA mydb.myschema to ROLE analyst;

Copy

Accorder tous les privilèges sur deux UDFs dans le schéma mydb.myschema au rôle analyst :

GRANT ALL PRIVILEGES ON FUNCTION mydb.myschema.add5(number) TO ROLE analyst;

GRANT ALL PRIVILEGES ON FUNCTION mydb.myschema.add5(string) TO ROLE analyst;
Copy
Notez que les UDFs ont des arguments différents, c’est ainsi que Snowflake identifie de façon unique les UDFs avec le même nom. Pour plus de détails sur les conventions d’appellation des UDF, voir Vue d’ensemble des fonctions définies par l’utilisateur.

Accorder le privilège d’utilisation d’une procédure stockée dans le schéma mydb.myschema au rôle analyst :

GRANT USAGE ON PROCEDURE mydb.myschema.myprocedure(number) TO ROLE analyst;
Copy
Notez que les noms de procédures stockées (comme les noms des UDF) peuvent être surchargés, vous devez donc spécifier le type de données des arguments. Pour plus de détails sur la surcharge de noms, voir Surcharge de procédures et de fonctions.

Accordez le privilège de créer des vues matérialisées dans le schéma spécifié :

GRANT CREATE MATERIALIZED VIEW ON SCHEMA mydb.myschema TO ROLE myrole;

Copy

Accorder les privilèges SELECT et INSERT sur toutes les futures tables créées dans le schéma mydb.myschema au rôle role1 :

GRANT SELECT,INSERT ON FUTURE TABLES IN SCHEMA mydb.myschema
TO ROLE role1;

Copy

Accordez le privilège USAGE sur tous les futurs schémas de la base de données mydb au rôle role1 :

use role accountadmin;

grant usage on future schemas in database mydb to role role1;

Copy

Rôles de base de données¶

Accorder le privilège SELECT sur toutes les tables existantes dans le schéma mydb.myschema au rôle de base de données mydb.dr1 :

GRANT SELECT ON ALL TABLES IN SCHEMA mydb.myschema
  TO DATABASE ROLE mydb.dr1;

Copy

Accorder tous les privilèges sur deux UDFs dans le schéma mydb.myschema au rôle de base de données mydb.dr1 :

GRANT ALL PRIVILEGES ON FUNCTION mydb.myschema.add5(number)
  TO DATABASE ROLE mydb.dr1;

GRANT ALL PRIVILEGES ON FUNCTION mydb.myschema.add5(string)
  TO DATABASE ROLE mydb.dr1;
Copy
Notez que les UDFs ont des arguments différents, c’est ainsi que Snowflake identifie de façon unique les UDFs avec le même nom. Pour plus de détails sur les conventions d’appellation des UDF, voir Vue d’ensemble des fonctions définies par l’utilisateur.

Accorder le privilège d’utilisation d’une procédure stockée dans le schéma mydb.myschema au rôle de base de données mydb.dr1 :

GRANT USAGE ON PROCEDURE mydb.myschema.myprocedure(number)
  TO DATABASE ROLE mydb.dr1;
Copy
Notez que les noms de procédures stockées (comme les noms des UDF) peuvent être surchargés, vous devez donc spécifier le type de données des arguments. Pour plus de détails sur le surchargement des procédures stockées, voir Surcharge de procédures et de fonctions.

Accorder le privilège de créer des vues matérialisées dans le schéma spécifié dans le rôle de base de données mydb.dr1 :

GRANT CREATE MATERIALIZED VIEW ON SCHEMA mydb.myschema
  TO DATABASE ROLE mydb.dr1;

Copy

Accorder les privilèges SELECT et INSERT sur toutes les futures tables créées dans le schéma mydb.myschema au rôle de base de données mydb.dr1 :

GRANT SELECT,INSERT ON FUTURE TABLES IN SCHEMA mydb.myschema
  TO DATABASE ROLE mydb.dr1;

Copy

Accordez le privilège USAGE sur tous les futurs schémas de la base de données mydb au rôle role1 :

USE ROLE ACCOUNTADMIN;

GRANT USAGE ON FUTURE SCHEMAS IN DATABASE mydb
  TO DATABASE ROLE mydb.dr1;

Copy

Classes¶

Pour permettre à un rôle de compte de créer des budgets dans un schéma, accordez au rôle le privilège CREATE SNOWFLAKE.CORE.BUDGET sur le schéma :

USE ROLE ACCOUNTADMIN;

GRANT CREATE SNOWFLAKE.CORE.BUDGET ON SCHEMA budgets_db.budgets_schema
  TO ROLE budget_admin;

Copy

Pour permettre à un rôle de compte de créer un modèle de fonction Snowflake Cortex alimenté par ML (prévision, détection d’anomalie ou classification) dans un schéma, accordez au rôle le privilège approprié sur le schéma. Les privilèges suivants sont disponibles.

CREATE SNOWFLAKE.ML.ANOMALY_DETECTION
CREATE SNOWFLAKE.ML.CLASSIFICATION
CREATE SNOWFLAKE.ML.FORECAST