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

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

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

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

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

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

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

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

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

Объекты учетной записи службы приложений создаются при регистрации приложения в Azure. Эту регистрацию можно выполнить с помощью портала Azure или Azure CLI. Процесс регистрации создает запись приложения на идентификационной платформе Microsoft Entra ID (ранее Azure Active Directory) и формирует объект служебного принципала для приложения. Объект главного сервиса используется для проверки подлинности приложения в сервисах Azure. Процесс регистрации приложения также создает секрет клиента (пароль) для приложения. Этот секрет используется для проверки подлинности приложения в службах Azure. Секрет клиента никогда не хранится в системе управления версиями, а в файле в .env каталоге приложений. Файл .env считывается приложением во время выполнения, чтобы задать переменные среды, которые пакет SDK Azure для Python использует для проверки подлинности приложения. Следующие шаги показывают, как зарегистрировать приложение в Azure и создать служебный принципал для приложения. Шаги показаны как для Azure CLI, так и для портала Azure.

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

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

SERVICE_PRINCIPAL_NAME=<service-principal-name>
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"
}

Затем необходимо получить appID значение и сохранить его в переменной. Это значение используется для настройки переменных окружения в вашей локальной среде разработки, чтобы пакет SDK Azure для Python мог проходить аутентификацию в Azure с помощью учетной записи службы.

APP_ID=$(az ad sp list \
  --all \
  --query "[?displayName=='$SERVICE_PRINCIPAL_NAME'].appId | [0]" \
  --output tsv)

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

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

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

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

GROUP_DISPLAY_NAME="<group-name>"
GROUP_MAIL_NICKNAME="<group-mail-nickname>"
GROUP_DESCRIPTION="<group-description>"
az ad group create \
  --display-name $GROUP_DISPLAY_NAME \
  --mail-nickname $GROUP_MAIL_NICKNAME \
  --description $GROUP_DESCRIPTION

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

SP_OBJECT_ID=$(az ad sp list \
  --filter "startswith(displayName,'$GROUP_DISPLAY_NAME')" \
  --query "[0].id" \
  --output tsv)

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

az ad group member add \
    --group $GROUP_DISPLAY_NAME \
    --member-id $SP_OBJECT_ID

Примечание.

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

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

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

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

RESOURCE_GROUP_NAME=<resource-group-name>
SUBSCRIPTION_ID=$(az account show --query id --output tsv)
ROLE_NAME=<role-name>
az role assignment create \
  --assignee "$APP_ID" \
  --scope "./subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RESOURCE_GROUP_NAME" \
  --role "$ROLE_NAME"

![!ПРИМЕЧАНИЕ] Чтобы предотвратить рассмотрение /subscriptions/... как путь к файлу, ставьте ./ перед строкой, используемой в параметре scope, и используйте двойные кавычки вокруг всей строки.

Чтобы получить имена ролей, которые можно назначить, используйте команду 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_ID считывает эти переменныеAZURE_TENANT_IDAZURE_CLIENT_SECRET, чтобы получить сведения о субъекте-службе приложения для подключения к 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)