The only way I can get dbt run to work is by connecting as an accountadmin (bad). Any other role gives me "insufficient privileges on table xxx" when executing dbt models. I am using DBT cloud connecting to snowflake. I have created the following with a role that I wanted to use, but it seems that my grants do not work, to allow running my models with this new role.
my dbt cloud "dev" target profile connects as dbt_user, and creates objects in analytics.dbt_ddumas
Below is my grant script, run by an accountadmin:
There must be an easier way than this below, which is not even working :(
Dave
use role accountadmin;
CREATE ROLE dbt_role
GRANT ROLE dbt_role TO ROLE sysadmin
GRANT USAGE ON WAREHOUSE transform_wh TO ROLE dbt_role
GRANT ALL ON database analytics TO ROLE dbt_role
grant ALL ON ALL schemas in database analytics to role dbt_role;
grant ALL ON future schemas in database analytics to role dbt_role;
grant ALL ON ALL tables in SCHEMA analytics.dbt_ddumas to role dbt_role;
grant ALL ON future tables in SCHEMA analytics.dbt_ddumas to role dbt_role;
grant ALL ON ALL views in SCHEMA analytics.dbt_ddumas to role dbt_role;
grant ALL ON future views in SCHEMA analytics.dbt_ddumas to role dbt_role;
CREATE USER dbt_user PASSWORD = 'Password123' MUST_CHANGE_PASSWORD = FALSE;
GRANT ROLE dbt_role TO USER dbt_user;
For anyone who is new to DBT with snowflake, here is what you need to do to setup a dbt role to run models, test, etc with dbt run, dbt test, etc
After much frustration, and a willingness to save others the pain I went through...
This is for a lower environment . Ex dev or test
Step 0: Login as an accountadmin, or have an accountadmin do this:
Step 1: create a warehouse . Ex. transform_wh
Step 2: create a database Ex. Analytics
Run this below, substituting the proper password for dbt_user:
NOTE: DO NOT CREATE ANY SCHEMAS AS ACCOUNTADMIN. That was my main problem, so do not make that mistake. The reply from the user who replied to this message did not know that, and his reply would work also. The dbt_loader_dev role will do this as you execute dbt_run. If you do, dbt_loader_dev will get "insufficient privileges" errors when trying to create schemas, tables, and views.
USE ROLE accountadmin;
-- this role is used to load all models in the dev (lower environments) when you do a dbt run, dbt test, etc
CREATE ROLE dbt_loader_dev;
-- custom roles should be granted to sysadmin
grant ROLE dbt_loader_dev TO ROLE sysadmin;
-- these grant are all you need to run so that dbt_loader_dev can do all that it needs to for any dbt run, dbt test, etc
GRANT USAGE ON WAREHOUSE transform_wh TO ROLE dbt_loader_dev;
GRANT all ON database analytics TO ROLE dbt_loader_dev;
GRANT usage ON ALL SCHEMAS IN DATABASE analytics TO dbt_loader_dev;
GRANT usage ON future SCHEMAS IN DATABASE analytics TO dbt_loader_dev;
GRANT Monitor ON ALL SCHEMAS IN database analytics TO dbt_loader_dev;
GRANT Monitor ON future SCHEMAS IN database analytics TO dbt_loader_dev;
GRANT MODIFY ON ALL SCHEMAS IN DATABASE analytics TO dbt_loader_dev;
GRANT MODIFY ON future SCHEMAs IN DATABASE analytics TO dbt_loader_dev;
-- create a user and grant the role
CREATE USER dbt_user PASSWORD = 'Password123' MUST_CHANGE_PASSWORD = FALSE;
GRANT ROLE dbt_loader_dev TO USER dbt_user;
That's it! Enjoy!
Dave (edited)
I recommend following the excellent article by Claire on the dbt Discourse that covers this exact topic.
It would be helpful to know exactly what table, schema, or database you are unable to read from. You say my dbt cloud "dev" target profile connects as dbt_user, and creates objects in analytics.dbt_ddumas, but what databases and schemas is it reading from? (Where are your sources located)? Most of your grants will be oriented to reading existing data, since dbt Cloud will create your dbt_ddumas schema, and therefore own it and every other relation that it creates.
Assuming your raw data is located in a database called raw, then I would change your script to:
use role accountadmin;
CREATE ROLE dbt_role
GRANT ROLE dbt_role TO ROLE sysadmin
GRANT USAGE ON WAREHOUSE transform_wh TO ROLE dbt_role
grant usage on database raw to role dbt_role;
grant usage on future schemas in database raw to role dbt_role;
grant select on future tables in database raw to role dbt_role;
grant select on future views in database raw to role dbt_role;
grant usage on all schemas in database raw to role dbt_role;
grant select on all tables in database raw to role dbt_role;
grant select on all views in database raw to role dbt_role;
grant usage ON database analytics TO ROLE dbt_role;
grant create schema ON database analytics TO ROLE dbt_role;
CREATE USER dbt_user PASSWORD = 'Password123' MUST_CHANGE_PASSWORD = FALSE;
GRANT ROLE dbt_role TO USER dbt_user;
Related
I have a requirement where I need to revoke users access on a particular schema as we will be purging that schema and its table in future.
Currently, the process followed to create Schema and grant access is like below,
Create Schema
Create DB Role
Create Azure AD Group on azure portal
Create DB User with the same name as AD group
Then, we run EXEC sp_addrolemember command to add DB user to DB role in database.
Finally, we run the Grant command to give permission (Select, Insert etc) on Schema to DB Role.
Now, whenever any new user need access to that schema we simply add him in the Azure AD group and he is able to see and access that schema.
However, when I Revoke the access of user by removing him from Azure AD group he is still able to see that Schema.
As I am not an expert in SQL so I am not sure what am I missing in order to revoke his access.
I also tried Revoke command like below but still the user is able to see the schema.
REVOKE SELECT ON SCHEMA :: Schema_Name TO [DB Role]
Am I missing anything, can anyone please let me know the right steps to revoke user access so that they should not be able to see that schema anymore or should not be able to run any command on that schema not even select command?
Then, in addition to remove it from the AD group, try to deny permissions on the schema:
DENY SELECT,VIEW DEFINITION On SCHEMA::Schema_Name To [user_name]
In my Snowflake database, I have a reporting ROLE requesting access to a subset of SCHEMAS owned by a subset of schema OWNERS. This is a valid request as I can see it reduces the schema clutter in their query interface.
Is it possible in Snowflake to grant privileges on ALL schemas owned by a certain role (Ex: abc_role) to another role (Ex: xyz_role)?
I see in Snowflake we can grant privileges on ALL schemas in the entire database but not restrict by the schema owner.
You’ll need to construct the commands yourself, there is no WHERE option in a grant statement.
Just run
show schemas;
and then construct your grant statements with
select — construct statement
from table(result_scan(last_query_id()))
where “owner” = value;
I am trying to grant usage on future stored procedures within a particular schema.
I am using the role SYSADMIN and the schema is owned by SYSADMIN.
The following statement works
GRANT USAGE ON ALL PROCEDURES IN SCHEMA UAT_CONTROL.PDS TO ROLE UAT_OPERATIONS;
While this one fails
GRANT USAGE ON FUTURE PROCEDURES IN SCHEMA UAT_CONTROL.PDS TO ROLE UAT_OPERATIONS;
"SQL Error [3001] [42501]: SQL access control error: Insufficient
privileges to operate on schema 'PDS'
Am I missing a trick?
Just wanted to provide the answer in case someone was looking for it in this forum. The MANAGE GRANTS privilege is required for future grants:
https://docs.snowflake.com/en/user-guide/security-access-control-configure.html#security-privileges-required-to-manage-future-grants
You also have to grant usage on your database and maybe on your schema:
GRANT USAGE ON DATABASE UAT_CONTROL TO ROLE UAT_OPERATIONS;
GRANT USAGE ON SCHEMA PDS TO ROLE UAT_OPERATIONS;
More infos here: https://docs.snowflake.com/en/sql-reference/sql/grant-privilege.html
I am trying to setup a new role for making the access rights granting easier. I was wondering if there is an easier way to give select on all tables (newly created tables should be accessible automatically) under a schema to selected users. I ran following queries for the same. But still my user is not able to access the specific table.
CREATE ROLE myrole;
GRANT SELECT ON myschema.mytable TO myrole;
GRANT usage ON schema myschema TO myrole;
CREATE USER mytest1 identified BY '***';
GRANT myrole TO mytest1;
After this, when I login with mytest1 user and trying to run select on myschema.mytable it is asking me to grant usage on schema to user. After I grant usage on schema to user directly it is failing with permission denied for that table.
Please help with the same. I am running on vertica 5.0
Update:
I find that u also have to make that role default or explicitely set that role as default for user session for making the role's effect take place.
ALTER USER mytest1 DEFAULT ROLE myrole;
But still, my another question of how to make all tables under a schema accessible to specific users remains.
As per the Vertica SQL Reference Manual.pdf (page 725) (doc version 5.0 - for page numbers)
GRANT (Schema)
...
USAGE
Allows the user access to the objects contained within the
schema. This allows the user to look up objects within the
schema. Note that the user must also be granted access to the
individual objects. See the GRANT TABLE (page 727) ... .
The the user must also be granted access to the individual objects means that you need to also GRANT table.
The two I use is GRANT SELECT and GRANT REFERENCES which allows the user to run queries and join (reference) tables in the query.
Example:
GRANT SELECT ON TABLE [schema].[Table1] TO myUser;
GRANT SELECT ON TABLE [schema].[Table2] TO myUser;
GRANT REFERENCES ON TABLE [schema].[Table1] TO myUser;
GRANT REFERENCES ON TABLE [schema].[Table2] TO myUser;
...
6.0 doc reference GRANT SCHEMA (page 808) and GRANT TABLE (page 813).
Does the following command effectively give the user, "MyUser," permission to execute ALL stored procedures in the database?
GRANT EXECUTE TO [MyDomain\MyUser]
SQL Server 2008 and Above:
/* CREATE A NEW ROLE */
CREATE ROLE db_executor
/* GRANT EXECUTE TO THE ROLE */
GRANT EXECUTE TO db_executor
For just a user (not a role):
USE [DBName]
GO
GRANT EXECUTE TO [user]
SQL Server 2005 introduced the ability to grant database execute permissions to a database principle, as you've described:
GRANT EXECUTE TO [MyDomain\MyUser]
That will grant permission at the database scope, which implicitly includes all stored procedures in all schemas. This means that you don't have to explicitly grant permissions per stored procedure.
You can also restrict by granting schema execute permissions if you want to be more granular:
GRANT EXECUTE ON SCHEMA ::dbo TO [MyDomain\MyUser]
In addition to the answers above, I'd like to add:
You might want to grant this to a role instead, and then assign the role to the user(s).
Suppose you have created a role myAppRights via
CREATE ROLE [myAppRights]
then you can give execute rights via
GRANT EXECUTE TO [myAppRights]
to that role.
Or, if you want to do it on schema level:
GRANT EXECUTE ON SCHEMA ::dbo TO [myAppRights]
also works (in this example, the role myAppRights will have execute rights on all elements of schema dbo afterwards).
This way, you only have to do it once and can assign/revoke all related application rights easily to/from a user if you need to change that later on - especially useful if you want to create more complex access profiles.
Note: If you grant a role to a schema, that affects also elements you will have created later - this might be beneficial or not depending on the design you intended, so keep that in mind.