I need to structure the roles in snowflake and need advise for it.
Currently, there are two databases: basedb and computedb. basedb is the database where we load the data and the data is not transformed. more like a landing zone.
computedb is where the transformation happens and there are dozens of functional teams and each would have a schema like content team has content schema and there could a schema which can be shared across multiple teams.
all the teams/ schema inside computedb can read from basedb but there are teams that are reading from transform schema of other teams and that is where I need assistance.
all custom roles are under sysadmin and we have a read and write role per schema.
Now analytics schema wants to read from sales and marketing schema as well.
should just give the read access of sales and marketing to analytics? like shown in picture (issue is that the teams might need to access more schemas in future from other schemas in transform)
or should we create a new role for all the schema in computedb which needs access to other schemas of computedb?
Open to more suggestions.
A role hierarchy is the easiest to build and maintain, whilst giving you flexibility.
Create role(s) that give you the required access to each schema.
Create a role for each team and assign to it the appropriate roles to give them access to the schemas they need
Related
With the ability to allow secondary roles, is it a good practice to separate roles with 'usage' permissions on data warehouse compute from other roles which provide access to databases, schemas. tables? As example, I create a role called 'USE_DEV_DW". This role is granted usage to the DEV data warehouse compute. In parallel, I create a role that has usage on a specific set of databases and schemas. I then grant both roles to a user so that they can query the provided database tables using the separately provided compute (data warehouse). This way I can control what compute users have access to separate from what objects they can query. I don't see this being possible without the ability to provide for secondary roles? Looking to see if others have done something like this.
Even though there is no guidelines from Snowflake how to create the roles, the way you described makes sense.
When you have two layers of roles, let's call them database and functional,
it will be easier to create role hierarchies and assign them to users.
For illustration purposes assuming you have DEVELOPERS and ANALYSTS as your groups and you have SALES and PRODUCTS databases
You can create your roles and role hierarchies like this
Database Roles
R_DB_SALES_READ_WRITE
R_DB_SALES_READ
R_DB_PRODUCTS_READ_WRITE
R_DB_PRODUCTS_READ
Functional Roles
R_DEVELOPER
R_ANALYSTS
Role Hiercharchy
R_DEVELOPER
R_DB_SALES_READ_WRITE
R_DB_PRODUCTS_READ_WRITE
R_ANALYSTS
R_DB_SALES_READ
R_DB_PRODUCTS_READ
With this you only need to assign functional roles to users
I am looking for your suggestions on Snowflake Role based Access control hierarchy which I created for a Snowflake data warehousing project.
Basically, we need to maintain different client data with different databases. This database creation process is automated with a script including create databases(DEV, QA and PROD), roles etc.. for a specific client. Here I have created a hierarchy with 3 different default roles for a database.
ADMIN_{ENV}_{CLIENT_ID}
READ_WRITE_{ENV}_{CLIENT_ID}
READ_{ENV}_{CLIENT_ID}
Then I created a set of roles which have access to all databases like..
ADMIN_{ENV}_ALL
READ_WRITE_{ENV}_ALL
READ_{ENV}_ALL
Hope below image illustrates that..
My questions are:
Is this right approach to continue?
When creating database objects, which role should I use? SYSADMIN? For example: for creating database objects in CLIENT_1_DEV_DB database, should I use ADMIN_DEV_CLIENT_1 role or SYSADMIN?
ADMIN_DEV_CLIENT_1 role should be able to create new users and grant the privileges. In that case should I use USERADMIN or SECURITYADMIN? Are there any methods to restrict that to database level?
There is a use case to clone a schema in a database if any issue occurred. In that case How to manage the grants? When we clone a schema, the roles are not retained to the cloned schema. In that case what is the best approach to copy the grants. having another role with MANAGE GRANTS privileges and use that?
Hope you suggestions on these. Thanks
A couple of RBAC approaches articles to help you fine-tune yours:
https://servian.dev/snowflake-role-based-access-control-simplified-41a3ddf34729
https://medium.com/snowflake/a-functional-approach-for-snowflakes-role-based-access-controls-5f0e84e80146
https://www.analytics.today/blog/introducing-snowflake-rbac
I am trying to share my Snowflake Database(default metadata)--> Account_Usage schema --> Query_History table to another managed account (i.e. reader account) but the data is not visible in another account.
is there any way to share the snowflake database without duplicating the data?
I am getting error as Already Imported Database (i.e) SNowflake cannot be shared for Datashare option.
for a Managed account for usage, I Snowflake database and schemas are available but are not able to see the data which is available.
According to the documentation you can't re-share any database that is shared with you:
Shared databases and all the objects in the database cannot be forwarded (i.e. re-shared with other accounts).
Since the Snowflake database is one that is shared to you from Snowflake, this is probably why you're having issues.
If you need to do this your best bet is to create a table and populate it with the data you need from the Snowflake database and share that table instead. Although it is strange that you'd want to share this info with another account.
Your other option would be to create database/schema in your account with views over the account usage data that you want to share, create a role that can access only that, and then provide a user login with that role only to the group needing to do analytics on your data.
I read a write up about database schema.
A SQL Server schema is a container of objects. For example you may have a large enterprise application and then is a good practice to use different schemas for different purposes (e.g. put HR related tables into HR schema, accounting related tables into Accounting schema and so on). A schema can be owned by any user, and the ownership is transferable.
They said: use different schemas for different purposes (e.g. put HR related tables into HR schema, accounting related tables into Accounting schema and so on)
Do they mean create new database for HR and again new database for accounting?
Because when we create a database then a single schema is created so we cannot create multiple schema in single SQL Server database as far I know.
So please tell me how is it possible to create different schemas for different purposes in a single database? Thanks
Purpose of Schema
Schemas in sql server were introduced in sql server 2005, The main purpose was to eliminate User's ownership of objects in sql server. or you can say to separate users from objects in sql server.
Prior to Sql server 2005 objects in sql server (Tables, views, Store proceders etc) were owned by users. Typically the user who created it.
And that user had to give permissions to other users to use that particular object.
Imagine a scenario where 12 developers are working in a company and all developers are creating sql objects left, right centre. Now all the developers had to give permissions to other 11 developers if they had to work objects created by that one developer. quite a bit of mess isnt it??
Since sql server 2005 came with Schema. All the objects were Owned by a Schema Not a User. if you havent created any custom schema it will be under default Schema dbo.
Now anyone who has permission to dbo schema has permission to any object under dbo schema.
Why it is a good idea to create different schemas for different departments in your case. It may be because HR people doesnt need to know anything about Finance stuff. so you can create a HR schema and give HR people permission only on HR schema. and vice versa with finance people. That will restrict their access to only objects related to their departments.
And we can create multiple Schemas in one database if you have ever worked with Adventureworks database, it has Schemas like 'Production', 'Sales' etc etc.
Read here to learn more about schemas in sql server.
No they mean create a schema. Create schema works within a database. There are all sorts of uses for it, I tend to think of it as either namespacing or a more natural way of partitioning a smallish database and keeping role based access, where you can think of schema as a user group.
Unfortunately, there are two meanings to the word "schema" in the database world.
One means the overall design of the database tables. "Show me your database schema", for example. This would be the collection of "create table" commands, or and ERD diagram.
The other is a synonym for "namespace", which the article in question is referring to. You can store tables, functions etc in different namespaces to ease cognitive load or use for security grouping.
Consider a database server whose job today is to house one database. Likely the database will be moved in the future to another database instance which houses multiple databases & schemas.
Let's pretend the app/project is called Invoicer 2.0. The database is called AcmeInvoice. The database holds all the invoice, customer, and product information. Here's a diagram of the actors and their roles and behaviour.
The schema(s) will largely be used to easily assign permissions to roles. The added benefit here is that the objects aren't under dbo, and that the objects & permissions can be ported to another machine in the future.
Question
What conventions do you use when naming the schema?
Is it good form to name the schema the same as the database?
I would think that if your schema name ends up being the same as your database schema, then you are just adding redundancy to your database. Find objects in your database that have common scope or purpose and create a schema to relect that scope. So for example if you have an entity for Invoices, and you have some supporting lookup tables for invoice states, etc, then put them all in an invoice schema.
As a generally rule of thumb, I would try to avoid using a name that reflects the application name, database name or other concrete/physical things because they can change, and find a name that conceptually represents the scope of your objects that will go into the schema.
Your comment states that "the schemas will largely be used to easily assign permissions to roles". Your diagram shows specific user types having access to some/all tables or some/all stored procs. I think trying to organize objects conceptually into schemas and organize them from a security standpoint into schemas are conflicting things. I am in favour of creating roles in sql server to reflect the types of users, and grant those roles access to the specific objects that each user type needs, as apposed to granting the role or user access the schema to build your security framework..
Why would you name the schema the same as the database? This means all database objects fall under the same schema. If this is the case, why have a schema at all?
Typically schema's are used to group objects within a common scope of activity or function. For example, given what you've described, you might have an Invoice schema, a Customer schema and a Product schema. All Invoice related objects would go into the Invoice schema, all Customer related objects would go into the Customer schema, and the same for Products.
We often will use a Common schema as well which includes objects that might be common to our entire application.
I would call the database AcmeInvoice (or another suitable name) and the schema Invoicer2.
My reasons are as follows: Acmeinvoice means I am grouping all of that applications objects/data together. It can therefore be moved as one unit to other machines (a backup/restore or unattach/attach).
The schema would be Invoicer2. Applications change, maybe in the future you will have Invoicer21 (you would create a schema), or perhaps a reporting module or system (Reports schema).
I find that the use of schemas allows me to separate data/procedures in one database into different groups which make it easier to adminster permissions.