I would like a new role which can query snowflake account usage. Currently only Account Admin have this privilege and don’t want to assign Account Admin for required users.
The IMPORTED PRIVILEGES grant would allow a non-admin role access to the SNOWFLAKE.ACCOUNT_USAGE schemas (docs). There is also a MONITOR USAGE global grant which allows similar billing and usage monitoring but through information_schema functions instead. See the documentation here -- particularly the table is helpful to explain the differences between these two options.
These are some of the more common built-in grant options for a billing-monitoring role, but if you need a more custom solution, you can always create some custom SQL (perhaps stored procedure and task for maintenance) that copies only the desired admin results from ACCOUNT_USAGE to a custom table/view. Then you can grant access to that custom object to your non-admins.
Related
I am using the below queries to create a share and add objects to it:
CREATE SHARE IF NOT EXISTS my_db_my_schema_my_table;
GRANT USAGE ON DATABASE my_db TO SHARE my_db_my_schema_my_table;
GRANT USAGE ON SCHEMA my_db.my_schema TO SHARE my_db_my_schema_my_table;
GRANT SELECT ON TABLE my_db.my_schema.my_table TO SHARE my_db_my_schema_my_table;
Now, I am using the below query to add the accounts:
ALTER SHARE my_db_my_schema_my_table ADD ACCOUNTS=AB60942;
This works fine. No errors. Also, I can see in the share details that this account name was added under Full Accounts.
Below are my current role permissions:
However, I am not able to see anything under the other account. What exactly am I missing here?
P.S: I am trying to refrain myself from using accountadmin role.
You must use the ACCOUNTADMIN role (or a role granted the IMPORT SHARES global privilege) to perform these tasks:
Do you see your shares in the available /inbound shares on the consumer account?
show shares;
Have you created a database from the share on the consumer account?
https://docs.snowflake.com/en/user-guide/data-share-consumers.html#creating-a-database-from-a-share
Are your consumer and the main account in the same region? If they are in different regions, follow this document: https://docs.snowflake.com/en/user-guide/secure-data-sharing-across-regions-plaforms.html
I'm trying to restrict read permissions on some entities to a specific user.
In Oracle I'd simply do
GRANT SELECT ON sensitive_schema.my_table1 TO error_2646;
GRANT SELECT ON sensitive_schema.my_table2 TO error_2646;
GRANT SELECT ON sensitive_schema.my_tableN TO error_2646;
or ideally at schema level
GRANT SELECT ON sensitive_schema TO error_2646;
Can I do this in Snowflake? In the documentation it looks like permissions are managed by role in Snowflake and I'd rather not change this person's role.
https://docs.snowflake.com/en/sql-reference/sql/grant-privilege.html
As Snowflake's approch for permission is Role-based Access Control (RBAC) you will not be able to give GRANTS to a specific user.
If you absolutly don't want to work on role for this, maybe you can have a look on Dynamic Data Masking. You will be able to mask data to a specific user using current_user(). But you will have to create a masking policy for every field type you want to mask and apply this policy to every field in your table so i would not recommend this compared to role approach.
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;
I am new to snowflake, As a DBA I got ACCOUNTADMIN access to start with. I have granted read access on information_schema.login_history and information_schema.query_history to our security application user, via a role.
The user is able to login and query above views. However, the account is not able to see all rows when query above views. Only returns login history of that user, query history of that user. I tested it from my end, switching role from ACCOUNTADMIN to the read role I have created, and I see the same thing.
Can anyone tell me what privileges I need to grant the role, so anyone using that role can see all login history?
There are two places where you can see login history -- in the Account Usage view or using the Information Schema table functions. The documentation here explains the differences.
After reviewing the differences, many customers will opt for giving non-admins access to Account_Usage views for auditing purposes. The grants needed for this are mentioned in the documentation here.
However, if you prefer giving the non-admin role access to the Information_Schema login_history table function, you may need to give a MONITOR grant on each desired user to this role as per the article here.
You need to grant monitor privileges to said role:
grant monitor usage on account to role custom;
This information can be accessed/viewed only by account administrators. To enable users who are not account administrators to access/view this information, Snowflake provides the global MONITOR USAGE privilege. Granting the MONITOR USAGE privilege to a role allows all users who are granted the role to access this historical/usage information.
In addition, with this privilege, the SHOW DATABASES and SHOW WAREHOUSES commands return the lists of all databases and warehouses in the account, respectively, regardless of other privilege grants.
Ref: https://docs.snowflake.com/en/user-guide/security-access-control-configure.html#enabling-non-account-administrators-to-monitor-usage-and-billing-history
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.