Перейти к основному содержимому

grants

Вы можете управлять доступом к наборам данных, которые вы создаёте с помощью dbt, используя grants. Для реализации этих прав доступа определите grants как конфигурации ресурса для каждой модели, seed или snapshot. Задайте grants по умолчанию, которые применяются ко всему проекту, в файле dbt_project.yml, а grants для конкретных моделей — в SQL- или YAML-файлах свойств каждой модели.

Конфигурации ресурса grants позволяют применять права доступа во время сборки к определённому набору получателей и к модели, seed или snapshot. Когда модель, seed или snapshot завершает сборку, dbt гарантирует, что grants для соответствующего представления (view) или таблицы в точности соответствуют тем grants, которые вы настроили.

dbt стремится использовать наиболее эффективный подход при обновлении grants. Он зависит от используемого адаптера, а также от того, заменяет ли dbt существующий объект или обновляет уже существующий. Вы всегда можете проверить debug-логи, чтобы увидеть полный набор команд grant и revoke, которые выполняет dbt.

Рекомендуется по возможности определять grants как конфигурации ресурсов, однако в некоторых случаях может потребоваться писать SQL-выражения grants вручную и запускать их с помощью hooks. Например, hooks могут быть уместны, если вы хотите:

  • Применять grants к другим объектам базы данных, помимо представлений и таблиц.
  • Создавать более детализированный доступ на уровне строк и столбцов, использовать masking policies или применять future grants.
  • Использовать более продвинутые возможности управления доступом, предоставляемые вашей платформой данных, для которых dbt не предлагает готовой поддержки через конфигурации ресурсов.
  • Применять grants более сложным или кастомным образом, выходящим за рамки встроенных возможностей grants.

Подробнее о hooks см. в разделе Hooks & operations.

Определение​

Вы можете использовать поле grants для задания разрешений или прав доступа для ресурса. Когда вы выполняете run для модели, seed для данных или snapshot для набора данных, dbt выполняет команды grant и/или revoke, чтобы гарантировать, что разрешения на объекте базы данных соответствуют grants, которые вы настроили для ресурса.

Как и все конфигурации, grants включаются в метаданные проекта dbt, в том числе в артефакт manifest.

Общий синтаксис​

Grants состоят из двух ключевых компонентов:

  • Privilege: Право на выполнение конкретного действия или набора действий над объектом в базе данных, например чтение данных из таблицы.
  • Grantees: Один или несколько получателей предоставляемых прав. Некоторые платформы также называют их «principals». Например, получателем может быть пользователь, группа пользователей, роль (Snowflake), назначенная одному или нескольким пользователям, или сервисный аккаунт (BigQuery/GCP).

Настройка разрешений​

Вы можете настраивать grants в dbt_project.yml, чтобы применять их сразу ко многим ресурсам — всем моделям проекта, пакету или подпапке. Также вы можете настраивать grants по отдельности для конкретных ресурсов — в YAML-блоках config: или прямо в .sql-файлах.

models/schema.yml
models:
- name: specific_model
config:
grants:
select: ['reporter', 'bi']

Конфигурация grants также может быть определена:

  • в разделе models в файле проекта (dbt_project.yml)
  • в Jinja-макросе config() внутри SQL-файла модели

Подробнее см. конфигурация и свойства.

Наследование конфигурации grants​

Если вы задаёте grants для одной и той же модели в нескольких местах, например в dbt_project.yml и в более конкретном .sql- или .yml-файле, поведение dbt по умолчанию заключается в замене менее специфичного набора получателей на более специфичный. Такое поведение «merge and clobber» обновляет каждое разрешение при разборе проекта dbt.

Например:

dbt_project.yml
models:
+grants: # В этом случае символ + не является опциональным — его необходимо указать, чтобы проект корректно распарсился.
select: ['user_a', 'user_b']
models/specific_model.sql
{{ config(grants = {'select': ['user_c']}) }}

В результате такой конфигурации для specific_model будет настроено предоставление привилегии select только пользователю user_c. После выполнения specific_model это будет единственное предоставленное право, которое вы увидите в базе данных, и единственная команда grant, которую вы найдёте в логах dbt.

Предположим, что мы хотим добавить user_c к существующему списку получателей привилегии select для specific_model, а не полностью заменить этот список. Для этого можно использовать символ + («addition»), добавив его в качестве префикса к имени привилегии:

models/specific_model.sql
{{ config(grants = {'+select': ['user_c']}) }}

Теперь модель предоставит привилегию select пользователям user_a, user_b и user_c!

