Доступ к выделенной группе вычислений

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

Режим доступа к выделенной группе позволяет пользователям достичь операционной эффективности кластера со стандартным режимом доступа, а также безопасно поддерживать языки и рабочие нагрузки, которые не поддерживаются стандартным режимом доступа, такие как Databricks Runtime для машинного обучения, API устойчивых распределенных данных (RDD) и R.

Требования

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

  • Рабочая область должна быть активирована для работы с Unity Catalog.
  • Необходимо использовать Databricks Runtime 15.4 или более поздней версии.
  • Назначенная группа должна иметь разрешения CAN MANAGE в папке рабочей области, где они могут хранить записные книжки, эксперименты машинного обучения и другие артефакты рабочей области, используемые кластером группы.

Что такое выделенный режим доступа?

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

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

Создание вычислительного ресурса, выделенного для группы

  1. В рабочей области Azure Databricks перейдите к Compute и щелкните Create compute.
  2. Разверните раздел Дополнительно.
  3. В разделе Режим доступащелкните Вручную и выберите Выделенный (ранее: один пользователь) в выпадающем меню.
  4. В поле один пользователь или группа выберите группу, которую вы хотите назначить этому ресурсу.
  5. Настройте другие нужные параметры вычислений, а затем нажмите кнопку "Создать".

Рекомендации по управлению кластерами групп

Так как разрешения пользователей ограничены группой при использовании кластеров групп, Databricks рекомендует создать папку /Workspace/Groups/<groupName> для каждой группы, используемой с кластером групп. Затем назначьте разрешения CAN MANAGE на папку для группы. Это позволяет группам избежать ошибок разрешений. Все записные книжки группы и ресурсы рабочей области должны управляться в папке группы.

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

  • MLflow: убедитесь, что записная книжка выполняется из папки группы или запустите mlflow.set_tracking_uri("/Workspace/Groups/<groupName>").
  • AutoML: установите значение необязательного параметра experiment_dir на “/Workspace/Groups/<groupName>” для запуска AutoML.
  • dbutils.notebook.run. Убедитесь, что группа обладает READ разрешением на выполнение записной книжки.

Поведение управления доступом в групповых кластерах

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

Не удается применить отдельные разрешения пользователей, так как все члены группы имеют полный доступ к API Spark и общей вычислительной среде. Если были применены пользовательские разрешения, один член может запрашивать доступ к ограниченным данным, а другой член без доступа по-прежнему может получить результаты благодаря общей среде. Таким образом, сама группа, а не пользователь, который является членом группы, должен иметь необходимые разрешения для успешного выполнения действия.

Например, группе требуется явное разрешение на запрос к таблице, доступ к области секретов или секрету, использование учетных данных для подключения каталога Unity, доступ к папке Git или создание объекта рабочей зоны.

Примеры разрешений группы

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

Например, если у вас есть записная книжка, подключенная к кластеру группы, и выполните следующую команду:

use catalog main;
create schema group_cluster_group_schema;

Затем выполните этот запрос, чтобы проверить владельца схемы:

describe schema group_cluster_group_schema;

Пример описания схемы группы

Аудит выделенной вычислительной активности группы

Существует два ключевых идентификатора, задействованных при выполнении рабочей нагрузки в группе кластеров.

  1. Пользователь, выполняющий рабочую нагрузку в кластере группы
  2. Группа, разрешения которой используются для выполнения конкретных действий, связанных с рабочей нагрузкой.

Таблица системы журнала аудита записывает эти идентификаторы по следующим параметрам.

  • identity_metadata.run_by. Проверка подлинности пользователя, выполняющего действие
  • identity_metadata.run_as: группа авторизации, разрешения которой используются для действия.

Следующий пример запроса извлекает идентификационные метаданные для действия, совершаемого в групповом кластере.

select action_name, event_time, user_identity.email, identity_metadata
from system.access.audit
where user_identity.email = "uc-group-cluster-group" AND service_name = "unityCatalog"
order by event_time desc limit 100;

Дополнительные примеры запросов см. в справочнике по системе журнала аудита. См. ссылку на системную таблицу журнала аудита .

Известные ограничения

Доступ к выделенной группе имеет следующие ограничения:

  • Задания, созданные с помощью API и пакета SDK, не могут быть назначены доступом к группе. Это связано с тем, что параметр задания run_as поддерживает только одного пользователя или субъекта-службы.
  • Задания, использующие Git , завершаются сбоем, так как временный каталог, используемый для извлечения репозитория Git, недоступен для записи. Вместо этого используйте папки Git .
  • Системные таблицы происхождения не записывают identity_metadata.run_as (группу авторизации) или identity_metadata.run_by (аутентифицирующего пользователя) для рабочих нагрузок, выполняемых в групповом кластере.
  • Журналы аудита, доставленные в хранилище клиентов, не записывают identity_metadata.run_as (уполномочивающую группу) или identity_metadata.run_by (проверяющего пользователя) для рабочих нагрузок, выполняемых в кластерной группе. Для просмотра метаданных удостоверения необходимо использовать таблицу system.access.audit.
  • При присоединении к кластеру группы обозреватель каталогов не фильтруется по ресурсам, доступным только для группы.
  • Руководители групп, которые не являются членами группы, не могут создавать, изменять или удалять кластеры групп. Это можно сделать только администраторам рабочей области и членам группы.
  • Если группа переименована, необходимо вручную обновить все политики вычислений, ссылающиеся на имя группы.
  • Кластеры групп не поддерживаются для рабочих областей с отключенными списками управления доступом (isWorkspaceAclsEnabled == false) из-за отсутствия элементов управления безопасностью и доступом к данным при отключении списков управления доступом к рабочей области.
  • Команда %run и другие действия, выполняемые в контексте записной книжки, всегда используют разрешения пользователя, а не разрешения группы. Это связано с тем, что эти действия обрабатываются средой записной книжки, а не средой кластера. Альтернативные команды, такие как dbutils.notebook.run(), запускаются на кластере и поэтому используют разрешения группы.
  • Функция is_member(<group>) возвращает false при вызове на групповом кластере, так как группа не является членом себя. Чтобы правильно проверить членство в обоих кластерах групп и других режимах доступа, используйте is_member(<group>) OR current_user() == <group>.
  • Создание и доступ к конечным точкам обслуживания моделей не поддерживается.
  • Создание и доступ к конечным точкам поиска векторов или индексам не поддерживается.
  • Удаление файлов и папок не поддерживается в кластерах групп.
  • Пользовательский интерфейс отправки файлов не поддерживает кластеры групп.
  • Last updated on