Replies: 1 comment 1 reply
-
The current 3-tier role hierarchy was designed specifically with long term maintainability in mind. We had a few hundred "live" users and dozens of "script" users with permissions being adjusted all the time. Some permissions were generated and adjusted dynamically. We also had to pass a strict external audit. Any kind of multi-nested hierarchy in this environment would be very difficult to maintain. In theory, the repetition should not be a big issue with the current setup:
Based on your picture, the setup could be relatively simple. business_roles: loader_raw_db:
schema_owner:
- raw_db.*
loader_another_db:
schema_owner:
- another_db.* users: airbyte_loader:
...
business_roles:
- loader_raw_db
- loader_another_db One final note about tech roles. Normally you only need tech roles to grant access to very limited number of objects. For example, you have a user with very restricted access, which should only have access to a few tables. Tech roles should generally not be used for majority of grants, since it is too verbose and becomes hard to manage when number of objects grows. Schema roles and warehouse roles should cover 95% of typical use cases. |
Beta Was this translation helpful? Give feedback.
-
I'm in the process of migrating my Snowflake IaC repo from Terraform --> SnowDDL, and I had originally planned out a pretty deep hierarchy of role inheritance. For example, suppose we had a
loader
business role which is a member of araw_db_admin
role. Thatraw_db_admin
role might also be a member of araw_db_reader
andraw_db_writer
role. And those reader and writer roles might be members of all the individual [SnowDDL-generated] schema read and write tech rolesIs this type of deep inheritance supported by the tool? It seems to me that only one level of inheritance in manually configured roles in supported (business roles can inherit from tech roles). But what if I want tech roles to inherit from other tech roles as a means of abstracting out commonly re-used sets of grants?
On one hand, I can see the benefit of avoiding deep role inheritance structures. I am coming from a Terraform deploy, and one issue was that it was challenging to actually traverse the configuration and get a good grasp on which grants a given user role actually had due to all the nested role memberships defined. On the other hand, it seems like maintainability is going to be a challenge in SnowDDL if I have to repeatedly grant business roles access to low level tech roles, when those tech roles could potentially be encapsulated into higher level abstractions for easier re-use
For reference, here's a little screenshot of an example role inheritance structure I had diagrammed out prior to starting my SnowDDL implementation. The red boxes are manually configured roles, and the green auto-generated tech roles. User roles not pictured here. This was before I really got into it and realized this might not be feasible. Am I thinking about the intended usage of this tool wrong?
Looking forward to hearing others' thoughts on this!
Beta Was this translation helpful? Give feedback.
All reactions