Проверка подлинности приложений 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 , предоставляемый клиентской библиотекой удостоверений 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 и создается с помощью процесса регистрации приложения. Например, рассмотрим веб-приложение Django, размещенное в локальной среде, которая использует Хранилище BLOB-объектов Azure. Вы создадите субъект-службу приложений для приложения с помощью процесса регистрации приложения. Значение AZURE_CLIENT_ID, AZURE_TENANT_IDи AZURE_CLIENT_SECRET все они будут храниться в виде переменных среды, которые будут считываться приложением во время выполнения и разрешать приложению проходить проверку подлинности в Azure с помощью субъекта-службы приложения. |
Когда приложение работает на рабочей станции разработчика во время локальной разработки, оно по-прежнему должно пройти проверку подлинности в любых службах Azure, используемых приложением. Существует две основные стратегии проверки подлинности приложений в Azure во время локальной разработки:
| Authentication method | Description |
|---|---|
| Создайте выделенные объекты субъекта-службы приложений, которые будут использоваться во время локальной разработки. | В этом методе выделенные объекты субъекта-службы приложений настраиваются с помощью процесса регистрации приложения для использования во время локальной разработки. Затем удостоверение субъекта-службы хранится в виде переменных среды, к которым будет обращаться приложение при запуске в локальной разработке. Этот метод позволяет назначать определенные разрешения ресурсов, необходимые приложению для объектов субъекта-службы, используемых разработчиками во время локальной разработки. Эта практика гарантирует, что приложение имеет доступ только к определенным ресурсам, необходимым им, и реплицирует разрешения, которые приложение будет иметь в рабочей среде. Недостатком этого подхода является необходимость создания отдельных объектов субъекта-службы для каждого разработчика, который работает в приложении. |
| Проверка подлинности приложения в Azure с помощью учетных данных разработчика во время локальной разработки. | В этом методе разработчик должен войти в Azure из Azure CLI, Azure PowerShell или Azure Developer CLI на локальной рабочей станции. Затем приложение может получить доступ к учетным данным разработчика из хранилища учетных данных и использовать эти учетные данные для доступа к ресурсам Azure из приложения. Этот метод имеет преимущество более простой настройки, так как разработчику нужно войти только в свою учетную запись Azure с помощью одного из упомянутых выше средств разработчика. Недостатком этого подхода является то, что учетная запись разработчика, скорее всего, имеет больше разрешений, чем требуется для приложения. В результате приложение точно не реплицирует разрешения, с которыми он будет работать в рабочей среде. |
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.