I'm trying to create a Role hierarchy in Snowflake with a "top level" role which will be used for my helpdesk support team to manage users and resources within Snowflake. But this role cannot have access to any stored data due to compliance restrictions.
For user management, I've just granted SECURITYADMIN to the role and it seems to work pretty well. But for databases I would like to avoid using SYSADMIN as I would be inheriting the ability to view everything in the databases. So I've come up with a hierarchy that I think makes sense, which is basically the following with some added project roles:
ACCOUNTADMIN >--- HELPDESK (create/drop db then hand off to OU_MANAGER)
- OU_MANAGER (create/drop schema/tables and assign grants within the OU) > OU_MEMBER (usage on resources in db)
What I would like to do is create the databases with my HELPDESK role, then grant all on that db to the management role for the organizational unit and hand it off to them.
I'm not sure if this is possible in Snowflake, or if I just have my syntax wrong. But I get an error when I try to run a basic grant create database to role helpdesk, and I can't find anything definitive in the docs about granting this kind of access.
use role accountadmin;
grant create database on account to role helpdesk;
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 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.
Environment: snowflake database.
i am trying to find a way to create a role which have security admin permission but should limit the permission only to specific database. is this doable or not? if so, anyone can help me on this? thanks so much.
Thanks, Alex
SECURITYADMIN is a role created by default in Snowflake and a lot of his permissions are not database-related (for example role and user management). Indeed most of the database-related grants belongs to SYSADMIN role.
So if you want to create a custom role having limited permissions on a specific database. You should list the permission which are database related and grant this permissions to the custom role.
For example if you want to give all privileges to a role on a specific database you can use :
GRANT ALL PRIVILEGES ON DATABASE my_db TO ROLE my_custom_role;
Roles are account-level, not db-level objects. So I am guessing you are trying actually to do the same role mgmt that SECURITYADMIN does, but at db-level. In that case:
use role SECURITYADMIN;
create role SECURITYADMIN_DB1;
grant create user, create role to SECURITYADMIN_DB1;
After that create Access Roles for your db:
https://docs.snowflake.com/en/user-guide/security-access-control-considerations.html#aligning-object-access-with-business-functions
Then assign all access roles to the custom SECURITYADMIN_DB1 role, so your role will manage that particular db only.
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.
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...