О правах доступа на уровне окружения

Права доступа на уровне окружения предоставляют администраторам dbt Cloud возможность предоставлять права на запись для групп и сервисных токенов для определенных типов окружений в рамках проекта. Предоставление доступа к окружению дает пользователям доступ ко всем действиям и ресурсам на уровне окружения, связанным с их назначенными ролями. Например, пользователи с ролью Разработчика могут создавать и запускать задания в окружениях, к которым у них есть доступ. Для всех остальных окружений эти же пользователи будут иметь доступ только для чтения.

Для инструкций по настройке ознакомьтесь со страницей настройки.

Текущие ограничения

Права доступа на уровне окружения предоставляют администраторам dbt Cloud больше гибкости для защиты своих окружений, но важно понимать, что у этой функции есть некоторые ограничения, чтобы администраторы могли принимать обоснованные решения о предоставлении доступа.

• Права доступа на уровне окружения не позволяют создавать пользовательские роли и права для каждого типа ресурса в dbt Cloud.
• Вы можете выбирать только типы окружений и не можете указать конкретное окружение в проекте.
• Вы не можете выбирать конкретные ресурсы в окружениях. Задания и запуски dbt Cloud являются ресурсами окружения.
  • Например, вы не можете указать, что пользователь имеет доступ только к заданиям, но не к запускам. Доступ к данному окружению дает пользователю доступ ко всему в этом окружении.

Окружения и роли

В dbt Cloud существует четыре различных типа окружений для каждого проекта:

• Production — Основное окружение развертывания. Только одно уникальное Production окружение на проект.
• Development — Окружение для тестирования разработчиками. Только одно уникальное Development окружение на проект.
• Staging — Предпродакшн окружение, находящееся между разработкой и продакшном. Только одно уникальное Staging окружение на проект.
• General — Окружения общего назначения. Нет ограничений на количество на проект.

Права на запись в окружении могут быть указаны для следующих ролей:

• Аналитик
• Администратор базы данных
• Разработчик (Предыдущий доступ по умолчанию на запись для всех окружений. Новый доступ по умолчанию - доступ только для чтения, если доступ не указан)
• Git администратор
• Администратор команды

В зависимости от текущих сопоставлений групп, возможно, вам придется обновить роли, чтобы гарантировать, что пользователи имеют правильный уровень доступа к окружениям.

Определите, какие персоны нуждаются в обновленном доступе к окружениям и к каким ролям они должны быть привязаны. Ниже приведены несколько сценариев для прав доступа к окружениям:

• Разработчик — Доступ на запись для создания/запуска заданий в окружении разработки
• Тестирование/QA — Доступ на запись к предпродакшн и разработческим окружениям для тестирования
• Развертывание в продакшн — Доступ на запись ко всем окружениям, включая продакшн, для развертывания
• Аналитик — Не нуждается в доступе на запись к окружениям, но имеет доступ только для чтения для изучения и устранения неполадок
• Другие администраторы — Эти администраторы могут нуждаться в доступе на запись для создания/запуска заданий или настройки интеграций для любого количества окружений

Проекты и окружения

Права доступа на уровне окружения могут быть применены к одному или нескольким проектам с различным доступом к самим окружениям.

Окружения одного проекта

Если вы работаете с одним проектом, мы рекомендуем ограничить доступ к окружению 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, то ему нужен доступ ко всем окружениям.
• Аналитик: Если у пользователя есть роль Аналитика, то ему не нужен доступ на запись ни к одному окружению.
• Другие администраторы: Пользователь (не Администратор) может иметь доступ к нескольким проектам в зависимости от требований.

Если у пользователя одинаковые роли в разных проектах, вы можете применить доступ к окружениям ко всем проектам.

Связанные документы

• Настройка прав доступа на уровне окружения