Skip to content

Commit 388d2d7

Browse files
authored
Update grants to include revocation examples (#6678)
1 parent 4b8b522 commit 388d2d7

File tree

1 file changed

+81
-4
lines changed
  • website/docs/reference/resource-configs

1 file changed

+81
-4
lines changed

website/docs/reference/resource-configs/grants.md

Lines changed: 81 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -11,12 +11,12 @@ The grant resource configs enable you to apply permissions at build time to a sp
1111

1212
dbt aims to use the most efficient approach when updating grants, which varies based on the adapter you're using, and whether dbt is replacing or updating an object that already exists. You can always check the debug logs for the full set of grant and revoke statements that dbt runs.
1313

14-
dbt encourages you to use grants as resource configs whenever possible. In versions prior to Core v1.2, you were limited to using hooks for grants. Occasionally, you still might need to write grants statements manually and run them using hooks. For example, hooks may be appropriate if you want to:
14+
You should define grants as resource configs whenever possible, but you might occasionally need to write grants statements manually and run them using [hooks](/docs/build/hooks-operations). For example, hooks may be appropriate if you want to:
1515

16-
* Apply grants in a more complex or custom manner, beyond what the built-in grants capability can provide.
1716
* Apply grants on other database objects besides views and tables.
18-
* Take advantage of more-advanced permission capabilities offered by your data platform, for which dbt does not (yet!) offer out-of-the-box support using resource configuration.
1917
* Create more granular row- and column-level access, use masking policies, or apply future grants.
18+
* Take advantage of more advanced permission capabilities offered by your data platform, for which dbt does not offer out-of-the-box support using resource configuration.
19+
* Apply grants in a more complex or custom manner, beyond what the built-in grants capability can provide.
2020

2121
For more information on hooks, see [Hooks & operations](/docs/build/hooks-operations).
2222

@@ -154,6 +154,83 @@ Now, the model will grant select to `user_a`, `user_b`, AND `user_c`!
154154
- This use of `+`, controlling clobber vs. add merge behavior, is distinct from the use of `+` in `dbt_project.yml` (shown in the example above) for defining configs with dictionary values. For more information, see [the plus prefix](https://docs.getdbt.com/reference/resource-configs/plus-prefix).
155155
- `grants` is the first config to support a `+` prefix for controlling config merge behavior. Currently, it's the only one. If it proves useful, we may extend this capability to new and existing configs in the future.
156156

157+
### Conditional grants
158+
159+
Like any other config, you can use Jinja to vary the grants in different contexts. For example, you might grant different permissions in prod than dev:
160+
161+
<File name='dbt_project.yml'>
162+
163+
```yml
164+
models:
165+
+grants:
166+
select: "{{ ['user_a', 'user_b'] if target.name == 'prod' else ['user_c'] }}"
167+
```
168+
169+
</File>
170+
171+
## Revoking grants
172+
173+
dbt only modifies grants on a node (including revocation) when a `grants` configuration is attached to that node. For example, imagine you had originally specified the following grants in `dbt_project.yml`:
174+
175+
<File name='dbt_project.yml'>
176+
177+
```yml
178+
models:
179+
+grants:
180+
select: ['user_a', 'user_b']
181+
```
182+
183+
</File>
184+
185+
If you delete the entire `+grants` section, dbt assumes you no longer want it to manage grants and doesn't change anything. To have dbt revoke all existing grants from a node, provide an empty list of grantees.
186+
187+
<Tabs
188+
defaultValue="revoke-one"
189+
values={[
190+
{ label: 'Revoke from one user', value: 'revoke-one', },
191+
{ label: 'Revoke from all users', value:'revoke-all', },
192+
{ label: 'Stop dbt from managing grants', value:'stop-managing', },
193+
]
194+
}>
195+
196+
<TabItem value="revoke-one">
197+
<File name='dbt_project.yml'>
198+
199+
```yml
200+
models:
201+
+grants:
202+
select: ['user_b']
203+
```
204+
205+
</File>
206+
</TabItem>
207+
208+
<TabItem value="revoke-all">
209+
<File name='dbt_project.yml'>
210+
211+
```yml
212+
models:
213+
+grants:
214+
select: []
215+
```
216+
217+
</File>
218+
</TabItem>
219+
220+
<TabItem value="stop-managing">
221+
<File name='dbt_project.yml'>
222+
223+
```yml
224+
models:
225+
226+
# this section intentionally left blank
227+
```
228+
229+
</File>
230+
</TabItem>
231+
232+
</Tabs>
233+
157234
## General examples
158235

159236
You can grant each permission to a single grantee, or a set of multiple grantees. In this example, we're granting `select` on this model to just `bi_user`, so that it can be queried in our Business Intelligence (BI) tool.
@@ -249,7 +326,7 @@ models:
249326

250327
<div warehouse="Redshift">
251328

252-
* Granting to / revoking from is only fully supported for Redshift users (not [groups](https://docs.aws.amazon.com/redshift/latest/dg/r_Groups.html) or [roles](https://docs.aws.amazon.com/redshift/latest/dg/r_roles-managing.html)).
329+
* Granting to / revoking from is only fully supported for Redshift users (not [groups](https://docs.aws.amazon.com/redshift/latest/dg/r_Groups.html) or [roles](https://docs.aws.amazon.com/redshift/latest/dg/r_roles-managing.html)). See [dbt-redshift#415](https://github.com/dbt-labs/dbt-redshift/issues/415) for the corresponding issue.
253330

254331
</div>
255332

0 commit comments

Comments
 (0)