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

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

  • Статья

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

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

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

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

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

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

1. Регистрация приложения в Azure

Объекты субъекта-службы приложений создаются с регистрацией приложения в Azure. Это можно сделать с помощью портал Azure или Azure CLI.

Команды Azure CLI могут выполняться в Azure Cloud Shell или на рабочей станции с установленным интерфейсом Azure CLI.

Сначала используйте команду az ad sp create-for-rbac , чтобы создать новый субъект-службу для приложения. Команда также создает регистрацию приложения для приложения одновременно.

az ad sp create-for-rbac --name <service-principal-name>

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

{
  "appId": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "displayName": "<service-principal-name>",
  "password": "Ee5Ff~6Gg7.-Hh8Ii9Jj0Kk1Ll2Mm3_Nn4Oo5Pp6",
  "tenant": "aaaabbbb-0000-cccc-1111-dddd2222eeee"
}

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

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

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

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

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

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

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

az ad sp list \
    --filter "startswith(displayName, 'msdocs')" \
    --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" и членством в группах.

3. Назначение ролей приложению

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

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

az role assignment create --assignee <appId or 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

Например, чтобы разрешить субъекту-службе приложения с идентификатором 00001111-aaaa-2222-bbbb-3333cccc4444 ресурсов read, write и delete access to служба хранилища Azure контейнеры BLOB-объектов и данные во всех учетных записях хранения в группе ресурсов msdocs-python-sdk-sdk-auth-example в подписке с идентификаторомaaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e, вы назначите субъекту-службе приложения роль участника данных BLOB-объектов хранилища, используя следующую команду.

az role assignment create --assignee 00001111-aaaa-2222-bbbb-3333cccc4444 \
    --scope /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/msdocs-python-sdk-auth-example \
    --role "Storage Blob Data Contributor"

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

4. Задание переменных среды разработки

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

Файл .env никогда не проверяется в системе управления версиями, так как он содержит секретный ключ приложения для Azure. Стандартный файл gitignore для Python автоматически исключает .env файл из регистрации.

Чтобы использовать пакет python-dotenv, сначала установите пакет в приложении.

pip install python-dotenv

Затем создайте файл в корневом .env каталоге приложения. Задайте значения переменной среды со значениями, полученными из процесса регистрации приложения следующим образом:

  • AZURE_CLIENT_ID → значение идентификатора приложения.
  • AZURE_TENANT_ID → Значение идентификатора клиента.
  • AZURE_CLIENT_SECRET → пароль или учетные данные, созданные для приложения.
AZURE_CLIENT_ID=00001111-aaaa-2222-bbbb-3333cccc4444
AZURE_TENANT_ID=aaaabbbb-0000-cccc-1111-dddd2222eeee
AZURE_CLIENT_SECRET=Ee5Ff~6Gg7.-Hh8Ii9Jj0Kk1Ll2Mm3_Nn4Oo5Pp6

Наконец, в коде запуска приложения используйте python-dotenv библиотеку для чтения переменных среды из .env файла при запуске.

from dotenv import load_dotenv

if ( os.environ['ENVIRONMENT'] == 'development'):
    print("Loading environment variables from .env file")
    load_dotenv(".env")

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

Для проверки подлинности клиентских объектов Пакета SDK Azure в Azure приложение должно использовать DefaultAzureCredential класс из azure.identity пакета. В этом сценарии DefaultAzureCredential определит переменные среды и AZURE_CLIENT_SECRET считывает эти переменныеAZURE_CLIENT_IDAZURE_TENANT_ID, чтобы получить сведения о субъекте-службе приложения для подключения к 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)