Примечания:

  • Это будет работать только для тех привилегий, в имени которых используется префикс +. Каждая привилегия управляет таким поведением отдельно. Если бы вы предоставляли другие привилегии без префикса +, для них по-прежнему применялось бы поведение замены (clobber), а не добавления.
  • Использование + для управления поведением объединения (замена vs добавление) отличается от использования + в dbt_project.yml (как показано в примере выше) для определения конфигураций со значениями-словарями. Подробнее см. the plus prefix.
  • grants — это первая конфигурация, которая поддерживает префикс + для управления поведением объединения конфигураций. На данный момент это единственная такая конфигурация. Если этот подход окажется полезным, в будущем мы можем расширить его на новые и существующие конфигурации.

Условные разрешения​

Как и для любой другой конфигурации, вы можете использовать Jinja, чтобы изменять grants в зависимости от контекста. Например, вы можете предоставлять разные права в prod и dev:

dbt_project.yml
models:
+grants:
select: "{{ ['user_a', 'user_b'] if target.name == 'prod' else ['user_c'] }}"

Отзыв разрешений​

dbt изменяет grants на узле (включая отзыв прав) только в том случае, если конфигурация grants привязана к этому узлу. Например, представим, что изначально в dbt_project.yml были указаны следующие grants:

dbt_project.yml
models:
+grants:
select: ['user_a', 'user_b']

Если вы удалите весь раздел +grants, dbt предполагает, что вы больше не хотите, чтобы он управлял grants, и не будет ничего менять. Чтобы dbt отозвал все существующие grants у узла, необходимо указать пустой список получателей.

dbt_project.yml
models:
+grants:
select: ['user_b']

Общие примеры​

Вы можете предоставлять каждое разрешение одному получателю или набору из нескольких получателей. В этом примере мы предоставляем select для данной модели только пользователю bi_user, чтобы он мог выполнять запросы из нашего инструмента бизнес-аналитики (BI).

models/table_model.sql
{{ config(materialized = 'table', grants = {
'select': 'bi_user'
}) }}

Когда dbt запускает эту модель в первый раз, он создаёт таблицу, а затем выполняет код вида:

grant select on schema_name.table_model to bi_user;

В следующем примере мы создаём инкрементальную модель и предоставляем привилегию select двум получателям: bi_user и reporter.

models/incremental_model.sql
{{ config(materialized = 'incremental', grants = {
'select': ['bi_user', 'reporter']
}) }}

Когда dbt запускает эту модель в первый раз, он создаёт таблицу, а затем выполняет код вида:

grant select on schema_name.incremental_model to bi_user, reporter;

При последующих запусках dbt использует SQL, специфичный для конкретной базы данных, чтобы получить текущие grants на incremental_model, а затем определяет, нужно ли выполнять какие-либо команды revoke или grant.

Требования и заметки для разных хранилищ​

Несмотря на стремление стандартизировать используемые термины для описания различных возможностей, в разных базах данных всегда существуют нюансы. В этом разделе описаны некоторые требования и примечания, специфичные для отдельных СУБД.

В примерах выше и ниже мы используем привилегию с именем select и получателя с именем another_user. Многие базы данных используют эти или похожие термины. Обратите внимание, что ваша база данных может требовать другой синтаксис для привилегий и получателей; вы должны настраивать grants в dbt, используя корректные имена для обоих.

В BigQuery «привилегии» называются «ролями» и имеют вид roles/service.roleName. Например, вместо предоставления select на модель вы должны предоставить roles/bigquery.dataViewer.

Получателями могут быть пользователи, группы, сервисные аккаунты, домены — и каждый из них должен быть явно обозначен с помощью префикса. Например, чтобы предоставить доступ к модели пользователю someone@yourcompany.com, необходимо указать его как user:someone@yourcompany.com.

Рекомендуем ознакомиться с документацией Google для получения дополнительного контекста:

Note

Конфигурации grants и grant_access_to различны.

  • grant_access_to: Позволяет настроить авторизованные представления. При настройке dbt предоставляет доступ к авторизованному представлению для отображения частичной информации из других наборов данных, не предоставляя конечным пользователям полного доступа к этим исходным наборам данных. Для получения дополнительной информации см. "Конфигурации BigQuery: Авторизованные представления"
  • grants: Предоставляет конкретные разрешения пользователям, группам или сервисным аккаунтам для управления доступом к наборам данных, которые вы создаете с помощью dbt. Для получения дополнительной информации см. "Конфигурации ресурсов: grants"

Вы можете использовать обе функции вместе: "авторизовать" модель представления с помощью конфигурации grant_access_to, а затем добавить grants к этой модели представления, чтобы поделиться результатами её запросов (и только результатами её запросов) с другими пользователями, группами или сервисными аккаунтами.

Примеры BigQuery​

Предоставление прав с использованием SQL и BigQuery:

{{ config(grants = {'roles/bigquery.dataViewer': ['user:someone@yourcompany.com']}) }}

Предоставление прав в schema-файле модели для BigQuery:

models/schema.yml
models:
- name: specific_model
config:
grants:
roles/bigquery.dataViewer: ['user:someone@yourcompany.com']

Нашли ошибку?

0
Loading