Аутентификация в рабочем пространстве с помощью учетной записи службы

Иногда выполнять интерактивную аутентификацию или вход от имени пользователя нецелесообразно (например, если вы хотите отправлять задания из веб-службы, другой рабочей роли или автоматизированной системы). Один из вариантов — настройка управляемого удостоверения. Другой вариант — использование принципала службы, об этом расскажет эта статья.

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

Чтобы выполнять аутентификацию от имени субъекта-службы, сначала нужно создать этот субъект-службу.

Чтобы создать субъект-службу, назначить права доступа и создать учетные данные, выполните следующие действия:

  1. Создайте приложение Azure AD:

    Примечание.

    Вам не нужно устанавливать URI перенаправления.

    1. После создания запишите значения Идентификатор приложения (клиент) и Идентификатор каталога (арендатор).

  2. Создайте учетные данные, чтобы войти в приложение:

    1. В разделе параметров приложения выберите Сертификаты и секреты.
    2. В разделе Секреты клиента выберите Создать секрет.
    3. Предоставьте описание и период действия, затем щелкните Добавить.
    4. Скопируйте значение этого секрета и немедленно сохраните его в надежном месте, ведь больше вы его не увидите.

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

    1. Откройте портал Azure.
    2. В поле поиска введите имя группы ресурсов, в которой вы создали рабочую область. Выберите группу ресурсов, когда она появится в результатах.
    3. В разделе обзор сведений для группы ресурсов выберите Управление доступом (IAM).
    4. Выберите Добавить назначение ролей.
    5. Найдите и выберите служебный принципал.
    6. Присвойте ему роль Участник или Владелец.

Примечание.

Чтобы создать назначение роли в группе ресурсов или рабочей области, необходимо быть владельцем или администратором доступа пользователей на уровне назначения роли. Если у вас нет разрешений на создание главного объекта службы в подписке, вам потребуется запросить разрешение у владельца или администратора подписки Azure.

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

az ad sp create-for-rbac --role Contributor --scopes /subscriptions/<SUBSCRIPTION-ID>

Аутентифицируйтесь как служебный принципал

Вариант 1. Использование переменных среды. Учетные данные по умолчанию, используемые при создании объекта Workspace, — это DefaultAzureCredential, который будет пытаться выполнить несколько типов проверки подлинности. Первый из них — EnvironmentCredential, с помощью которого вы передаете учетные данные сервисного аккаунта через следующие переменные среды:

  • AZURE_TENANT_ID — идентификатор арендатора субъекта-службы. Также называется идентификатором каталога.
  • AZURE_CLIENT_ID — идентификатор клиента субъекта-службы.
  • AZURE_CLIENT_SECRET — один из секретов клиента субъекта-службы.

Вариант 2. Использование ClientSecretCredential. Передайте ClientSecretCredential во время создания объекта Workspace или задайте свойство credentials.

from azure.identity import ClientSecretCredential

tenant_id = os.environ["AZURE_TENANT_ID"]
client_id = os.environ["AZURE_CLIENT_ID"]
client_secret = os.environ["AZURE_CLIENT_SECRET"]
credential = ClientSecretCredential(tenant_id=tenant_id, client_id=client_id, client_secret=client_secret)

workspace.credentials = credential

Примечание.

Метод workspace.login() является нерекомендуемым и больше не требуется. При первом вызове службы проверка подлинности будет предпринята с помощью учетных данных, переданных в Workspace конструкторе или его credentials свойстве. Если учетные данные не были переданы, DefaultAzureCredential попробует использовать несколько методов проверки подлинности.

  • Last updated on