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

Если приложению требуется доступ к ресурсу Azure, например службе хранилища Azure, Azure Key Vault или средств Foundry, приложение должно пройти проверку подлинности в Azure. Это требование верно для всех приложений, независимо от того, развертываются ли они в Azure, развертываются локально или в процессе разработки на локальной рабочей станции разработчика. В этой статье описаны рекомендуемые подходы к проверке подлинности приложения в Azure при использовании пакета SDK Azure для Python.

Рекомендуемый подход к проверке подлинности приложений

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

Конкретный тип проверки подлинности на основе токенов, который приложение использует для проверки подлинности в ресурсах Azure, зависит от того, где выполняется приложение. Типы проверки подлинности на основе токенов показаны на следующей схеме.

• Когда разработчик выполняет приложение во время локальной разработки: приложение аутентифицируется в Azure, используя служебный принципал для локальной разработки или учетные данные Azure разработчика. Эти параметры рассматриваются в разделе "Проверка подлинности" во время локальной разработки.
• Когда приложение размещено в Azure: приложение проходит проверку подлинности в ресурсах Azure с помощью управляемого удостоверения. Этот параметр рассматривается в разделе "Проверка подлинности" в средах сервера.
• Если приложение размещено и развернуто локально: приложение проходит проверку подлинности в ресурсах Azure с помощью субъекта-службы приложений. Этот параметр рассматривается в разделе "Проверка подлинности" в средах сервера.

DefaultAzureCredential

Класс DefaultAzureCredential , предоставляемый клиентской библиотекой удостоверений Azure, позволяет приложениям использовать различные методы проверки подлинности в зависимости от среды, в которой они выполняются. Таким образом, приложения могут быть продвинуты из локальной разработки в тестовые среды и далее в продуктивную среду без изменений в коде.

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

Сведения об использовании DefaultAzureCredential класса рассматриваются в разделе "Использование DefaultAzureCredential" в приложении.

Преимущества проверки подлинности на основе токенов

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

• Методы проверки подлинности на основе маркеров, описанные в этой статье, позволяют устанавливать определенные разрешения, необходимые приложению в ресурсе Azure. Эта практика следует принципу наименьшей привилегии. В отличие от этого, строка подключения предоставляет полные права ресурсу Azure.
• Любой пользователь или любое приложение со строкой подключения может подключаться к ресурсу Azure, но методы проверки подлинности на основе маркеров ограничивают доступ к ресурсу только для тех приложений, которые предназначены для доступа к ресурсу.
• В управляемом удостоверении нет необходимости хранить секрет приложения. Приложение является более безопасным, так как нет строка подключения или секрета приложения, которые могут быть скомпрометированы.
• Пакет azure-identity получает токены Microsoft Entra и управляет ими. azure-identity делает использование проверки подлинности на основе токенов таким же простым, как строка подключения.

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

Проверка подлинности в средах сервера

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

Метод аутентификации	Описание
Приложения, размещенные в Azure	Приложения, размещенные в Azure, должны использовать служебный принципал управляемой сущности. Управляемые удостоверения предназначены для представления идентификации приложений, размещенных в Azure, и используются исключительно с такими приложениями. Например, веб-приложению Django, размещенному в Службе приложений Azure, будет назначено управляемое удостоверение. Затем управляемое удостоверение, назначенное приложению, будет использоваться для проверки подлинности приложения в других службах Azure. Приложения, работающие в Службе Azure Kubernetes (AKS), могут использовать удостоверение для рабочей нагрузки. Эти учетные данные основаны на управляемом удостоверении с отношением доверия с учетной записью службы AKS. , Узнайте о проверке подлинности в приложениях, размещенных в Azure
Приложения, размещенные за пределами Azure (например, локальные приложения)	Приложения, размещенные за пределами Azure (например, локальные приложения), для подключения к службам Azure должны использовать принципал службы приложения. Основной объект службы приложения представляет удостоверение приложения в Azure и создается в процессе регистрации приложения. Например, рассмотрим веб-приложение Django, размещенное в локальной среде, которая использует Хранилище BLOB-объектов Azure. Вы создадите учетную запись службы приложения, используя процесс регистрации приложения. Значения AZURE_CLIENT_ID, AZURE_TENANT_ID и AZURE_CLIENT_SECRET все будут храниться в виде переменных среды, которые приложение будет считывать во время выполнения, чтобы позволять приложению проходить аутентификацию в Azure с помощью учетной записи службы приложения. Сведения о проверке подлинности из приложений, размещенных за пределами Azure

Проверка подлинности во время локальной разработки

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

Метод аутентификации	Описание
Создайте специальные объекты Service Principal для приложений, которые будут использоваться при локальной разработке.	В этом методе выделенные объекты доверителя службы приложения настраиваются с помощью процесса регистрации приложения для использования во время локальной разработки. Идентичность главного сервиса затем хранится в виде переменных среды, к которым приложение будет обращаться при запуске в локальной разработке. Этот метод позволяет назначать определенные разрешения ресурсов, необходимые приложению для объектов субъекта-службы, используемых разработчиками во время локальной разработки. Эта практика гарантирует, что приложение имеет доступ только к определенным ресурсам, необходимым им, и реплицирует разрешения, которые приложение будет иметь в рабочей среде. Недостатком этого подхода является необходимость создания отдельных объектов сервисного принципала для каждого разработчика, который работает над приложением. Узнайте об аутентификации с использованием учетных записей служб разработчика
Проверка подлинности приложения в Azure с помощью учетных данных разработчика во время локальной разработки.	В этом методе разработчик должен войти в Azure из Azure CLI, Azure PowerShell или Azure Developer CLI на локальной рабочей станции. Затем приложение может получить доступ к учетным данным разработчика из хранилища учетных данных и использовать эти учетные данные для доступа к ресурсам Azure из приложения. Этот метод имеет преимущество более простой настройки, так как разработчику нужно войти только в свою учетную запись Azure с помощью одного из упомянутых выше средств разработчика. Недостатком этого подхода является то, что учетная запись разработчика, скорее всего, имеет больше разрешений, чем требуется для приложения. В результате приложение точно не реплицирует разрешения, с которыми он будет работать в рабочей среде. Сведения об аутентификации с помощью учетных записей разработчика

Использование DefaultAzureCredential в приложении

DefaultAzureCredential — это предопределенная, упорядоченная последовательность механизмов аутентификации в Microsoft Entra ID. Каждый механизм проверки подлинности — это класс, реализующий протокол TokenCredential и известный как учетные данные. Во время выполнения DefaultAzureCredential пытается пройти проверку подлинности с помощью первых учетных данных. Если этот учетные данные не удается получить токен доступа, предпринимается попытка следующих учетных данных в последовательности и т. д., пока токен доступа не будет успешно получен. Таким образом, приложение может использовать разные учетные данные в разных средах без написания кода для конкретной среды.

Чтобы использовать DefaultAzureCredential в приложении Python, добавьте azure-identity пакет в приложение.

pip install azure-identity

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

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

# Acquire a credential object
credential = DefaultAzureCredential()

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

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

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

Связанный контент

• Клиентская библиотека Azure Identity для Python README на GitHub