Проверка подлинности приложений 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": "00000000-0000-0000-0000-000000000000",
  "displayName": "{service-principal-name}",
  "password": "abcdefghijklmnopqrstuvwxyz",
  "tenant": "33333333-3333-3333-3333-333333333333"
}

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

Например, чтобы разрешить субъекту-службе приложения с идентификатором 00000000-0000-0000-0000-000000000000 ресурсов для чтения, записи и удаления доступа к контейнерам больших двоичных объектов служба хранилища Azure и данным во всех учетных записях хранения в группе ресурсов msdocs-python-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".

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

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

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

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

pip install python-dotenv

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

  • AZURE_CLIENT_ID → значение идентификатора приложения.
  • AZURE_TENANT_ID → Значение идентификатора клиента.
  • AZURE_CLIENT_SECRET → пароль или учетные данные, созданные для приложения.
AZURE_CLIENT_ID=00000000-0000-0000-0000-000000000000
AZURE_TENANT_ID=11111111-1111-1111-1111-111111111111
AZURE_CLIENT_SECRET=abcdefghijklmnopqrstuvwxyz

Наконец, в коде запуска приложения используйте 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)