На этой странице рассматриваются группы пользователей и управление доступом, включая:
- Пользовательские лицензии, разрешения и членство в группах
- Контроль доступа на основе ролей (RBAC) для проектов и окружений
- Единый вход (Single sign-on) и безопасная аутентификация
Для управления доступом к конкретным моделям и их доступности в разных проектах см. раздел Model access.
:::
О доступе пользователей
Вы можете регулировать доступ к dbt различными способами, включая лицензии, группы, разрешения и управление доступом на основе ролей (RBAC). Чтобы понять возможные подходы к управлению доступом пользователей к возможностям и функциональности dbt, сначала нужно разобраться, как мы работаем с пользователями и группами.
Пользователи
Отдельные пользователи в dbt могут быть реальными людьми, которых вы приглашаете вручную, или пользователями, которым предоставляется доступ через внешний провайдер удостоверений (IdP), такой как Microsoft Entra ID, Okta или Google Workspace.
В любом из этих сценариев, когда вы добавляете пользователя в dbt, ему назначается лицензия. Вы можете назначать лицензии как на уровне отдельных пользователей, так и на уровне групп. При ручном приглашении пользователя вы назначаете лицензию в окне приглашения.
Пример выпадающего списка лицензий в окне приглашения пользователя.Вы можете изменить лицензию существующего пользователя, перейдя в раздел Пользователи в Настройках аккаунта, нажав на пользователя и выбрав Редактировать в панели пользователя. Удалите пользователей из этого же окна, чтобы освободить лицензии для новых пользователей.
Пример окна информации о пользователе в каталоге пользователейПароли пользователей
По умолчанию новым пользователям предлагается установить пароль для своей учетной записи. Все тарифные планы поддерживают и требуют использование многофакторной аутентификации для пользователей, входящих по паролю. Однако перед настройкой MFA пользователю все равно необходимо сначала задать пароль. Учетные записи уровня Enterprise могут настраивать SSO и расширенные меры аутентификации. Планы Developer и Starter поддерживают только пароли пользователей с MFA.
Пароли пользователей должны соответствовать следующим требованиям:
- Содержать не менее девяти символов
- Содержать как минимум одну заглавную и одну строчную букву
- Содержать как минимум одну цифру от 0 до 9
- Содержать как минимум один специальный символ
Группы
Группы в dbt выполняют во многом ту же роль, что и в традиционных инструментах каталогов — они объединяют отдельных пользователей, упрощая массовое назначение разрешений.
Доступные разрешения зависят от того, используете ли вы план уровня Enterprise или самообслуживаемый план Starter.
- Администраторы используют группы в dbt для назначения лицензий и разрешений.
- Разрешения более детализированы, чем лицензии, и назначаются только на уровне группы; назначать разрешения на уровне отдельного пользователя нельзя.
- Каждый пользователь в dbt должен быть включен как минимум в одну группу.
Сразу после создания учетной записи dbt доступны три группы по умолчанию (пользователь, создавший учетную запись, автоматически добавляется во все три):
- Owner: Эта группа предназначена для лиц, отвечающих за всю учетную запись, и предоставляет им расширенные привилегии администратора аккаунта. Изменять разрешения нельзя.
- Member: Эта группа предназначена для обычных участников вашей организации. Разрешения по умолчанию достаточно широкие и ограничивают только доступ к функциям, которые могут влиять на биллинг или безопасность. По умолчанию dbt добавляет новых пользователей в эту группу.
- Everyone: Общая группа для всех участников вашей организации. Вы можете настроить разрешения в соответствии с потребностями вашей организации. По умолчанию dbt добавляет новых пользователей в эту группу.
Группы по умолчанию автоматически создаются для всех учетных записей, чтобы упростить первоначальную настройку. Мы рекомендуем создавать собственные организационные группы, чтобы вы могли гибко настраивать разрешения. После создания собственных групп вы можете удалить группы по умолчанию.
Создание новых групп EnterpriseEnterprise +
- Создавайте новые группы в разделе Groups & Licenses в Account settings.
- Если вы используете внешний IdP для SSO, вы можете синхронизировать эти SSO‑группы с dbt из панели Group details при создании новой группы или редактировании существующей.
Пример панели новой группы в настройках учетной записи.Если пользователю назначены лицензии и разрешения из нескольких групп, группа, предоставляющая наибольший доступ, будет иметь приоритет. Вы должны назначить набор разрешений для любых групп, созданных сверх трех по умолчанию, иначе пользователи, назначенные в них, не будут иметь доступа к функциям, кроме их пользовательского профиля.
Доступ и разрешения группы
Раздел Access & Permissions в настройках группы — это место, где вы можете назначить пользователям соответствующий уровень доступа в зависимости от их роли или обязанностей. Здесь вы определяете:
- к каким проектам группа имеет доступ;
- какие роли назначаются участникам группы для каждого проекта;
- в каких окружениях группа может вносить изменения.
Такая настройка дает гибкость в определении уровня доступа для пользователей в любой группе. Например, вы можете разрешить одной группе аналитиков редактировать задания (jobs) в своем проекте, но предоставить им только просмотр связанных проектов. Или же вы можете выдать доступ уровня администратора команде, которая владеет конкретным проектом, оставив для остальных пользователей доступ только для чтения.
Назначайте различные роли и права доступа группам пользователей.Права на запись в окружения (Environment write access)
Некоторые наборы разрешений предоставляют пользователям доступ к настройкам окружений только для чтения. Это ограничение можно переопределить, если назначить пользователей в группу с включенным Environment write access. В этом случае они смогут создавать, редактировать и удалять настройки окружений, такие как jobs и runs, обходя режим «только чтение». При этом расширенный доступ не дает права создавать или удалять сами окружения.
В следующем примере набор разрешений analyst, который по умолчанию имеет доступ к jobs только для чтения, назначен группе во всех проектах. Однако параметр Environment write access установлен в значение All Environments. Это дает всем пользователям в данной группе возможность создавать, редактировать и удалять jobs во всех окружениях и проектах.
Пользователи, которым назначен доступ на запись к среде, смогут редактировать настройки среды.Используйте настройки Environment write access только в том случае, если вы действительно хотите предоставить пользователям возможность редактировать окружения. Если необходимо выдать пользователям только те права, которые заложены в их наборе разрешений, оставьте эту настройку пустой (все флажки сняты).
Сопоставления SSO EnterpriseEnterprise +
SSO mappings связывают членство в группе поставщика удостоверений (Identity Provider, IdP) с группой в dbt. Когда пользователи входят в dbt через поддерживаемого поставщика удостоверений, их членство в группах IdP синхронизируется с dbt. После успешного входа членство пользователя в группах (а вместе с ним и разрешения) автоматически обновляется внутри dbt.
Хотя dbt поддерживает сопоставление нескольких групп IdP с одной группой dbt, мы рекомендуем использовать сопоставление 1:1, чтобы упростить администрирование. Используйте одинаковые имена для групп dbt и групп в вашем IdP.
Создайте SSO сопоставление в представлении группы:
- Откройте существующую группу для редактирования или создайте новую группу.
- В разделе SSO на экране группы введите название группы SSO точно так, как оно указано в IdP. Если название не совпадает, пользователи не будут правильно размещены в группе.
- В разделе Пользователи убедитесь, что опция Добавить всех пользователей по умолчанию отключена.
- Сохраните конфигурацию группы. Новые пользователи SSO будут добавлены в группу при входе, а существующие пользователи будут добавлены в группу при следующем входе.
Пример группы SSO, сопоставленной с группой dbt.Дополнительную информацию о сопоставлении групп SSO для назначения пользователей в группы dbt см. в разделе role-based access control.
Предоставление доступа
Пользователи dbt имеют как лицензию (назначенную конкретному пользователю или через членство в группе), так и разрешения (только через членство в группе), которые определяют, какие действия они могут выполнять. Лицензии действуют на уровне всего аккаунта, а разрешения обеспечивают более детализированный доступ или ограничения для отдельных функций.
Лицензии
Каждому пользователю в dbt будет назначена лицензия. Лицензии потребляют «места» (seats), которые влияют на то, как выставляется счёт для вашей учётной записи, в зависимости от вашего тарифного плана.
В dbt существует четыре типа лицензий:
- Analyst — доступна только на тарифах Enterprise и Enterprise+. Требует приобретения лицензии developer seat.
- Пользователю могут быть назначены любые permission sets.
- Developer — пользователю могут быть назначены любые permission sets.
- IT — доступна только на тарифах Starter, Enterprise и Enterprise+. Пользователь получает permission sets Security Admin и Billing Admin. См. permissions.
- Может управлять пользователями, группами, подключениями и лицензиями, а также выполнять другие действия.
- Пользователи с лицензией IT не наследуют права из каких-либо permission sets.
- Каждый пользователь с лицензией IT имеет одинаковый уровень доступа ко всему аккаунту, независимо от назначенных group permissions.
- Read-Only — доступна только на тарифах Starter, Enterprise и Enterprise+.
- Пользователь получает права только на чтение для всех ресурсов dbt.
- Предназначена для просмотра artifacts и раздела deploy (jobs, runs, schedules) в аккаунте dbt, без возможности вносить изменения.
- Пользователи с лицензией Read-only не наследуют права из каких-либо permission sets.
- Каждый пользователь с лицензией Read-only имеет одинаковый уровень доступа ко всему аккаунту, независимо от назначенных group permissions.
Лицензии разработчиков составляют большинство пользователей в вашей среде и оказывают наибольшее влияние на выставление счетов, поэтому важно следить за их количеством в любой момент времени.
Для получения дополнительной информации о этих типах лицензий см. Места и пользователи
Типы пользовательских лицензий всегда имеют приоритет над наборами разрешений, назначенными через группы. Например, пользователь с лицензией Read-Only не может выполнять административные действия, даже если он состоит в группе Account Admin.
Это гарантирует, что ограничения, связанные с лицензией, всегда применяются независимо от членства в группах.
Разрешения
Права доступа определяют, что пользователь с лицензией Developer может делать в вашем аккаунте dbt. По умолчанию участники групп Owner и Member имеют полный доступ ко всем разделам и возможностям. Если вам нужно ограничить доступ к отдельным функциям, назначайте пользователей в группы с более строгими наборами прав. Обратите внимание: если пользователь состоит в нескольких группах, приоритет имеет группа с наиболее широкими правами.
Доступные права зависят от того, используете ли вы план Enterprise, Enterprise+ или self-service Starter. В аккаунтах Developer есть только один пользователь, поэтому права доступа в них не применяются.
Пример выпадающего списка разрешений при редактировании существующей группы.Некоторые разрешения (те, которые не предоставляют полный доступ, как администраторы) позволяют группам быть "назначенными" только для конкретных проектов и сред. Прочтите о разрешениях на уровне среды для получения дополнительной информации об ограничении доступа к средам.
Пример управления доступом к среде для группы с назначенным администратором Git.Управление доступом на основе ролей EnterpriseEnterprise +
Управление доступом на основе ролей (Role-based access control, RBAC) позволяет предоставлять пользователям доступ к возможностям и функциональности на основе их принадлежности к группам. С помощью этого подхода вы можете назначать пользователям разные уровни доступа к различным проектам и окружениям. Вы можете вывести управление доступом и безопасность на новый уровень, интегрировав dbt со сторонним провайдером идентификации (IdP), чтобы предоставлять пользователям доступ после аутентификации через ваш SSO- или OAuth‑сервис.
Перед тем как настраивать RBAC для пользователей SSO, важно знать несколько моментов:
- Новые пользователи SSO автоматически добавляются во все группы, в которых включена опция Add all new users by default. По умолчанию эта опция включена для групп
EveryoneиMember. Для наилучшего опыта работы с RBAC рекомендуется отключить эту опцию во всех группах. - У вас должны быть корректно настроены группы SSO в разделе сведений о группе (Group details) в секции SSO. Если имя группы SSO не совпадает точно, пользователи не будут корректно добавляться в группу.
The Group details SSO section with a group configured. - dbt Labs рекомендует, чтобы имена групп в dbt совпадали с именами групп в IdP.
Предположим, что в вашу организацию принимают нового сотрудника с использованием Okta в качестве IdP и групп dbt с настроенными сопоставлениями SSO. В этом сценарии пользователи работают над проектом The Big Project, и к команде присоединяется новый аналитик по имени Euclid Ean.
Ознакомьтесь с следующими примерами конфигураций, чтобы получить представление о том, как вы можете реализовать RBAC для вашей организации (эти примеры предполагают, что вы уже настроили SSO):
Конфигурация Okta
Вы и ваша команда IdP добавляете Euclid Ean в свою среду Okta и назначаете его в SSO‑приложение dbt через группу с названием The Big Project.
Пользователь в группе в Okta.Настройте выражения атрибутов групп в приложении dbt в Okta. В примере ниже выражения групп настроены на точное совпадение с именем группы (The Big Project), однако в вашем случае конфигурация, скорее всего, будет гораздо более широкой. Компании часто используют один и тот же префикс для всех групп dbt в своём IdP. Например, DBT_GROUP_.
Атрибуты групп, настроенные в SAML 2.0 приложении dbt в Okta.dbt configuration
Вы и ваша команда администраторов dbt настраиваете группы в настройках аккаунта:
- Перейдите в Account settings и в меню слева выберите Groups & Licenses.
- Нажмите Create group или выберите существующую группу и нажмите Edit.
- Введите имя группы в поле SSO.
- Настройте поля Access and permissions в соответствии с вашими требованиями. Выберите набор разрешений, проекты, к которым группа может иметь доступ, и уровень доступа на уровне окружений.
Конфигурация группы в dbt с заполненным полем SSO.Эвклид ограничен ролью Аналитик, проектом Jaffle Shop и средами Разработка, Тестирование и Общая этого проекта. Эвклид не имеет доступа к среде Производство в своей роли.
Путь пользователя
Эвклид выполняет следующие шаги для входа в систему:
- Перейдите по URL-адресу SSO или откройте приложение dbt в своей учетной записи Okta. Этот URL можно найти на странице конфигурации Single sign-on в разделе Account settings.
URL для входа через SSO в настройках аккаунта.- Войдите в систему, используя свои учетные данные Okta.
Экран входа через SSO при использовании Okta в качестве поставщика удостоверений.- Поскольку это его первый вход через SSO, Эвклид Иан получает сообщение и не может продолжить, пока не проверит адрес электронной почты, связанный с его учетной записью Okta.
Экран, который видят пользователи после первого входа через SSO.- Затем они открывают свою электронную почту и переходят по ссылке, чтобы присоединиться к dbt Labs.
Электронное письмо, которое пользователь получает при первом входе через SSO.-
Их адрес электронной почты теперь подтверждён. Они нажимают Authenticate with your enterprise login, после чего процесс завершается.
Подтверждение того, что адрес электронной почты проверен.
Теперь Euclid вошёл в свою учётную запись. У него есть доступ только к проекту Jaffle Shop. В разделе Orchestration он может настроить учётные данные для разработки.
Страница оркестрации со средами.Окружение Production отображается, но доступ к нему ограничен режимом read-only, тогда как в окружении Staging у него есть полный доступ.
Страница среды Производство с доступом только для чтения.
Страница среды Тестирование с полным доступом.После настройки RBAC у вас появляется детальный контроль доступа пользователей к функциям по всему dbt.
Управление лицензиями SCIM
В рамках настройки SSO для поддерживаемых IdP вы также можете настроить параметры System for Cross-Domain Identity Management (SCIM), чтобы добавить дополнительный уровень безопасности в управление жизненным циклом пользователей. В рамках этого процесса вы можете интегрировать распределение пользовательских лицензий в процесс их провижининга через ваш IdP. Подробнее см. в инструкции по управлению лицензиями SCIM.
