Share via

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

  • Статья

При создании облачных приложений они обычно отлаживать и тестировать приложения на локальной рабочей станции. Когда приложение выполняется на рабочей станции разработчика во время локальной разработки, оно по-прежнему должно пройти проверку подлинности в любых службах Azure, используемых приложением. В этой статье описывается, как использовать учетные данные разработчика Azure для проверки подлинности приложения в Azure во время локальной разработки.

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

Чтобы приложение выполнило проверку подлинности в Azure во время локальной разработки с помощью учетных данных Azure разработчика, разработчик должен войти в Azure из Azure CLI, Azure PowerShell или Azure Developer CLI. Пакет SDK Azure для Python может обнаружить, что разработчик вошел в систему из одного из этих средств, а затем получите необходимые учетные данные из кэша учетных данных для проверки подлинности приложения в Azure в качестве пользователя, вошедшего в систему.

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

1. Создание группы безопасности Microsoft Entra для локальной разработки

Так как в приложении почти всегда работает несколько разработчиков, рекомендуется сначала создать группу безопасности Microsoft Entra, чтобы инкапсулировать роли (разрешения), необходимые приложению в локальной разработке. Этот подход предлагает следующие преимущества.

  • Каждый разработчик гарантирует, что на уровне группы назначены одни и те же роли, так как роли назначаются на уровне группы.
  • Если для приложения требуется новая роль, ее необходимо добавить только в группу Microsoft Entra для приложения.
  • Если новый разработчик присоединяется к команде, они просто должны быть добавлены в правильную группу Microsoft Entra, чтобы получить правильные разрешения для работы с приложением.

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

Команда az ad group create используется для создания групп в идентификаторе Microsoft Entra. Параметры --display-name и --main-nickname являются обязательными. Имя, заданное группе, должно быть основано на имени приложения. Также полезно включить фразу, например local-dev, в имя группы, чтобы указать назначение группы.

az ad group create \
    --display-name MyDisplay \
    --mail-nickname MyDisplay  \
    --description "<group-description>"

Скопируйте значение id свойства в выходных данных команды. Это идентификатор объекта для группы. Вам потребуется это в последующих шагах. Для получения этого свойства можно также использовать команду az ad group show .

Чтобы добавить участников в группу, вам потребуется идентификатор объекта пользователя Azure. Используйте список пользователей az ad, чтобы получить список доступных субъектов-служб. Команда --filter параметра принимает фильтры стилей OData и может использоваться для фильтрации списка в отображаемом имени пользователя, как показано ниже. Параметр --query ограничивает выходные данные столбцами, интересующими вас.

az ad user list \
    --filter "startswith(displayName, 'Bob')" \
    --query "[].{objectId:id, displayName:displayName}" \
    --output table

Затем команду az ad group member add можно использовать для добавления участников в группы.

az ad group member add \
    --group <group-name> \
    --member-id <object-id>

Примечание.

По умолчанию создание групп безопасности Microsoft Entra ограничено определенными привилегированными ролями в каталоге. Если вы не можете создать группу, обратитесь к администратору каталога. Если вы не можете добавить участников в существующую группу, обратитесь к владельцу группы или администратору каталога. Дополнительные сведения см. в статье "Управление группами Microsoft Entra" и членством в группах.

2. Назначение ролей группе Microsoft Entra

Затем необходимо определить, какие роли (разрешения) приложения требуются для ресурсов и назначить эти роли приложению. В этом примере роли будут назначены группе Microsoft Entra, созданной на шаге 1. Роли можно назначать в ресурсе, группе ресурсов или подписке область. В этом примере показано, как назначать роли в группе ресурсов область, так как большинство приложений группировать все ресурсы Azure в одну группу ресурсов.

Пользователю, группе или субъекту-службе приложений назначается роль в Azure с помощью команды az role assignment create . Группу можно указать с идентификатором объекта.

az role assignment create --assignee {objectId} \
    --scope /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName} \
    --role "{roleName}"

Чтобы получить имена ролей, которые можно назначить, используйте команду az role definition list .

az role definition list --query "sort_by([].{roleName:roleName, description:description}, &roleName)" --output table

Например, чтобы разрешить членам группы идентификатор ресурса с идентификатором 00000000-0000-0000-0000-000000000000 чтения, записи и удаления доступа к служба хранилища Azure контейнерам BLOB-объектов и данным во всех учетных записях хранения в группе ресурсов msdocs-python-sdk-sdk-auth в подписке с идентификатором11111111-1111-1111-1111-111111111111, вы назначите роль участника данных blob-объектов служба хранилища группе с помощью следующей команды.

az role assignment create --assignee 00000000-0000-0000-0000-000000000000 \
    --scope /subscriptions/11111111-1111-1111-1111-111111111111/resourceGroups/msdocs-python-sdk-auth-example \
    --role "Storage Blob Data Contributor"

Сведения о назначении разрешений на уровне ресурса или подписки с помощью Azure CLI см. в статье "Назначение ролей Azure с помощью Azure CLI".

3. Вход в Azure с помощью Azure CLI, Azure PowerShell, Интерфейса командной строки разработчика Azure или в браузере

Откройте терминал на рабочей станции разработчика и войдите в Azure из Azure CLI.

az login

4. Реализация DefaultAzureCredential в приложении

Для проверки подлинности клиентских объектов Пакета SDK Azure в Azure приложение должно использовать DefaultAzureCredential класс из azure.identity пакета. В этом сценарии последовательно проверка, чтобы узнать, DefaultAzureCredential выполнил ли разработчик вход в Azure с помощью Azure CLI, Azure PowerShell или Интерфейса командной строки разработчика Azure. Если разработчик вошел в Azure с помощью любого из этих средств, учетные данные, используемые для входа в средство, будут использоваться приложением для проверки подлинности в Azure.

Начните с добавления пакета azure.identity в приложение.

pip install azure-identity

Затем для любого кода Python, создающего клиентский объект Azure SDK в приложении, вам потребуется:

  1. DefaultAzureCredential Импортируйте класс из azure.identity модуля.
  2. Создание объекта DefaultAzureCredential.
  3. Передайте объект конструктору DefaultAzureCredential клиентского объекта пакета SDK Azure.

Пример этих шагов показан в следующем сегменте кода.

from azure.identity import DefaultAzureCredential
from azure.storage.blob import BlobServiceClient

# Acquire a credential object
token_credential = DefaultAzureCredential()

blob_service_client = BlobServiceClient(
        account_url="https://<my_account_name>.blob.core.windows.net",
        credential=token_credential)