-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[CT-1346] [Feature] Extend grants config to include usage grants #6063
Comments
I can see why granting usage on the database/schema would be very helpful (especially for blanket configs on sub-directories) but I don't think warehouse usage should be tied into it. Our best practices align with the transformers having their own warehouse while users accessing the objects downstream like a BI service user have their own. Also, the concept of a warehouse and permissions on that level are adapter specific (i.e Snowflake only at this point) |
Hi there, let me shine some light on this from a customer's point of view. We are on BigQuery and we have the need to secure data access on individual user level. So we have different data marts (schemas) where we do The result is... nothing. Because users cannot connect until we give them a schema-level role. In our point of view, as DBT creates the schemas it is also responsible for granting roles to them. We now fall back to an
This then results in too wide access for all users, because they can connect and view the structure of all data marts (schemas) including the ones they cannot query. |
@stevenkoppenol My curiosity is should this be ran at every dbt run or should there actually be a separate project/higher level to manage this? Because roles to me should only be granted once rather than continuously versus usage which might need to be granted multiple times due to the object being dropped. To me, db management can 100% be in the dbt project but the granularity is unclear to me on how things should be applied because there are some things that only need to be run once or twice. |
Well, every run there is a chance of (a) a new data mart appearing as a result of a branch being merged to main or (b) manually assigned permissions that need to be revoked (exceptional, I admit). So in my view it should run every time, comparing "as is" to "to be" and applying changes as needed. |
@AlexFrid Thanks for opening, and kicking off the disucssion! I agree that this is functionality we should look to add, and I also agree with this statement:
IMO Check out the discussion over in #5781, which includes some concept art for what a |
This issue has been marked as Stale because it has been open for 180 days with no activity. If you would like the issue to remain open, please comment on the issue or else it will be closed in 7 days. |
Although we are closing this issue as stale, it's not gone forever. Issues can be reopened if there is renewed community interest. Just add a comment to notify the maintainers. |
Is this your first time submitting a feature request?
Describe the feature
#5189 and #5263 introduced grants as node configs.
This feature request seeks to extend the grants config to include usage grants as well.
Currently, we can do this:
The extended version could look very similar:
or
Describe alternatives you've considered
The current recommended way of doing usage grants is by using on-run-end
Example:
A similar approach is also in the dbt labs partner engineering team demos)
Who will this benefit?
This will benefit the same people who appreciate grants as node configs and push the envelope further in terms of how dbt can enable people to configure grants.
As select grants are often used in conjunction with usage grants, this will allow people to consolidate their workflow to fully use the grants config for standard things, instead of having it fragmented between the grants config for select grants and on-run-end for usage grants.
The dbt labs partner engineering team noticed that this would be useful as we updated our demos and enablement recommendations to use the grants config, but couldn't fully replace our current macro since we are using usage grants.
@ernestoongaro has also noticed people asking about this.
Are you interested in contributing this feature?
Yes
Anything else?
No response
The text was updated successfully, but these errors were encountered: