Проверка подлинности доступа к ресурсам Azure Databricks

Чтобы получить доступ к ресурсу Azure Databricks с помощью интерфейса командной строки Databricks или REST API, клиенты должны пройти проверку подлинности с помощью учетной записи Azure Databricks с требуемой авторизацией для доступа к ресурсу. Чтобы безопасно выполнить команду CLI Databricks или вызвать запрос API Databricks, требующий авторизованного доступа к учетной записи или рабочей области, необходимо предоставить маркер доступа на основе допустимых учетных данных учетной записи Azure Databricks. В этой статье рассматриваются параметры проверки подлинности для предоставления этих учетных данных и авторизации доступа к рабочей области Или учетной записи Azure Databricks.

В следующей таблице показаны методы проверки подлинности, доступные для учетной записи Azure Databricks.

Методы проверки подлинности Azure Databricks

Так как средства и пакеты SDK Azure Databricks работают с одним или несколькими поддерживаемыми методами проверки подлинности Azure Databricks, вы можете выбрать лучший метод проверки подлинности для вашего варианта использования. Дополнительные сведения см. в документации по инструменту или пакету SDK в Средства разработчика.

Метод	Description	Вариант использования
OAuth для субъектов-служб (OAuth M2M)	Кратковременные маркеры OAuth для субъектов-служб.	Сценарии автоматической проверки подлинности, такие как полностью автоматизированные и рабочие процессы CI/CD.
OAuth для пользователей (OAuth U2M)	Кратковременные маркеры OAuth для пользователей.	В сценариях проверки подлинности, в которых вы используете веб-браузер для проверки подлинности с помощью Azure Databricks в режиме реального времени, при появлении запроса.
Личные маркеры доступа (PAT)	Кратковременные или длительные маркеры для пользователей или субъектов-служб.	Сценарии, в которых целевое средство не поддерживает OAuth.
Проверка подлинности управляемых удостоверений Azure	Маркеры идентификатора Microsoft Entra для управляемых удостоверений Azure.	Используйте только ресурсы Azure, поддерживающие управляемые удостоверения, такие как виртуальные машины Azure.
Проверка подлинности субъект-службы Microsoft Entra.	Маркеры идентификатора Microsoft Entra для субъектов-служб Microsoft Entra ID.	Используйте только ресурсы Azure, поддерживающие маркеры идентификатора Microsoft Entra и не поддерживающие управляемые удостоверения, такие как Azure DevOps.
Проверка подлинности Azure CLI	Маркеры идентификатора Microsoft Entra для пользователей или субъектов-служб Идентификатора Microsoft Entra.	Используется для проверки подлинности доступа к ресурсам Azure и Azure Databricks с помощью Azure CLI.
Проверка подлинности пользователя идентификатора записи Майкрософт	Маркеры идентификатора Microsoft Entra для пользователей.	Используйте только с ресурсами Azure, поддерживающими только маркеры идентификатора Microsoft Entra. Databricks не рекомендует создавать маркеры идентификатора Microsoft Entra для пользователей Azure Databricks вручную.

Какой подход к проверке подлинности следует выбрать?

Существует два варианта проверки подлинности команды CLI Databricks или вызова API для доступа к ресурсам Azure Databricks:

• Используйте учетную запись пользователя Azure Databricks (проверку подлинности "пользователь — компьютер" или U2M). Выберите это только при выполнении команды Azure Databricks CLI из локальной клиентской среды или вызова запроса API Azure Databricks из кода, который вы владеете и выполняете исключительно.
• Используйте субъект-службу Azure Databricks (проверку подлинности "компьютер — компьютер" или M2M). Выберите это, если другие будут запускать код (особенно в случае приложения), или если вы создаете автоматизацию, которая вызовет команды Azure Databricks CLI или запросы API.

1. Если вы используете Azure Databricks, вы также можете использовать субъект-службу MS Entra для проверки подлинности доступа к учетной записи Или рабочей области Azure Databricks. Однако Databricks рекомендует использовать субъект-службу Databricks с нашей предоставленной проверкой подлинности OAuth через проверку подлинности субъекта-службы MS Entra. Это связано с тем, что проверка подлинности Databricks использует маркеры доступа OAuth, которые являются более надежными при проверке подлинности только с помощью Azure Databricks.

Дополнительные сведения об использовании субъекта-службы MS Entra для доступа к ресурсам Databricks см. в разделе проверки подлинности субъекта-службы MS Entra.

У вас также должен быть маркер доступа, связанный с учетной записью, которую вы будете использовать для вызова API Databricks. Этот маркер может быть маркером доступа OAuth 2.0 или личным маркером доступа (PAT). Однако Azure Databricks настоятельно рекомендует использовать OAuth для авторизации, так как маркеры OAuth автоматически обновляются по умолчанию и не требуют прямого управления маркером доступа, повышая безопасность при перехвате маркеров и нежелательном доступе. Так как OAuth создает и управляет маркером доступа для вас, вы предоставляете URL-адрес конечной точки маркера OAuth, идентификатор клиента и секрет, который создается из рабочей области Azure Databricks, а не напрямую предоставляет строку маркера самостоятельно. PaTs подвергают риску долгосрочные маркеры, предоставляющие возможности исходящего трафика, если они не регулярно проверяются и отменяются, или если строки токенов и пароли не управляются безопасно для вашей среды разработки.

