GRANT <privilèges> … TO APPLICATION ROLE¶

Syntaxe¶

GRANT {
        { schemaPrivileges         | ALL [ PRIVILEGES ] } ON SCHEMA <schema_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 SCHEMA <schema_name>
      }
    TO APPLICATION ROLE <name> [ WITH GRANT OPTION ]

Où :

schemaPrivileges ::=
ADD SEARCH OPTIMIZATION
| CREATE {
    ALERT | EXTERNAL TABLE | FILE FORMAT | FUNCTION
    | MATERIALIZED VIEW | PIPE | PROCEDURE
    | { MASKING | PASSWORD | ROW ACCESS | SESSION } POLICY
    | SECRET | SEQUENCE | STAGE | STREAM
    | TAG | TABLE | TASK | VIEW
  }
| MODIFY | MONITOR | USAGE
[ , ... ]

schemaObjectPrivileges ::=
  -- For ALERT
     { MONITOR | OPERATE } [ , ... ]
  -- For DYNAMIC TABLE
     OPERATE, SELECT [ , ...]
  -- For EVENT TABLE
     { INSERT | SELECT } [ , ... ]
  -- For FILE FORMAT, FUNCTION (UDF or external function), PROCEDURE, SECRET, or SEQUENCE
     USAGE [ , ... ]
  -- For PIPE
     { APPLYBUDGET | MONITOR | OPERATE } [ , ... ]
  -- For { MASKING | PACKAGES | PASSWORD | ROW ACCESS | SESSION } POLICY or TAG
     APPLY [ , ... ]
  -- For SECRET
     READ, USAGE [ , ... ]
  -- For external STAGE
     USAGE [ , ... ]
  -- For internal STAGE
     READ [ , WRITE ] [ , ... ]
  -- For STREAM
     SELECT [ , ... ]
  -- 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 } [ , ... ]

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.

• ALERT

• DYNAMIC TABLE

• EVENT TABLE

• EXTERNAL TABLE

• FILE FORMAT

• FUNCTION

• MASKING POLICY

• MATERIALIZED VIEW

• NETWORK RULE

• PACKAGES POLICY

• PASSWORD POLICY

• PIPE

• PROCEDURE

• ROW ACCESS POLICY

• SECRET

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

name

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

Paramètres facultatifs¶

ON FUTURE

Spécifie que les privilèges sont accordés sur les nouveaux objets de schéma (futurs) d’un type spécifié plutôt que sur les objets existants. Les autorisations futures peuvent être annulées à tout moment en utilisant REVOKE <privilèges> FROM APPLICATION ROLE 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 schéma dans cette rubrique.

WITH GRANT OPTION

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

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

Note

La clause WITH GRANT OPTION ne prend pas en charge le privilège IMPORTED PRIVILEGES. Pour plus d’informations, reportez-vous à Attribution de privilèges sur une base de données partagée.

Notes sur l’utilisation¶

Vous devez utiliser un rôle d’application pour attribuer et révoquer des privilèges sur les objets d’une application.

Cette commande a des restrictions différentes selon que vous êtes le fournisseur ou le consommateur de l’application.

Le consommateur d’applications ne peut pas faire ce qui suit concernant un rôle d’application :

• Accorder ou révoquer les privilèges d’un objet par rapport à un rôle d’application.

• Accorder un rôle d’application à une base de données ou à un partage, ou révoquer un rôle d’application d’une base de données ou d’un partage.

• Attribuer un rôle à la même application ou à une application différente, ou révoquer un rôle à la même application ou à une application différente.

Ces éléments appliquent le fournisseur d’application par rapport à un rôle d’application.

• 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 d’application, en transférant la propriété de l’objet d’un rôle d’application à un autre, utilisez la commande GRANT OWNERSHIP .

• 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 une virgule.

  Cependant, seuls les privilèges détenus et pouvant être attribués par le rôle d’application exécutant la commande GRANT sont réellement attribués au rôle cible. Un message d’avertissement est renvoyé pour tout privilège qui n’a pas pu être accordé.

• Les privilèges accordés à un rôle d’application particulier sont automatiquement hérités par tous les autres rôles d’application auxquels le rôle d’application est accordé, ainsi que tous les autres rôles d’application 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.

• 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’applique 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 mises en zone de préparation externes et internes, référez-vous à CREATE STAGE et Exigences en matière de contrôle d’accès (dans cette rubrique).

• 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 et des procédures stockées qui ont le même nom dans un schéma. Pour plus d’informations, reportez-vous à Surcharge de procédures et de fonctions.

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

• Cette commande ne peut être exécutée qu’à partir de l’application.

• Les privilèges ne peuvent être accordés ou révoqués que sur des objets appartenant à l’application. Pour déterminer ces objets, utilisez la commande SHOW OBJECTS :

  SHOW OBJECTS OWNED BY APPLICATION myapp;
  

  Copy

• À propos des schémas d’accès gérés :

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

    Les rôles suivants peuvent attribuer des privilèges sur des objets d’un schéma d’accès géré :

    • Le rôle d’application, car ce rôle est le propriétaire du schéma (c’est-à-dire le rôle ayant le privilège OWNERSHIP sur le schéma).

    • Un rôle qui hérite du rôle d’application.

    • Un rôle doté du privilège global MANAGE GRANTS peut attribuer des privilèges sur les objets du schéma.

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

  • Reportez-vous à Futures autorisations sur des objets de schéma (dans cette rubrique) pour connaître les exigences en matière de contrôle d’accès des futures attributions dans les schémas d’accès gérés.

Futures autorisations sur des objets de schéma¶

Les remarques de ces sections s’appliquent lors de l’affectation d’autorisations futures à des objets d’un schéma (c’est-à-dire lorsque vous utilisez les mots clés ON FUTURE).

Exemple¶

Accordez le privilège SELECT sur une vue à un rôle d’application :

GRANT SELECT ON VIEW data.views.credit_usage
  TO APPLICATION ROLE app_snowflake_credits;