-
Notifications
You must be signed in to change notification settings - Fork 59
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
Support Privilege Grants to Roles and Groups in Materialization #626
base: main
Are you sure you want to change the base?
Support Privilege Grants to Roles and Groups in Materialization #626
Conversation
Ran all of the integration tests, however the test suite for materialized views fails for me even with no proposed changes. Would love some help on that! Kept getting a Also had to refactor many of the integration tests from |
Need to update CI workflow to include new env vars: https://github.com/dbt-labs/dbt-redshift/blob/main/.github/workflows/integration.yml#L185 |
Hmmm... integration tests for grants are still failing after I updated the CI workflow. |
Failing test:
|
It's the same error that came up also before updating CI workflow. Perhaps, |
"schema.yml": updated_schema, | ||
} | ||
|
||
def test_view_table_grants(self, project, get_test_users, get_test_groups, get_test_roles): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Running locally I see issues with the expected/actual grants (it looks like the actual grants includes a superset of all users). Kind of hard to debug since there are so many test cases in this test. Can we break this up into separate test cases?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi Colin, let me take a look.
The tests that are failing successfully pass in my local environment. Is there a way to set up my local environment to mirror dbt's local + remote testing environment? I follow the contributing guide, but some test results conflict between local and remote environment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remotely, it seems the fixtures are not manifesting even with the fix. https://github.com/dbt-labs/dbt-redshift/actions/runs/6461848915/job/17542365369?pr=626#step:7:275
get_test_users = ['dbt_test_user_1', 'dbt_test_user_2', 'dbt_test_user_3']
get_test_groups = [], get_test_roles = []
Let me try refactoring base_grants to see if that fixes the issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@soksamnanglim took another look at the tests and it looks like they're being invoked twice in some places. Simplified by making the "base" classes standard test classes since they shouldn't need to be inherited
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also confirmed that the roles/groups are setup in our test DB via:
select * from SVV_ROLES;
and select * from pg_group;
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After running revoke SELECT on "database"."schema"."my_model" from dbt_test_user_1, group dbt_test_group_1, role dbt_test_role_1;
, test_model_grants
successfully passes for me.
It seems that the privileges were not revoked properly the first time, but seems like they are automatically revoking fine now.
I'd like to figure out whether the code for automatic revoking/granting has a bug in it or my testing set up for models is incorrect—Can we try manually revoking those privileges from the dbt testing cluster and running the grant test suite multiple times to ensure its behaving deterministically in the dbt environment?
Any updates here? |
Co-authored-by: Colin Rogers <[email protected]>
Looking at the results from the most recent CI tests, there are 3 tests that are not passing:
The failed assertion for each looks identical to me: TestIncrementalGrantsRedshift
actual_grants = {'select': {'group': ['dbt_test_group_1'], 'user': ['dbt_test_user_1']}} TestModelGrantsTableRedshift
actual_grants = {'select': {'group': ['dbt_test_group_1'], 'user': ['dbt_test_user_1']}} TestSnapshotGrantsRedshift
actual_grants = {'select': {'group': ['dbt_test_group_1'], 'user': ['dbt_test_user_1']}} |
I checked that the CI environment has values for all the expected environment variables:
I'm not seeing any changes to Before trying to make changes to |
It looks to me like the logic within select * from svv_roles r So to unblock the CI tests, I manually executed in the following within Redshift: CREATE ROLE dbt_test_role_1;
CREATE ROLE dbt_test_role_2;
CREATE ROLE dbt_test_role_3; |
'role' as grantee_type, | ||
r.role_name as grantee, | ||
p.privilege_type | ||
from svv_roles r |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From pairing with @dbeatty10 - in order to query svv_table_info
, this requires:
- that dbt's user has role
<somerole>
grant access system table to role <somerole>;
References:
|
||
{% endmacro %} | ||
|
||
{% macro redshift__apply_grants(relation, grant_config, should_revoke=True) %} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overriding default__apply_grants
.
return grants_dict | ||
|
||
@available | ||
def diff_of_two_nested_dicts(self, dict_a, dict_b): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of diff_of_two_dicts
.
|
||
# grant-related methods | ||
@available | ||
def standardize_grants_dict(self, grants_table): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overriding standardize_grants_dict
.
{% macro redshift__get_show_grant_sql(relation) %} | ||
{# ------- DCL STATEMENT TEMPLATES ------- #} | ||
|
||
{%- macro redshift__get_grant_sql(relation, privilege, grantee_dict) -%} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overriding default__get_grant_sql
.
{%- endfor -%} | ||
{%- endmacro -%} | ||
|
||
{%- macro redshift__get_revoke_sql(relation, privilege, revokee_dict) -%} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overriding default__get_revoke_sql
.
and tp.table_schema=replace(split_part('{{ relation }}', '.', 2), '"', '') | ||
and tp.table_name=replace(split_part('{{ relation }}', '.', 3), '"', '') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should use Relation
class attributes (like here and here) rather than splitting on dot separators.
and tp.table_schema=replace(split_part('{{ relation }}', '.', 2), '"', '') | |
and tp.table_name=replace(split_part('{{ relation }}', '.', 3), '"', '') | |
and tp.table_schema = '{{ relation.schema }}' | |
and tp.table_name = '{{ relation.identifier }}' |
and rp.namespace_name=replace(split_part('{{ relation }}', '.', 2), '"', '') | ||
and rp.relation_name=replace(split_part('{{ relation }}', '.', 3), '"', '') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should use Relation
class attributes (like here and here) rather than splitting on dot separators.
and rp.namespace_name=replace(split_part('{{ relation }}', '.', 2), '"', '') | |
and rp.relation_name=replace(split_part('{{ relation }}', '.', 3), '"', '') | |
and rp.namespace_name = '{{ relation.schema }}' | |
and rp.relation_name = '{{ relation.identifier }}' |
Any updates here? |
resolves #415
docs: dbt-labs/docs.getdbt.com#4193
Problem
Prior to this PR, users were unable to configure grants to roles and groups via grant config on resource.
A valid workaround existed. Users could prefix their permissions with "group" or "role", which introduced concerns:
get_show_grant
did not query for group or role grants on the table. Expected behavior: grants configured via the workaround would be automatically revoked. Actual behavior: workaround grants remain.Solution
Users may now extend grant configurations to roles and groups like this:
To not break existing dbt projects, dbt users granting privileges to only users may continue configuring grants the following way:
Upon running, dbt will continue to automatically grant and revoke differences in privileges to users, groups, and roles.
Checklist