I want to create a role on snowflake limited only to one database and one schema and give there a read access on all tables.
I create a role, grant:
grant usage on database1,
grant usage on database1.schema1,
grat select on all tables in database1.schema1,
and I grant usage and operate on one warehouse1.
However, additionally to this I am seeing also other databases and other schemas with this role, despite no grants were added, also there is additional warehouse to warehouse1.
How I can limit access with this role and not see something that appear as default
'databases' even for roles with no grants?
Regards
P
You will be able to find out what the role can and cannot do.
Check the which users and/or roles are granted the privilege of the role:
show grants of role ;
Then check what privileges were given to the role:
show grants to role ;
All the users are granted the PUBLIC role. Hence, never grant any privileges to the PUBLIC role, as this simply means giving the whole world access to a database, schema and tables/views etc.
Related
I created a new Database (DB_COMMON) using ACCOUNTADMIN role and I grant ALL PRIVILEGES to other roles but I am not able to see newly created Database (DB_COMMON) using those roles. Am I missing something? Please guide.
Here is the complete code:
USE DATABASE ACCOUNTADMIN;
-- DATABASE CREATION
CREATE DATABASE IF NOT EXISTS DB_COMMON;
-- PERMISSION TO ALL THE FUTURE SCHEMAS
GRANT ALL PRIVILEGES ON FUTURE SCHEMAS IN DATABASE DB_COMMON TO ROLE DEVADMIN;
GRANT ALL PRIVILEGES ON FUTURE SCHEMAS IN DATABASE DB_COMMON TO ROLE QAADMIN;
GRANT ALL PRIVILEGES ON FUTURE SCHEMAS IN DATABASE DB_COMMON TO ROLE UATADMIN;
GRANT ALL PRIVILEGES ON FUTURE SCHEMAS IN DATABASE DB_COMMON TO ROLE PRODADMIN;
-- PERMISSION TO ALL THE FUTURE TABLES
GRANT ALL PRIVILEGES ON FUTURE TABLES IN DATABASE DB_COMMON TO ROLE DEVADMIN;
GRANT ALL PRIVILEGES ON FUTURE TABLES IN DATABASE DB_COMMON TO ROLE QAADMIN;
GRANT ALL PRIVILEGES ON FUTURE TABLES IN DATABASE DB_COMMON TO ROLE UATADMIN;
GRANT ALL PRIVILEGES ON FUTURE TABLES IN DATABASE DB_COMMON TO ROLE PRODADMIN;
-- CREATION OF SCHEMA
USE DATABASE DB_COMMON;
CREATE SCHEMA IF NOT EXISTS COMMON;
After these commands, if I switch to these roles (DEVADMIN, QAADMIN, etc) I am not able to see DB_COMMON Database. Am I missing something? Please guide.
It is not recommeded to use ACCOUNTADMIN role as owner of user-defined databases:
Avoid Using the ACCOUNTADMIN Role to Create Objects:
The ACCOUNTADMIN role is intended for performing initial setup tasks in the system and managing account-level objects and tasks on a day-to-day basis. As such, it should not be used to create objects in your account, unless you absolutely need these objects to have the highest level of secure access. If you create objects with the ACCOUNTADMIN role and you want users to have access to these objects, you must explicitly grant privileges on the objects to the roles for these users.
Instead, we recommend creating a hierarchy of roles aligned with business functions in your organization and ultimately assigning these roles to the SYSADMIN role. For more information, see Aligning Object Access with Business Functions in this topic.
Second the USAGE permission on the database needs to be granted.
GRANT USAGE ON DATABASE ... TO ROLE ...;
Database Privileges:
USAGE
Enables using a database, including returning the database details in the SHOW DATABASES command output. Additional privileges are required to view or take actions on objects in a database.
I need information within Snowflake which captures "Role to Privilege mapping".
Example :: If I am an user "USER_01" & I have the role as "ANALYST", then this "ANALYST" role has access to which all the objects (database/schema/table/etc..) in Snowflake account I would need that information.
Any pointers like queries/metadata tables/etc.. would help as there has to be some metadata tables which would keep this role to privilege mapping.
For e.g., queries like :
show grants to user USER_01
--> This gives what role has been assigned to this user. But this do not convey any information regarding what all privileges has been given to that role. Like if this role has got below access:
grant usage on database DB_01 to role analyst;
grant all privileges on schema schema_01 to role analyst;
grant all privileges on all tables in schema schema_01 to role analyst;
SHOW GRANTS:
SHOW GRANTS TO ROLE <role_name>
Key point: Access Control Framework
Role-based Access Control (RBAC): Access privileges are assigned to roles, which are in turn assigned to users.
Access priviliges are not assigned directly to users.
If you want to list all the privileges given to a user, you may use the stored procedure described in this KB article:
https://community.snowflake.com/s/article/How-to-Capture-Snowflake-Users-Roles-and-Grants-Into-a-Table
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.
I've set up the following scenario:
The Demo_DB is owned by the sysadmin role. The Demo_Schema was created and is owned by Demo_Developer role. All the objects in Demo_Schema are owned and have been created by the Demo_Developer role.
AccountAdmin created a new role called Demo_Analyst, which the intent is to set up as a read-only user of the Demo_Schema tables. Demo_Developer successfully executed the following grant (assuming because it is the owner of all the tables in the Demo_Schema):
use role Demo_Developer;
grant select on all tables in schema Demo_DB.Demo_Schema to role Demo_Analyst;
However, neither Demo_Developer or event SysAdmin (which belongs to the Demo_Developer role) can execute the following:
use role sysadmin;
grant select on FUTURE tables in schema Demo_DB.Demo_Schema to role Demo_Analyst;
However, the above will execute using the AccountAdmin role. This seemed strange to me at first, but then I reasoned that maybe we won't know which future tables will be created by which owners, so we need an AccountAdmin to grant FUTURE. Is that correct?
I did some more testing and changed ownership of one of the tables in Demo_Schema to a completely different role that Demo_Developer isn't a part of. Then I tried to grant select on all tables using that Demo_Developer again (first statement above), and this time it didn't grant to all tables, but just to the tables Demo_Developer was the owner of.
So I wonder why the attempted grant on FUTURE tables doesn't work the same way - i.e. grant select on future tables owned by the grantor of the future grant.
So my question is: Why do I need an AccountAdmin to grant select on Future tables, but I can use the owner role (Demo_Developer) to grant select on all current tables?
Did you see this in the usage notes?
The MANAGE GRANTS global privilege is required to grant or revoke privileges on future objects at the database level. By default, only the SECURITYADMIN and ACCOUNTADMIN roles have the MANAGE GRANTS privilege.
Fundamentally I want
my "DBA" user; the original account which has the SYSADMIN and ACCOUNTADMIN roles, to be able to see any object in the database as well as its data. It seems that at least at the level of ACCOUNTADMIN I should be able to do this.
a "power" user; via a role (dr_uce_role) I can assign at a database level where the user can do virtually everything within a database.
I thought I had made the power user role with the following code:
--grant power to engineer
grant all privileges on database dr_ev to dr_uce_role;
grant all privileges on all schemas in database dr_ev to dr_uce_role;
grant all privileges on all tables in schema dr_ev.public to dr_uce_role;
grant all privileges on all views in schema dr_ev.public to dr_uce_role;
grant select on future tables in schema dr_ev.public to dr_uce_role;
grant select on future views in schema dr_ev.public to dr_uce_role;
grant all privileges on all tables in schema dr_ev.stg to dr_uce_role;
grant all privileges on all views in schema dr_ev.stg to dr_uce_role;
grant select on future tables in schema dr_ev.stg to dr_uce_role;
grant select on future views in schema dr_ev.stg to dr_uce_role;
This user then created objects in the schemas. However my "DBA" user at SYSADMIN could not see the objects at all. With role ACCOUNTADMIN the user can see the objects, but not query them. My understanding is that ACCOUNTADMIN is the top level account, and can take ownership of these objects anyway, so if this is supposed to be a security feature I don't really understand how it is providing much protection as it can always steal ownership?
I tried changing ownership of an object as ACCOUNTADMIN to SYSADMIN, to find it had a blocking privilege;
grant ownership on dr_ev.stg.load_opportunity to sysadmin;
SQL execution error: Dependent grant of privilege 'DELETE' on securable 'DR_EV.STG.LOAD_OPPORTUNITY' to role 'DR_UCE_ROLE' exists. It must be revoked first. More than one dependent grant may exist: use 'SHOW GRANTS' command to view them. To revoke all dependent grants while transferring object ownership, use convenience command 'GRANT OWNERSHIP ON TO REVOKE CURRENT GRANTS'.`
I tried taking ownership with
grant ownership on all tables in schema dr_ev.stg to sysadmin revoke current grants;
which did work - although it left my power user unable to see the objects. So I granted them back with
grant all privileges on all tables in schema dr_ev.stg to dr_uce_role;
However I want my power user to be able to create or replace this table. I believe this requires the DROP TABLE privilege, although apparently my power user grants do not provide it, and I am unclear on how I should be providing it?
I will not say I have the greatest understanding of Snowflake privileges and am wondering if the statements above like grant all privileges on all tables in schema do not live at the schema level to blanket apply to all tables, but actually sets object level permissions and my original approach has simply been too granular as I do not actually wish to manage anything at object level. That being said, I am unclear in the doc how to manage at a higher level than object anyway if the statement is actually just a shortcut to set many object privileges. How can I accomplish my original goals?
The best practice for a situation like this is to grant all of your custom roles to the SYSADMIN role. This allows the sysadmin to do everything a SYSADMIN can do plus everything that all of the other roles can do. You have a lot of questions in your post, but I think this resolves many of them.
The way I did was to create a super role 'superole' and granted sysadmin, securityadmin and accountadmin to that role. I then attached the superrole to whoever I wanted to be my DBA...