Разделы справки использовать OAuth для проверки подлинности с помощью Azure Databricks?

Azure Databricks предоставляет единую проверку подлинности клиента для проверки подлинности с помощью набора переменных среды по умолчанию, которые можно задать для определенных значений учетных данных. Это помогает упростить и безопасно работать, так как эти переменные среды относятся к среде, которая будет выполнять команды Интерфейса командной строки Azure Databricks или вызывать API Azure Databricks.

• Для проверки подлинности учетной записи пользователя (на компьютере) Azure Databricks OAuth обрабатывается с помощью единой проверки подлинности клиента Databricks, если средства и пакеты SDK реализуют свой стандарт. Если они нет, вы можете вручную создать проверяющий код OAuth и вызвать пару вызовов для использования непосредственно в командах Интерфейса командной строки Azure Databricks и запросах API. См . шаг 1. Создание проверки кода OAuth и пары вызовов кода.
• Для проверки подлинности субъекта-службы (на компьютере) Azure Databricks OAuth требует, чтобы вызывающий объект предоставил учетные данные клиента вместе с URL-адресом конечной точки маркера, где запрос может быть авторизован. (Это обрабатывается при использовании средств Azure Databricks и пакетов SDK, поддерживающих унифицированную проверку подлинности клиента Databricks.) Учетные данные включают уникальный идентификатор клиента и секрет клиента. Клиент, являющийся субъектом-службой Databricks, который будет запускать код, должен быть назначен рабочим областям Databricks. После назначения субъекта-службы рабочим областям, к которым он будет обращаться, вы предоставляете идентификатор клиента и секрет клиента, который будет задан с определенными переменными среды.

Ниже перечислены эти переменные среды:

• DATABRICKS_HOST: эта переменная среды имеет URL-адрес консоли учетной записи Azure Databricks (http://accounts.cloud.databricks.com) или URL-адрес рабочей области Azure Databricks (https://{workspace-id}.cloud.databricks.com). Выберите тип URL-адреса узла на основе типа операций, которые будут выполняться в коде. В частности, если вы используете команды CLI уровня учетной записи Azure Databricks или запросы REST API, задайте эту переменную в URL-адрес учетной записи Azure Databricks. Если вы используете команды CLI уровня рабочей области Azure Databricks или запросы REST API, используйте URL-адрес рабочей области Azure Databricks.
• DATABRICKS_ACCOUNT_ID: используется для операций с учетной записью Azure Databricks. Это идентификатор учетной записи Azure Databricks. Чтобы получить его, см. статью "Найти идентификатор учетной записи".
• DATABRICKS_CLIENT_ID: (только M2M OAuth) Идентификатор клиента, назначенный при создании субъекта-службы.
• DATABRICKS_CLIENT_SECRET: (только M2M OAuth) Секрет клиента, созданный при создании субъекта-службы.

Эти параметры можно задать напрямую или с помощью профиля конфигурации Databricks (.databrickscfg) на клиентском компьютере.

Чтобы использовать маркер доступа OAuth, ваша рабочая область Azure Databricks или администратор учетной записи должны предоставить учетную запись пользователя или субъект-службу CAN USE привилегию для учетной записи и рабочих областей, к которым будет доступ ваш код.

Дополнительные сведения о настройке авторизации OAuth для клиента и проверке параметров авторизации для конкретного поставщика облачных служб см. в статье унифицированная проверка подлинности клиента.

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

Если вы пишете код, который обращается к сторонним службам, средствам или пакетам SDK, необходимо использовать механизмы проверки подлинности и авторизации, предоставляемые сторонним поставщиком. Однако если необходимо предоставить стороннему инструменту, пакету SDK или службе доступ к учетной записи Azure Databricks или ресурсам рабочей области, Databricks предоставляет следующую поддержку:

• Поставщик Databricks Terraform: это средство может получить доступ к API Azure Databricks из Terraform от вашего имени с помощью учетной записи пользователя Azure Databricks. Дополнительные сведения см. в статье "Подготовка субъекта-службы с помощью Terraform".

• Поставщики Git, такие как GitHub, GitLab и Bitbucket, могут получить доступ к API Azure Databricks с помощью субъекта-службы Databricks. Дополнительные сведения см. в разделе "Субъекты-службы" для CI/CD.

• Jenkins может получить доступ к API Azure Databricks с помощью субъекта-службы Databricks. Дополнительные сведения см. в разделе CI/CD с Jenkins в Azure Databricks.

• Azure DevOps может получить доступ к API Azure Databricks с помощью субъекта-службы MS Entra и идентификатора. Дополнительные сведения см. в статье Аутентификация с помощью Azure DevOps в Databricks.

Профили конфигурации Azure Databricks

Профиль конфигурации Azure Databricks содержит параметры и другие сведения, необходимые Azure Databricks для проверки подлинности. Профили конфигурации Azure Databricks хранятся в локальных клиентских файлах для инструментов, пакетов SDK, скриптов и приложений для использования. Файл стандартного профиля конфигурации называется .databrickscfg. Дополнительные сведения см. в профилях конфигурации Azure Databricks.