I've recently enabled the CI feature on dbt Cloud. Their documentation mentions that
Once the PR is closed, dbt Cloud will delete the temporary schema.
But it seems like these schemas aren't actually deleting once I've closed the PR.
Anyone know what's happening here?
Does your dbt executing user on snowflake (Example snowflake_dbt) have all permissions for all schemas on that DB?
I'd start by checking something like the following and then check for what privileges are enabled for all schemas on that database:
SHOW GRANTS TO USER <dbt_user>
SHOW GRANTS OF ROLE <dbt_service_role>
SHOW GRANTS ON SCHEMA <ci_schema>
SHOW GRANTS ON DATABASE <ci_database>
Reminder, dbt is creating the schema on the fly so pre-existing schema privileges won't apply. This is a privilege that will have to be given to all schemas on that database for either that user or role.
Related
I'm experiencing a strange behavior in Snowflake and couldn't find any explanation in the documentation.
use role accountadmin ;
use database some_database;
create schema test_schema;
drop schema test_schema;
Result:
SQL access control error: Insufficient privileges to operate on schema 'TEST_SCHEMA'
When I check the schemas with show schemas I find that the ownership of TEST_SCHEMA belongs to another role.
Snowflake documentation only says that the ownership of an object is set to the role which created it, and the only way to have it owned by another role is transfer of ownership.
I've tried granting usage on future schema to accountadmin, but it hasn't fixed the problem.
Any ideas?
The database probably has future grants set up on it that automatically assigns ownership of each new schema created
As part of our development lifecycle we clone our prod databases to replace our dev databases, the next step is to apply the correct privileges to the newly cloned databases as our devs need full access to the dev environment whilst they shouldn't have write access to the prod environment.
So I have a requirement to change the owner of all objects in the dev databases to allow the devs to replace and update existing tables, views, procs etc. I have so far been unable to find how to achieve this.
After cloning the database, transfer ownership to another role using the GRANT OWNERSHIP (see also example) function using COPY CURRENT GRANTS clause, for example:
GRANT OWNERSHIP ON DATABASE mydb TO ROLE developer COPY CURRENT GRANTS;
GRANT OWNERSHIP ON ALL SCHEMAS IN DATABASE mydb TO ROLE developer COPY CURRENT GRANTS;
GRANT OWNERSHIP ON ALL TABLES IN DATABASE mydb TO ROLE developer COPY CURRENT GRANTS;
GRANT OWNERSHIP ON ALL VIEWS IN DATABASE mydb TO ROLE developer COPY CURRENT GRANTS;
To me the statement
GRANT OWNERSHIP ON ALL SCHEMAS IN DATABASE my_clone_db TO ROLE developer COPY CURRENT GRANTS;
executes but returns
Statement executed successfully. 0 objects affected.
even though the database has many schemas in it.
Only GRANT OWNERSHIP ON SCHEMA my_clone_db.schema_name TO ROLE developer COPY CURRENT GRANTS; seems to work but then I am back to the problem of having to execute multiple statements, one per schema.
#the_rusteiner
That is probably because the role you are running the GRANT as is not the owner of the schema. You can either do:
USE ROLE <owner_role>;
and try again or execute the GRANT OWNERSHIP as SECURITYADMIN role.
While exploring Snowflake documentation on Audit Logging (user login history, object creation/deletion, query execution history etc), I found the below information.
But in my trail account, I didn't find any shared DB with name 'SNOWFLAKE'.
Would apreciate if someone can throw more light on this feature.
Neeraj
You need to choose the 'ACCOUNTADMIN' role in the context of your session to see that database.
You should set the ACCOUNTADMIN role in the context to access the SNOWFLAKE database.
Alternatively, As accountadmin, you can grant the privilege for viewing the data to other users as below.
Grant imported privileges on database snowflake to ; -- where is an existing/new role granted to
Changing the role in right upper corner is not sufficient. Yo uneed to change the role in the context.
After that, 'SNOWFLAKE' shared DB will be visible.
I am trying the below query against SNOWFLAKE.INFORMATION_SCHEMA from account admin but it returning an error.
Query:
Select
'databases' as category,
count(*) as found,
'3' as expected
from SNOWFLAKE.INFORMATION_SCHEMA.DATABASES
where DATABASE_NAME IN ('USDA_NUTRIENT_STDREF','LIBRARY_CARD_CATALOG','SOCIAL_MEDIA_FLOODGATES')
Error:
SQL compilation error: Database 'SNOWFLAKE' does not exist or not authorized.
Checked SNOWFLAKE database exists but it does not have any schema including INFORMATION_SCHEMA
Databases live under your account. Account is the top level object in the Snowflake object hierarchy. Databases live under account. See this link, and find the text where it says, "The top-most container is the customer account...". It's got a nice little graphic there.
When you query information_schema on the Snowflake database, you're getting the information_schema of just the snowflake database, not of your entire account. Snowflake.information_schema is kinda useless b/c it just shows the information schema of a database (Snowflake) that you have no control over - Snowflake controls it.
If you want to see all the databases in your account, you can do the following:
use role accountadmin;
show databases;
select count(*) from table(result_scan(last_query_id())) where "name" in ('USDA_NUTRIENT_STDREF','LIBRARY_CARD_CATALOG','SOCIAL_MEDIA_FLOODGATES');
Now, separately, if you're concerned about the error you're getting - that you don't have access to the snowflake database, then I'd say you're either not using the accountadmin role, or you're not using a role that has the right privileges. If you'd like to give a role privileges to the Snowlfake database, you can run the following:
GRANT IMPORTED PRIVILEGES
ON DATABASE SNOWFLAKE TO ROLE {SOME_ROLE_OF_YOURS};
Good luck!
I would like to create a role that would have permissions to clone any database, present and future.
Something like
GRANT CREATE DATABASE ON ACCOUNT TO ROLE CLONE_ADMIN;
Followed by
GRANT USAGE ON FUTURE DATABASES TO ROLE CLONE_ADMIN;
Is it possible?
Future grants can only be applied to schema objects.
From the documentation"When a database is cloned, the schemas in the cloned database copy the future privileges from the source schemas. This maintains consistency with the regular object grants, in which the grants of the source object (i.e. database) are not copied to the clone, but the grants on all the children objects (i.e. schemas in the database) are copied to the clones."
Future grants cannot be applied to databases.
USE ROLE ACCOUNTADMIN;
USE DATABASE ANALYTICS;
CREATE OR REPLACE ROLE DATA;
GRANT USAGE ON DATABASE ANALYTICS TO DATA;
GRANT CREATE DATABASE ON ACCOUNT TO ROLE DATA;
GRANT ROLE DATA TO USER NEW_USER1;
USE ROLE DATA;
CREATE DATABASE Z_NEW_USER1_TEST CLONE ANALYTICS;
The feature of future grant at database level is in the roadmap. It is currently in private preview with selected customers to gather feedback from early users.
Stay tune from update from Snowflake when this feature will become accessible to wider audience.