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

Если приложению требуется доступ к ресурсу Azure, например служба хранилища Azure, Azure Key Vault или службам ИИ Azure, приложение должно пройти проверку подлинности в 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, всегда предпочтительнее при проверке подлинности в ресурсах 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
Создайте выделенные объекты субъекта-службы приложений, которые будут использоваться во время локальной разработки.	В этом методе выделенные объекты субъекта-службы приложений настраиваются с помощью процесса регистрации приложения для использования во время локальной разработки. Затем удостоверение субъекта-службы хранится в виде переменных среды, к которым будет обращаться приложение при запуске в локальной разработке. Этот метод позволяет назначать определенные разрешения ресурсов, необходимые приложению для объектов субъекта-службы, используемых разработчиками во время локальной разработки. Эта практика гарантирует, что приложение имеет доступ только к определенным ресурсам, необходимым им, и реплицирует разрешения, которые приложение будет иметь в рабочей среде. Недостатком этого подхода является необходимость создания отдельных объектов субъекта-службы для каждого разработчика, который работает в приложении. Сведения об аутентификации с помощью субъектов-служб разработчика
Проверка подлинности приложения в Azure с помощью учетных данных разработчика во время локальной разработки.	В этом методе разработчик должен войти в Azure из Azure CLI, Azure PowerShell или Azure Developer CLI на локальной рабочей станции. Затем приложение может получить доступ к учетным данным разработчика из хранилища учетных данных и использовать эти учетные данные для доступа к ресурсам Azure из приложения. Этот метод имеет преимущество более простой настройки, так как разработчику нужно войти только в свою учетную запись Azure с помощью одного из упомянутых выше средств разработчика. Недостатком этого подхода является то, что учетная запись разработчика, скорее всего, имеет больше разрешений, чем требуется для приложения. В результате приложение точно не реплицирует разрешения, с которыми он будет работать в рабочей среде. Сведения об аутентификации с помощью учетных записей разработчика

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

DefaultAzureCredential — это упорядоченная последовательность механизмов проверки подлинности в идентификаторе Microsoft Entra. Каждый механизм проверки подлинности — это класс, реализующий протокол 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 для Python README на GitHub