Support Privilege Grants to Roles and Groups in Materialization#626
Support Privilege Grants to Roles and Groups in Materialization#626soksamnanglim wants to merge 51 commits intodbt-labs:mainfrom
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.
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.
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.
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.
@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.
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.
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?
Co-authored-by: Colin Rogers <111200756+colin-rogers-dbt@users.noreply.github.com>
|
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 rSo 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.
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) %} |
| return grants_dict | ||
|
|
||
| @available | ||
| def diff_of_two_nested_dicts(self, dict_a, dict_b): |
|
|
||
| # grant-related methods | ||
| @available | ||
| def standardize_grants_dict(self, grants_table): |
| {% macro redshift__get_show_grant_sql(relation) %} | ||
| {# ------- DCL STATEMENT TEMPLATES ------- #} | ||
|
|
||
| {%- macro redshift__get_grant_sql(relation, privilege, grantee_dict) -%} |
| {%- endfor -%} | ||
| {%- endmacro -%} | ||
|
|
||
| {%- macro redshift__get_revoke_sql(relation, privilege, revokee_dict) -%} |
| 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.
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.
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 dbt-labs/dbt-adapters#647
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_grantdid 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