Поделиться через

Использование субъекта-службы для проверки подлинности в рабочей области Azure Quantum

  • Статья

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

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

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

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

  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 попробует использовать несколько методов проверки подлинности.