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

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

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

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

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

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

DefaultAzureCredential

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

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

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

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

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

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

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

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

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

Authentication method	Description
Приложения, размещенные в 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 во время локальной разработки:

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

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

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

pip install azure-identity

В следующем примере кода показано, как создать экземпляр 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)

Объект DefaultAzureCredential автоматически обнаруживает механизм проверки подлинности, настроенный для приложения, и получает необходимые маркеры для проверки подлинности приложения в Azure. Если приложение использует несколько клиентов ПАКЕТА SDK, можно использовать один и тот же объект учетных данных с каждым клиентским объектом пакета SDK.

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

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

Порядок DefaultAzureCredential поиска учетных данных показан на следующей схеме и таблице:

Тип учетных данных	Description
Среда	Объект DefaultAzureCredential считывает набор переменных среды, чтобы определить, был ли для приложения задан субъект-служба приложения (пользователь приложения). В этом случае использует эти значения для DefaultAzureCredential проверки подлинности приложения в Azure. Этот метод чаще всего используется в серверных средах, но его также можно использовать при локальной разработке.
Удостоверение рабочей нагрузки	Если приложение развертывается в Служба Azure Kubernetes (AKS) с включенным управляемым удостоверением, DefaultAzureCredential выполняет проверку подлинности приложения в Azure с помощью этого управляемого удостоверения. Удостоверение рабочей нагрузки представляет реляционную связь доверия между управляемым удостоверением, назначенным пользователем, и учетной записью службы AKS. Проверка подлинности с помощью удостоверения рабочей нагрузки рассматривается в статье "Использование Идентификация рабочей нагрузки Microsoft Entra AKS с Служба Azure Kubernetes".
Управляемое удостоверение	Если приложение развертывается на узле Azure с включенным управляемым удостоверением, DefaultAzureCredential выполняет проверку подлинности приложения в Azure с помощью этого управляемого удостоверения. Проверка подлинности с помощью управляемого удостоверения рассматривается в разделе "Проверка подлинности" в средах сервера. Этот метод доступен только в том случае, если приложение размещено в Azure с помощью такой службы, как служба приложение Azure, Функции Azure или Azure Виртуальные машины.
Azure CLI	Если вы выполнили проверку подлинности в Azure с помощью az login команды в Azure CLI, DefaultAzureCredential выполняет проверку подлинности приложения в Azure с помощью той же учетной записи.
Azure PowerShell	Если вы выполнили проверку подлинности в Azure с помощью командлета Connect-AzAccount Из Azure PowerShell, DefaultAzureCredential выполняет проверку подлинности приложения в Azure с помощью той же учетной записи.
Azure Developer CLI	Если вы выполнили проверку подлинности в Azure с помощью azd auth login команды в Интерфейсе командной строки разработчика Azure, DefaultAzureCredential выполните проверку подлинности приложения в Azure с помощью той же учетной записи.
Интерактивный	Если этот параметр включен, DefaultAzureCredential интерактивно проходит проверку подлинности через браузер по умолчанию текущей системы. По умолчанию этот параметр отключен.

Примечание.

Из-за известной проблемы VisualStudioCodeCredentialудален из DefaultAzureCredential цепочки токенов. Когда проблема устранена в будущем выпуске, это изменение будет отменить изменения. Дополнительные сведения см . в клиентской библиотеке удостоверений Azure для Python.