О правах доступа на уровне окружения
Разрешения на уровне окружения дают администраторам dbt возможность предоставлять права на запись группам и сервисным токенам для определённых типов окружений внутри проекта. Предоставление доступа к окружению даёт пользователям доступ ко всем действиям и ресурсам уровня окружения, требующим прав на запись, в соответствии с назначенными им ролями. Например, пользователи с ролью Developer могут создавать и запускать задания в тех окружениях, к которым у них есть доступ. Во всех остальных окружениях эти же пользователи будут иметь доступ только для чтения.
Для инструкций по настройке ознакомьтесь со страницей настройки.
Текущие ограничения
Разрешения на уровне окружения дают администраторам dbt больше гибкости для защиты своих окружений. Однако важно понимать, что у этой функции есть определённые ограничения, чтобы администраторы могли принимать осознанные решения при предоставлении доступа.
- Разрешения на уровне окружения не позволяют создавать пользовательские роли и разрешения для каждого типа ресурса в dbt.
- Вы можете выбирать только типы окружений и не можете указать конкретное окружение внутри проекта.
- Вы не можете выбирать отдельные ресурсы внутри окружений. Jobs и runs в dbt считаются ресурсами окружения.
- Например, нельзя указать, что пользователь имеет доступ только к jobs, но не к runs. Доступ к конкретному окружению автоматически даёт пользователю доступ ко всему, что находится внутри этого окружения.
Окружения и роли
dbt имеет четыре различных типа окружений для каждого проекта:
- Production — Основное окружение развертывания. Только одно уникальное Production окружение на проект.
- Development — Окружение для тестирования разработчиками. Только одно уникальное Development окружение на проект.
- Staging — Предпродакшн окружение, находящееся между разработкой и продакшном. Только одно уникальное Staging окружение на проект.
- General — Окружения общего назначения. Нет ограничений на количество на проект.
Права на запись в среде (Environment write permissions)
Права на запись в среде предоставляют доступ к созданию, редактированию и удалению запусков (runs) и заданий (jobs) внутри среды. Однако они не дают пользователям права создавать или удалять сами среды. Дополнительную информацию о расширенных наборах прав см. в разделе Enterprise permissions.
Права на запись в среде могут быть заданы для следующих ролей:
- Analyst
- Database admin
- Developer (Ранее — доступ на запись по умолчанию для всех сред. Новый вариант по умолчанию — доступ только на чтение для сред, если доступ явно не указан)
- Git admin
- Team admin
В зависимости от текущих сопоставлений групп, возможно, вам придется обновить роли, чтобы гарантировать, что пользователи имеют правильный уровень доступа к окружениям.
Определите, какие персоны нуждаются в обновленном доступе к окружениям и к каким ролям они должны быть привязаны. Ниже приведены несколько сценариев для прав доступа к окружениям:
- Developer — Доступ на запись для создания и запуска jobs в непроизводственных средах
- Testing/QA — Доступ на запись к средам staging и development для тестирования
- Production deployment — Доступ на запись ко всем средам, включая production, для выполнения развертываний
- Analyst — Не требуется доступ на запись к средам, но нужен доступ только на чтение для исследования данных и устранения проблем
- Other admins — Этим администраторам может потребоваться доступ на запись для создания и запуска jobs или настройки интеграций в любом количестве сред
Проекты и окружения
Права доступа на уровне окружения могут быть применены к одному или нескольким проектам с различным доступом к самим окружениям.
Окружения одного проекта
Если вы работаете с одним проектом, мы рекомендуем ограничить доступ к окружению Production и обеспечить доступ групп к окружениям Development, Staging или General, где они могут безопасно создавать и запускать задания. Пример того, как персоны могут быть сопоставлены с ролями:
- Разработчик: Роль разработчика с доступом на запись к окружениям Development и General
- Тестирование/QA: Роль разработчика с доступом на запись к окружениям Development, Staging и General
- Развертывание в продакшн: Роль разработчика с доступом на запись ко всем окружениям или роль Job Admin, которая имеет доступ ко всем окружениям по умолчанию.
- Аналитик: Роль аналитика без доступа на запись и с доступом только для чтения к окружениям.
- Другие администраторы: Зависит от потребностей администратора. Например, если они управляют развертыванием в продакшн, предоставьте доступ ко всем окружениям.
Несколько проектов
Предположим, что в компании Acme есть 12 проектов, из которых 3 принадлежат Финансам, 3 - Маркетингу, 4 - Производству и 2 - Технологиям.
С различным доступом по проектам:
- Разработчик: Если у пользователя есть роль Разработчика и доступ к Проектам A, B, C, то ему нужен доступ только к окружениям Dev и General.
- Тестирование/QA: Если у них есть роль Разработчика и доступ к Проектам A, B, C, то им нужен доступ только к окружениям Development, Staging и General.
- Развертывание в продакшн: Если у пользователя есть роль Администратора или Разработчика и доступ к Проектам A, B, C, то ему нужен доступ ко всем окружениям.
- Аналитик: Если у пользователя есть роль Аналитика, то ему не нужен доступ на запись ни к одному окружению.
- Другие администраторы: Пользователь (не Администратор) может иметь доступ к нескольким проектам в зависимости от требований.
Если у пользователя одинаковые роли в разных проектах, вы можете применить доступ к окружениям ко всем проектам.
