Can we hide tables from users upon creation in Snowflake?
Can we setup an access control rule using wildcards on table names? Ex: revoke access to users if table name like '%ETL_TRANSIT%'?
OR
When creating a table/view, do we have an option to choose "not visible to users"?
You will first have to be using a different role to create the tables than the role that will be viewing the tables. I would recommend reviewing the Role-based Access Controls in the documentation: Role Hierarchy and Privilege Inheritance
I'm going to use SYSADMIN as the role that creates objects, and a create a new role for viewing called VIEWER just as an example. If you have SYSADMIN access you can test this out yourself:
USE ROLE sysadmin;
CREATE OR REPLACE DATABASE demo_db; -- creating a new db just for demo purposes
CREATE OR REPLACE SCHEMA demo_schema;
USE ROLE securityadmin; -- Use the securityadmin or useradmin to create and manage roles
CREATE ROLE viewer;
GRANT ROLE viewer TO ROLE sysadmin;
-- Now go check out the Roles page in Snowsight under Admin --> Users & Roles
-- You should see viewer underneath sysadmin
USE ROLE viewer; -- You will see nothing because you don't have access to anything
USE ROLE securityadmin;
GRANT USAGE ON WAREHOUSE compute_wh TO ROLE viewer; -- viewer needs a WH to access data
GRANT USAGE ON DATABASE demo_db TO ROLE viewer;
GRANT USAGE ON SCHEMA demo_db.demo_schema TO ROLE viewer;
USE ROLE viewer; -- You will see the db and the schema now
-- Follow this for each new table you create:
USE ROLE sysadmin;
CREATE OR REPLACE TABLE demo_db.demo_schema.demo_tbl (col INT);
USE ROLE viewer; -- You will not see the new table
USE ROLE securityadmin;
GRANT SELECT ON demo_db.demo_schema.demo_tbl TO ROLE viewer;
USE ROLE viewer; -- You will now see the new table and be able to query it
Do NOT grant SELECT on FUTURE TABLES or FUTURE VIEWS in a schema though. IF you do that, the Viewer role will automatically see new tables as you create them. You will want to grant SELECT one at a time based on your requirements.
This is an answer to your second requirement. You could build out a Stored Procedure that could GRANT based on a like, but it would be a highly custom option that would need to run on a schedule or triggered manually.
Unless you have future grants in place or a role is inheriting the role used to create the table, most roles do not automatically gain access to tables created by other roles. You would need to explicitly grant them permissions on the new table (and the table's associated schema/database) in order for the table to be "visible" to the role.
Related
how to perform joins and how to maintain warehouse?
I have tried:
create table table_name values i int, nm string;
How to create a role in snowflake without any privileges or minimum privileges ?
I tried to create a role with parent role security-admin .
when I assign this role to user i am able to see databases of parent role also.
After I created role with parent role as public still I am able to see databases
what shall I do that a created role should not have access to any unless I grant it ?
When you CREATE ROLE, it's an independent object and does not come with any privileges:
use role accountadmin;
create role empty_role;
show grants to role empty_role;
The last command does not return anything even if it is created by the accountadmin role.
grant role empty_role to user gokhan;
use role empty_role;
show databases;
As the new role has no additional access, the last command shows the databases which the PUBLIC role has access. I hope this explains why you see some databases when you switch to your new role.
I have granted USAGE on the schemas and database.
I have granted select on all tables.
Using that role, I can read data from all tables within any schema.
I then grant the permission to create tables in all schemas within that database
GRANT CREATE TABLE ON ALL SCHEMAS IN DATABASE TEST1_CONTROL TO DEVELOPERS;
Yet, when I issue this command (while using DEVELOPERS role), I get an error
CREATE TABLE PDS.ERIC_TEST_TABLE(COUCOU STRING NULL);
What am I missing?
Works fine for me (script below). Going to go with what Lukasz commented and that your schema was created later.
use role accountadmin;
create database TEST1_CONTROL;
create schema PDS;
create role DEVELOPERS;
grant role DEVELOPERS to user <your_username>;
GRANT USAGE ON DATABASE TEST1_CONTROL TO DEVELOPERS;
GRANT USAGE ON ALL SCHEMAS IN DATABASE TEST1_CONTROL TO DEVELOPERS;
GRANT CREATE TABLE ON ALL SCHEMAS IN DATABASE TEST1_CONTROL TO DEVELOPERS;
use role DEVELOPERS;
CREATE TABLE PDS.ERIC_TEST_TABLE(COUCOU STRING NULL);
Snowflake does offer future grants if you want a role to have access to any new schemas that would be created in the future.
I'm gIven the problem:
Write a script that creates a user-defined role named VendorMaintenance in the AP database. Give update permissions to that role on the Vendors table and Select permission on the Invoice and InvoiceLineItems table. Assign the VendorMaintenance role to dbMaster.
I've looked through my textbook and came up with this incorrect solution.
USE AP
GO
CREATE SERVER ROLE VendorMaintenance
GO
GRANT UPDATE
ON Vendors
TO VendorMaintenance
GO
GRANT SELECT
ON Invoices
TO VendorMaintenance
GO
GRANT SELECT
ON InvoiceLineItems
TO VendorMaintenance
GO
ALTER SERVER ROLE VendorMaintenance ADD MEMBER dbMaster
GO
It says that VendorMaintenance isn't a user, and its not. but I need to grant these permissions to the role and then assign users to that role. Also is there a better way to write this?
For a user-defined database role, the syntax is as below. The role will be created in the current database context.
USE AP;
GO
CREATE ROLE VendorMaintenance;
GO
CREATE SERVER ROLE creates a user-defined server role, which is used to grant server-scoped permissions rather than permissions on database-scoped objects.
CREATE OR REPLACE DATABASE "Orders";
I did not set any permissions on this database. Another person at my company ran the SQL above and replaced the data. How can I prevent this from happening in the future using the permissions in Snowflake?
TL;DR: The global privilege CREATE DATABASE in Snowflake permits a user/role to run such a statement. Removing it requires designing a role based access system and revoking administrative level rights from existing users.
At the very minimum, severely restrict the users who are allowed to run statements as ACCOUNTADMIN, SECURITYADMIN or SYSADMIN roles. Revoke these privileges from the set of users you want to prevent from performing DATABASE level operations:
REVOKE accountadmin FROM USER other_user1;
REVOKE securityadmin FROM USER other_user1;
REVOKE sysadmin FROM USER other_user1;
REVOKE accountadmin FROM USER other_user2;
REVOKE securityadmin FROM USER other_user2;
REVOKE sysadmin FROM USER other_user2;
(… repeat for all users that need to be limited …)
Next, design custom roles and define a desired level of accesses over them. Also decide which usernames will belong to each role depending on their function in your organization.
The following is a very generic and basic example just for illustrative purposes that divides all "Orders" database users into two levels of access. Specific needs will vary depending on your organization's unique situation.
CREATE ROLE orders_read_and_write;
CREATE ROLE orders_read_only;
-- Snowflake recommends you create a hierarchy of roles so you can allow any
-- SYSADMIN-allowed users to manage these newly created roles instead of
-- requiring an ACCOUNTADMIN level user to do so in future
GRANT ROLE orders_read_and_write TO ROLE sysadmin;
GRANT ROLE orders_read_only TO ROLE sysadmin;
The two roles orders_read_and_write and orders_read_only created above can then be granted privileges appropriately to control their level of access for schema and tables under the "Orders" database. Continuing the example:
-- Allow both these roles to access schema and tables under "Orders" DB
-- This does not allow them to perform any DB-level operations
-- such as replacing/overwriting it
GRANT USAGE ON DATABASE "Orders" TO ROLE orders_read_and_write;
GRANT USAGE ON DATABASE "Orders" TO ROLE orders_read_only;
-- Allow read and write access appropriately to schema under the DB
-- Note the difference on using ALL vs. USAGE in the privilege granted
-- to each role here:
GRANT ALL ON SCHEMA "Orders"."SCHEMA-NAME" TO ROLE orders_read_and_write;
GRANT USAGE ON SCHEMA "Orders"."SCHEMA-NAME" TO ROLE orders_read_only;
GRANT SELECT
ON ALL TABLES IN SCHEMA "Orders"."SCHEMA-NAME"
TO ROLE orders_read_only;
Finally, grant the roles to their respective username(s).
GRANT ROLE orders_read_and_write TO USER other_user_1;
GRANT ROLE orders_read_only TO USER other_user_2;
(…)
Any role lacking the CREATE DATABASE level privilege will no longer be able to perform a statement such as CREATE OR REPLACE DATABASE "Orders";.
In the above example, both roles only receive USAGE level access on the Orders database, which does not permit them to run such statements anymore.
If you ever need to permit such a privilege to a role, you can GRANT it explicitly to the role of choice that has trusted users under it:
GRANT CREATE DATABASE TO ROLE role_name;
I highly recommend going over Snowflake's Access Controls feature section a few times to get acclimated to the terminology. This makes it easier to implement and manage effective access controls in your organization.
Note: Introducing access control is a wide-impacting change and will require communication and coordination within your organization to be truly effective. It is always difficult to remove freedoms as this may be ingrained into scripts and programs already in use.
Using SQL Server (2008), is it possible to grant a specific user full control of the objects under a specific schema? This includes create/drop/alert table. Its important that this user isn't not given db_ddladmin role because that would give him access to other tables.
You can create a role in the database, assign all appropriate permissions(SELECT, UPDATE, DELETE, EXECUTE, etc.) to the role, and then assign the user to that role.