Avec un compte Snowflake facilement utilisable et une compréhension limitée de ses rôles définis par le système, il devient généralement difficile pour un chef d’équipe ou un administrateur de configurer les environnements avec des contrôles d’accès appropriés pour ses développeurs ou utilisateurs.
Pour commencer avec la configuration du compte, vous auriez d’abord besoin d’un utilisateur disposant d’un accès au rôle ACCOUNTADMIN pour le compte Snowflake. Cela peut être fourni par un utilisateur disposant d’un accès au compte ORGADMIN Snowflake.
Ceci est compris par l’exemple ci-dessous :
Une organisation a un compte Snowflake à l’échelle de l’organisation et est gérée par ORGADMIN.
ORGADMIN peut créer plusieurs comptes sous la même organisation dans Snowflake, qui peuvent être gérés séparément par différentes équipes au sein de l’organisation.
Avant de commencer à créer des utilisateurs, des rôles, des entrepôts, des bases de données, etc., vous devez d’abord comprendre les rôles définis par le système ci-dessous dans Snowflake et ce que Snowflake recommande comme meilleure pratique lors de la configuration du compte.
Rôles définis par le système
UTILISATEUR ADMIN :
- La première partie du processus de création de compte consiste à créer des utilisateurs et des rôles au sein d’un compte.
- L’objectif des rôles USERADMIN est la création d’utilisateurs et de rôles. Ce rôle est accordé avec les privilèges de sécurité CREATE USER et CREATE ROLE.
ADMIN SECURITE :
- Un rôle est incomplet sans aucun octroi, et le rôle SECURITYADMIN est uniquement utilisé pour l’octroi.
- Tout ce qui concerne les subventions dans Snowflake est entièrement géré par le rôle SECURITYADMIN.
- Une fois les utilisateurs et les rôles créés par USERADMIN, vous pouvez utiliser SECURITYADMIN pour accorder aux utilisateurs les rôles appropriés.
- Vous pouvez accorder des entrepôts, des bases de données, des schémas, des objets d’intégration et un accès pour créer des tables, des étapes, des vues, etc., à un rôle à l’aide du rôle SECURITYADMIN.
- Le rôle SECURITYADMIN hérite des privilèges du rôle USERADMIN via la hiérarchie des rôles système.
- Notez que Snowflake n’a pas le concept de groupes d’utilisateurs. Au lieu de cela, les utilisateurs sont créés et les rôles nécessaires sont accordés à l’utilisateur.
SYSADMIN :
- SYSADMIN crée les objets tels que les bases de données, les entrepôts, les schémas, etc., dans un compte.
- Bien qu’il crée des objets tels que des bases de données, des entrepôts, etc., il n’accorde pas l’accès à ces objets aux rôles. C’est fait par SECURITYADMIN.
ADMIN COMPTE :
- Le rôle ACCOUNTADMIN encapsule les rôles définis par le système SYSADMIN et SECURITYADMIN. Il s’agit du rôle de niveau supérieur dans le système et ne doit être accordé qu’à un nombre limité/contrôlé d’utilisateurs de votre compte.
- En dehors de cela, ACCOUNTADMIN n’a accès qu’aux objets CREATE INTEGRATION dans Snowflake.
- En tant que meilleure pratique, activez les utilisateurs avec des rôles ACCOUNTADMIN doivent avoir MFA activé.
ORGADMIN :
- Ce rôle est principalement utilisé pour créer des comptes au sein d’une organisation.
- Chaque compte agit comme une entité distincte et aura ses propres bases de données, entrepôts et autres objets.
- PUBLIC:
Comme son nom l’indique, ce rôle est accessible à tous les autres utilisateurs d’un compte. - Les objets créés dans le cadre d’un rôle PUBLIC sont accessibles à tous et utilisés lorsqu’il n’est pas nécessaire de contrôler l’accès aux objets, et peuvent être partagés dans le compte.
- Généralement, il n’est pas recommandé d’utiliser ce rôle à des fins de production.
Créer un compte avec un exemple
Comme il est maintenant clair ce que chaque rôle défini par le système est censé faire dans Snowflake, voyons quelques exemples de base de la configuration d’un compte en les utilisant.
En supposant que vous vous êtes connecté en utilisant un utilisateur ayant un accès ACCOUNTADMIN, voyons ci-dessous le cas d’utilisation :
- Il y a quatre utilisateurs nommés : meghna, adnan, kaushik et shushant
- meghna et adnan font partie d’une équipe d’analyse qui crée des rapports à l’aide d’outils de création de rapports. Par conséquent, ils n’ont besoin que de l’accès en lecture pour les objets créés.
- kaushik et shushant font partie de l’équipe d’ingénierie des données et construisent des pipelines pour charger les données dans les bases de données Snowflake. Comme il s’agit d’un environnement de développement, ils auront un accès en lecture et en écriture aux objets créés.
Alors, utilisons les noms d’utilisateur comme prénoms : meghna, adnan, kaushik, shushant
Puisqu’ils travaillent dans un projet d’analyse et un environnement de développement, nous pouvons créer deux rôles :
- Un pour lire nommé ROLE_DEV_ANALYTICS_RO
- Un pour l’accès en lecture/écriture nommé ROLE_DEV_ANALYTICS_RW
Pas:
Tout d’abord, comme indiqué, créons les utilisateurs à l’aide de USERADMIN rôle.
use role USERADMIN;
– Create the roles
create role ROLE_DEV_ANALYTICS_RO;
create role ROLE_DEV_ANALYTICS_RW;
– create the users
create user meghna password='abc123' default_role = ROLE_DEV_ANALYTICS_RO default_secondary_roles = ('ALL') must_change_password = true;
create user adnan password='abc123' default_role = ROLE_DEV_ANALYTICS_RO default_secondary_roles = ('ALL') must_change_password = true;
create user kaushik password='abc123' default_role = ROLE_DEV_ANALYTICS_RW default_secondary_roles = ('ALL') must_change_password = true;
create user shushant password='abc123' default_role = ROLE_DEV_ANALYTICS_RW default_secondary_roles = ('ALL') must_change_password = true;Notez que les quatre utilisateurs sont créés en utilisant le même mot de passe avec l’argument must_change_password = truece qui les forcera à changer les mots de passe lors de la première connexion.
Utiliser SECURITYADMIN pour accorder aux utilisateurs leurs rôles respectifs :
use role SECURITYADMIN;
– Grant the Roles created to SYSADMIN
grant role ROLE_DEV_ANALYTICS_RO to role SYSADMIN;
grant role ROLE_DEV_ANALYTICS_RW to role SYSADMIN;Ceci est fait pour que les objets tels que les tables, les étapes, les vues, etc., créés à l’aide des rôles soient accessibles par SYSADMIN aussi. Si celui-ci n’est pas accordé, SYSADMIN ne serait pas en mesure d’accéder ou de gérer les objets créés par ces rôles.
use role SECURITYADMIN;
– Grant the users to the roles
grant ROLE ROLE_DEV_ANALYTICS_RO to user meghna;
grant ROLE ROLE_DEV_ANALYTICS_RO to user adnan;
grant ROLE ROLE_DEV_ANALYTICS_RW to user kaushik;
grant ROLE ROLE_DEV_ANALYTICS_RW to user shushant;Utilisons maintenant SYSADMIN pour créer l’entrepôt, les bases de données, les schémas, etc.
use role SYSADMIN;
-- Create database and schemas
create database analytics_dev;
create schema analytics_dev.analytics_master;
create schema analytics_dev.analytics_summary;
-- Create warehouse
create warehouse analytics_small with
warehouse_size="SMALL"
warehouse_type="STANDARD"
auto_suspend = 60
auto_resume = TRUE ;Le SQL ci-dessus crée un petit entrepôt qui peut s’arrêter en 60 secondes d’inactivité et reprendre automatiquement chaque fois que des requêtes sont déclenchées.
Maintenant que la base de données, le schéma et l’entrepôt sont prêts, il est temps d’accorder aux rôles les accès nécessaires à l’aide de SECURITYADMIN.
Supposons que seules les tables et les vues sont utilisées pour ce projet.
use role SECURITYADMIN;
– Granting the usage access to ROLE_DEV_ANALYTICS_RO
grant usage on database analytics_dev to role ROLE_DEV_ANALYTICS_RO;
grant usage on all schemas in database analytics_dev to role ROLE_DEV_ANALYTICS_RO;
grant select on future tables in database analytics_dev to role ROLE_DEV_ANALYTICS_RO;
grant select on all tables in database analytics_dev to role ROLE_DEV_ANALYTICS_RO;
grant select on future views in database analytics_dev to role ROLE_DEV_ANALYTICS_RO;
grant select on all views in database analytics_dev to role ROLE_DEV_ANALYTICS_RO;
– Granting the usage access to ROLE_DEV_ANALYTICS_RW
grant usage on database analytics_dev to role ROLE_DEV_ANALYTICS_RW;
grant usage on all schemas in database analytics_dev to role ROLE_DEV_ANALYTICS_RW;
grant select on future tables in database analytics_dev to role ROLE_DEV_ANALYTICS_RW;
grant select on all tables in database analytics_dev to role ROLE_DEV_ANALYTICS_RW;
grant select on future views in database analytics_dev to role ROLE_DEV_ANALYTICS_RW;
grant select on all views in database analytics_dev to role ROLE_DEV_ANALYTICS_RW;
grant create table on schema analytics_dev.analytics_master to role ROLE_DEV_ANALYTICS_RW;
grant create view on schema analytics_dev.analytics_master to role ROLE_DEV_ANALYTICS_RW;
grant create table on schema analytics_dev.analytics_summary to role ROLE_DEV_ANALYTICS_RW;
grant create view on schema analytics_dev.analytics_summary to role ROLE_DEV_ANALYTICS_RW;Comme vu ci-dessus, ROLE_DEV_ANALYTICS_RO a obtenu un accès en lecture seule et ROLE_DEV_ANALYTICS_RW dispose d’un accès en lecture et en écriture.
Enfin, accordons l’entrepôt aux rôles.
use role SECURITYADMIN;
grant USAGE , OPERATE on warehouse analytics_small to role ROLE_DEV_ANALYTICS_RO;
grant USAGE , OPERATE on warehouse analytics_small to role ROLE_DEV_ANALYTICS_RW;Les utilisateurs disposant des autorisations appropriées devraient désormais pouvoir se connecter à Snowflake et ne devraient pouvoir utiliser que les rôles associés aux autorisations appropriées.