I am creating a user that should only have access to the database tables metadata,via INFORMATION_SCHEMA, and not the table data. So no perms to query the tables directly. The role the user will be a member of will have USAGE privileges on INFORMATION_SCHEMA schema. I tested the user with that role and it is only able to see tables within public and no where else.
I did see in Snowflake documentation:
"The output of a view or table function depend on the privileges granted to the user’s current role. When querying an INFORMATION_SCHEMA view or table function, only objects for which the current role has been granted access privileges are returned."
So, I tried to grant to the role MONITOR and USAGE on other schemas; but, that did not work either. Only when I granted a role with read access to all the tables in the schema was it able to see and query from INFORMATION_SCHEMA.TABLES the tables in that schema. This, however, is not what I want as now that user would be able to query data from the tables. I just want to set that user to be able to query and gather the metadata of tables and not allow data access. Is there a way in Snowflake to setup and perform this type of setup?
I believe the only way to do this would be to provide access to the SNOWFLAKE.ACCOUNT_USAGE share on Snowflake, which also has TABLES and would allow this user to query the metadata of all tables and columns in that Snowflake account. There is a lot more information available in that share, but at least the user would not have access to any real data, if that is what you are after.
Related
In SnowFlake, I want to provide access kind ofddl_admin in sql server to a user or role who can drop any tables in schema regardless anybody else is the owner of the table.
There is no concept of having a super role in Snowflake. Everything has to go by access hierarchy.
However, if all the roles are granted to ACCOUNTADMIN role then no matter which user creates the table, that can be dropped by ACCOUNTADMIN.
Apologies for the new question, but I am having trouble understanding the best practices for understanding the recommended role set up for my account. I am auditing what I have created to backwards engineer and correct it on a new warehouse.
So here is the situation:
I granted all permissions on all warehouses modify AND usage to the sysadmin.
When running worksheets and ./snowsql in parallel, I used the ACCOUNTADMIN for all of the sessions in snowsql.
When I use the Sysadmin to modify the tables that copied the data staged in the warehouse sometimes I have permissions and other times I don't.
I have been sifting through account history with the ACCOUNTADMIN role to view all the grants with the recommended query from the documentation below:
select *
from table(information_schema.query_history())
order by start_time;
I filtered then by the database and query_id to include grant
select *
from table(information_schema.query_history())
where database_name = 'temp_db'
and query_id like '%grant%'
order by start_time;
I did this to see if there were any differences in the grants I did between databases in the warehouse. I only set up two warehouses so it was easy to see.
Going forward, Accountadmin is used to create roles, warehouses, and databases.
To prevent the need to do an audit when switching between roles, I want to set future grants on Sysadmin to specific databases in a warehouse for modification and usage, how do I do that?
Permissions to warehouses, database, and all other objects are separate things. Granting permissions to a warehouse let's that role use or modify a warehouse, but that has nothing at all to do with creating, updating, etc. other objects like databases, schemas, tables, and views. Also, only the role that OWNS a table can drop or alter a table. So, you might want to check on the ownership of the tables between SYSADMIN and ACCOUNTADMIN. As a best practice, ACCOUNTADMIN shouldn't own anything.
It would take quite a bit more information to give you a full rundown of RBAC in Snowflake. If you are struggling with it, you might want to contact Professional Services at Snowflake and get them to come in and do an overview (QuickStart or Security package) to get you straightened out.
I am new to Snowflake. Is it possible to query Information schema views for eg, SCHEMATA, TABLES, COLUMNS for all tables in a snowflake Db without having select access to the underlying tables. The requirement is to create a user/account that only has access to query metadata of the snowflake Db and should not have a select access to the table data. Please advise.
From the Snowflake documentation:
"The output of a view or table function depends on the privileges
granted to the user’s current role. When querying an
INFORMATION_SCHEMA view or table function, only objects for which the
current role has been granted access privileges are returned."
In other words, you won't see the metadata for objects you do not have access to when you query the INFORMATION_SCHEMA views.
To workaround, you can use a role like ACCOUNTADMIN that has permissions to all tables and populate a new table with results from the desired INFORMATION_SCHEMA views. Then give your new role access to that table. You may be able to even setup a task in Snowflake to regularly update the table.
References:
https://docs.snowflake.net/manuals/sql-reference/info-schema.html#general-usage-notes
https://docs.snowflake.net/manuals/user-guide/tasks.html#executing-sql-statements-on-a-schedule-using-tasks
I believe you won't see the object in information schema views. So you required privileges to access the object.
The views in INFORMATION_SCHEMA display metadata about objects defined in the database, as well as metadata for non-database, account-level objects that are common across all databases.
There are 17 views available under INFORMATION_SCHEMA that holds information of Database level objects.
There are 8 views that holds information of Account level objects.
INFORMATION_SCHEMA is a read-only schema available automatically under each database. It stores metadata of all Snowflake objects built under the database.
Running Queries on INFORMATION_SCHEMA requires warehouse to be up and running which incurs Snowflake credits.
The output of a view or table function depend on the privileges granted to the user’s current role. When querying an INFORMATION_SCHEMA view or table function, only objects for which the current role has been granted access privileges are returned.
To use a database's information schema all you need is usage privilege on that database. The role in turn will only see content from the information schema that he/she has access to.
I am new to SQL Server database and I am struggling to figure out the access issue for one of the user on a particular view. I don't want to expose any of my base tables.
The scenario is: I have 3 databases, DB one, two and three
Database one has 2 base tables
Database two has one view on top of those tables (tables in database one)
Database three has one view which is on top of the view of database two
Database three is our data warehouse. So, I would like to know if I give select permission on only database three's view, will that suffice?
The catch is I don't want to expose any of my base tables in database one
If I grant select permission to user1 on datawarehouse view (view in database three) and deny all the permissions to the base tables (in database 1), then is it possible?
Thanks
Ownership chaining allows access to data via the view without permissions on the underlying tables as long as all objects are owned by the same security principal. There is no need for an explicit GRANT or DENY on the indirectly used objects with an unbroken ownership chain since permissions are checked only on the directly access view. The object owner is typically inherited from the schema owner.
To allow ownership chaining to extend across multiple database:
The DB_CHAINING database option must be ON for the databases involved.
The user must be able to use the databases (have a user account in each database with CONNECT permissions), although only permissions on directly accessed objects are needed.
In the case of dbo-owned objects, the databases must be owned by the same login (AUTHORIZATION) since the dbo schema owner is the database owner. For other schemas, the schema owner must map to the same login.
DB_CHAINING should be enabled only when you fully trust highly-privileged users (those with permissions to create database objects).
In Oracle,
- I want to ensure that owner of trigger must match table owner.
- Also the views should be restricted. The user must not be able to query system views and tables.
Generally only the owner of a table will have privileges to create triggers on it. DBAs may have the privilege CREATE ANY TRIGGER, but protecting a database from a DBA is whole different order of question.
There are a number of system views (eg USER_TABLES, ALL_USERS) which you can't revoke access on, but they will only reveal what the user has been granted access to. Again the DBA will have access to views prefixed DBA_ and 'views' prefixed V$ (which are a bit odd in that they show operational information about the database and not data that is stored on disk anywhere) and tables owned by SYS.
What exactly is it that you want to accomplish?
Normally, we create roles that give access to only the application tables and views.
The owner of the application grants privileges to those roles and
the roles are granted to your users.
As long as the owner of the tables only has the regular 'create xxx' privileges, there is not much to worry for. Normally we need access to some system tables and views.
What data do you want to hide? Most of the views don't reveal more than already is known by the application.
Don't give 'xxxx ANY' privileges to anyone. Most of the time when those privs are requested it is because of laziness. They are rarely needed.
Ronald.