Wanted to confirm if it is not possible to create a schema from a share.
I see from the documentation that once a share (from a schema not the entire database) is created/enabled by the provider account,I/the consumer account can only leverage the share by creating a new database.
I/Consumer already have a snowflake database & would like to just point the schema from the provider that is enabled as share to a new schema on my side in the existing database. This avoids the need to maintain multiple databases.
Br,
Noor.
It is not possible.
In consumer side, the ff. command is used to consume a share:
CREATE DATABASE <name> FROM SHARE <provider_account>.<share_name>;
Hence, consumption can only be done in database level. This effectively creates a read-only database (unlike regular/local databases), all of its objects are controlled by the provider.
Additionally, IMPORTED PRIVILEGES is used to grant roles in consumer side access on shared database. Cannot grant this privilege on a Schema.
Related
I am looking for your suggestions on Snowflake Role based Access control hierarchy which I created for a Snowflake data warehousing project.
Basically, we need to maintain different client data with different databases. This database creation process is automated with a script including create databases(DEV, QA and PROD), roles etc.. for a specific client. Here I have created a hierarchy with 3 different default roles for a database.
ADMIN_{ENV}_{CLIENT_ID}
READ_WRITE_{ENV}_{CLIENT_ID}
READ_{ENV}_{CLIENT_ID}
Then I created a set of roles which have access to all databases like..
ADMIN_{ENV}_ALL
READ_WRITE_{ENV}_ALL
READ_{ENV}_ALL
Hope below image illustrates that..
My questions are:
Is this right approach to continue?
When creating database objects, which role should I use? SYSADMIN? For example: for creating database objects in CLIENT_1_DEV_DB database, should I use ADMIN_DEV_CLIENT_1 role or SYSADMIN?
ADMIN_DEV_CLIENT_1 role should be able to create new users and grant the privileges. In that case should I use USERADMIN or SECURITYADMIN? Are there any methods to restrict that to database level?
There is a use case to clone a schema in a database if any issue occurred. In that case How to manage the grants? When we clone a schema, the roles are not retained to the cloned schema. In that case what is the best approach to copy the grants. having another role with MANAGE GRANTS privileges and use that?
Hope you suggestions on these. Thanks
A couple of RBAC approaches articles to help you fine-tune yours:
https://servian.dev/snowflake-role-based-access-control-simplified-41a3ddf34729
https://medium.com/snowflake/a-functional-approach-for-snowflakes-role-based-access-controls-5f0e84e80146
https://www.analytics.today/blog/introducing-snowflake-rbac
I created a share in snowflake and assigned permissions to only a few tables. But they can lookup any table.
What's the problem?
I ran it with the script below.
CREATE SHARE test_share
GRANT USAGE ON DATABASE "DBNAME" TO SHARE test_share
GRANT USAGE ON SCHEMA "DBNAME"."SCHEMANAME" TO SHARE test_share
GRANT SELECT ON TABLE "DBNAME"."SCHEMANAME"."TABLENAME" TO SHARE test_share
ALTER SHARE sparc_poc_share ADD ACCOUNTS=ConsumerName;
If sharing tables from the same database via different shares with the same consumer account, when the consumer creates a database from one of the shares, all shared tables are visible in the imported database. To prevent this from happening, create a separate schema for each table you wish to share.
Details: https://docs.snowflake.com/en/user-guide/data-sharing-provider.html#general-data-sharing-considerations-and-usage
Recommended practice: https://docs.snowflake.com/en/user-guide/data-sharing-secure-views.html#using-secure-objects-to-control-data-access
When using shared databases in Snowflake (as a data consumer), there seems to be no other way to control the access than granting IMPORTED PRIVILEGES on the DB, which effectively grants read-only access to the entire DB and all its schemas & objects.
Is there no way to grant more granular access to the schemas & objects inside a shared database? My goal would be to create roles that have access to only limited portions of the share (specific schemas or objects, like I can with a regular database).
For example, let's say I want to share a database with 10 schemas in it (as a data provider), and would like to restrict/control the access to each of these schemas on the consumer side... would there be no other option than to create 10 shares (one for each schema) on the data provider side? And so on to restrict/control access for specific tables & views?
This is assuming I have access to both accounts (the provider and the consumer), or that I can negotiate the implementation details with the provider/consumer.
Is there no way to grant more granular access to the schemas & objects inside a shared database?
Currently, there is not.
For example, let's say I want to share a database with 10 schemas in it (as a data provider), and would like to restrict/control the access to each of these schemas on the consumer side... would there be no other option than to create 10 shares (one for each schema) on the data provider side? And so on to restrict/control access for specific tables & views?
That's how you would have to do it currently.
Edit: Actually, following up on Robert's answer, if the inbound side of the share is a full account rather than a reader account, you could sort of restrict access by creating a view that filters out rows based on current_role(). It wouldn't be like a privilege, more like row level security based on role.
One approach to this problem is to block access to certain objects in the share for those roles which you don't want to allow access. If your role owns the share then you can block access by revoking privileges on the objects from the share. If your role does not own the share, but owns the objects in the share, you can block access by revoking the USAGE or SELECT privileges with CASCADE on the objects from the share owner.
Alternatively, depending on all the details, it may be easier just to create as many seperate shares as are needed.
I am trying to share my Snowflake Database(default metadata)--> Account_Usage schema --> Query_History table to another managed account (i.e. reader account) but the data is not visible in another account.
is there any way to share the snowflake database without duplicating the data?
I am getting error as Already Imported Database (i.e) SNowflake cannot be shared for Datashare option.
for a Managed account for usage, I Snowflake database and schemas are available but are not able to see the data which is available.
According to the documentation you can't re-share any database that is shared with you:
Shared databases and all the objects in the database cannot be forwarded (i.e. re-shared with other accounts).
Since the Snowflake database is one that is shared to you from Snowflake, this is probably why you're having issues.
If you need to do this your best bet is to create a table and populate it with the data you need from the Snowflake database and share that table instead. Although it is strange that you'd want to share this info with another account.
Your other option would be to create database/schema in your account with views over the account usage data that you want to share, create a role that can access only that, and then provide a user login with that role only to the group needing to do analytics on your data.
In SQL Server 2005, a snapshot of a database can be created that allows read-only access to a database, even when the database is in "recovery pending" mode. One use case for this capability is in creating a reporting database that references a copy of a production database, which is kept current through log-shipping.
In this scenario, how can I implement security on the "snapshot" database that is different from the "production" source database?
For example, in the production database, all access to data is through stored procedures, while in the snapshot database users are allowed to select from table in the database for reporting purposes. The problem the I see is that security for the snapshot database is inherited from the source database, and can not be changed because snapshots are strictly read-only.
Are you able to manage permissions on this database? Would adding a separate user who only has read access to a database be sufficient for this type of scenario? This could be a read-only user on the main database, but is only effectively used on the snapshot db.
i.e. Add a new user, readerMan5000 who is only given select access, to the database in question. Then require users to authenticate through that new credential.
Note to future commenters, you may want to read:
http://www.simple-talk.com/sql/database-administration/sql-server-2005-snapshots/
or
http://msdn.microsoft.com/en-us/library/ms187054(SQL.90).aspx
before you open your big mouth like me. :)
You can't change permissions after you take the snapshot, but here's one workaround: instead of having them access the tables directly, require them to use views instead. If the views are used only for reporting, then you can set tight security on them in the original database, and then have the users hit those views in the snapshot. You'll need to restrict access on the underlying tables though if you want it to be effective.