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


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

При размещении приложения в Azure с помощью таких служб, как служба приложение Azure, Azure Виртуальные машины или Экземпляры контейнеров Azure, рекомендуемый подход для проверки подлинности приложения в ресурсах Azure имеет управляемое удостоверение.

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

Примечание.

Приложения, работающие на Служба Azure Kubernetes (AKS), могут использовать удостоверение рабочей нагрузки для проверки подлинности с помощью ресурсов Azure. В AKS удостоверение рабочей нагрузки представляет отношение доверия между управляемым удостоверением и учетной записью службы Kubernetes. Если приложение, развернутое в AKS, настроено с учетной записью службы Kubernetes в такой связи, DefaultAzureCredential выполняет проверку подлинности приложения в Azure с помощью управляемого удостоверения. Проверка подлинности с помощью удостоверения рабочей нагрузки рассматривается в разделе "Использование Идентификация рабочей нагрузки Microsoft Entra с Служба Azure Kubernetes". Инструкции по настройке удостоверения рабочей нагрузки см. в статье "Развертывание и настройка удостоверения рабочей нагрузки" в кластере Служба Azure Kubernetes (AKS).

Типы управляемых удостоверений

Существует два типа управляемых удостоверений:

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

В этой статье рассматриваются действия по включению и использованию управляемого удостоверения, назначаемого системой, для приложения. Если вам нужно использовать управляемое удостоверение, назначаемое пользователем, см. статью "Управление назначаемыми пользователем управляемыми удостоверениями ", чтобы узнать, как создать управляемое удостоверение, назначаемое пользователем.

1. Включение управляемого удостоверения в ресурсе Azure, в котором размещено приложение

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

Вы можете включить управляемое удостоверение для ресурса Azure с помощью портал Azure или Azure CLI.

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

Команды Azure CLI, используемые для включения управляемого удостоверения для ресурса Azure, имеют форму az <command-group> identity --resource-group <resource-group-name> --name <resource-name>. Ниже приведены определенные команды для популярных служб Azure.

az webapp identity assign --resource-group <resource-group-name> -name <web-app-name>

Выходные данные будут выглядеть следующим образом.

{
  "principalId": "aaaaaaaa-bbbb-cccc-1111-222222222222",
  "tenantId": "aaaabbbb-0000-cccc-1111-dddd2222eeee",
  "type": "SystemAssigned",
  "userAssignedIdentities": null
}

Это principalId значение является уникальным идентификатором управляемого удостоверения. Сохраните копию этих выходных данных, так как эти значения потребуются на следующем шаге.

2. Назначение ролей управляемому удостоверению

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

Управляемое удостоверение назначается роли в Azure с помощью команды az role assignment create . Для назначаемого пользователя используйте скопированные principalId на шаге 1.

az role assignment create --assignee <managedIdentityprincipalId> \
    --scope /subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName> \
    --role "<roleName>" 

Чтобы получить имена ролей, которым может быть назначен субъект-служба, используйте команду az role definition list .

az role definition list \
    --query "sort_by([].{roleName:roleName, description:description}, &roleName)" \
    --output table

Например, чтобы разрешить управляемое удостоверение с идентификатором aaaaaaaa-bbbb-cccc-1111-222222222222 ресурса чтения, записи и удаления доступа к контейнерам больших двоичных объектов служба хранилища Azure и данным во всех учетных записях хранения в группе ресурсов msdocs-python-sdk-sdk-auth-example в подписке с идентификаторомaaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e, вы назначите субъекту-службе приложения роль участника данных BLOB-объектов хранилища с помощью следующей команды.

az role assignment create --assignee aaaaaaaa-bbbb-cccc-1111-222222222222 \
    --scope /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/msdocs-python-sdk-auth-example \
    --role "Storage Blob Data Contributor"

Сведения о назначении разрешений на уровне ресурса или подписки с помощью Azure CLI см. в статье "Назначение ролей Azure с помощью Azure CLI".

3. Реализация DefaultAzureCredential в приложении

Если код запущен в Azure и управляемом удостоверении включен в ресурсе Azure, на котором размещено приложение, DefaultAzureCredential учетные данные определяются в следующем порядке:

  1. Проверьте среду для субъекта-службы, определяемую переменными AZURE_CLIENT_IDсреды, AZURE_TENANT_IDи AZURE_CLIENT_SECRET либо или AZURE_CLIENT_CERTIFICATE_PATH (при необходимости). AZURE_CLIENT_CERTIFICATE_PASSWORD
  2. Проверьте параметры ключевых слов для управляемого удостоверения, назначаемого пользователем. Управляемое удостоверение, назначаемое пользователем, можно передать, указав его идентификатор клиента в параметре managed_identity_client_id .
  3. AZURE_CLIENT_ID Проверьте переменную среды для идентификатора клиента управляемого удостоверения, назначаемого пользователем.
  4. Если он включен, используйте управляемое удостоверение, назначаемое системой, для ресурса Azure.

Вы можете исключить управляемые удостоверения из учетных данных, задав параметр Trueключевого exclude_managed_identity_credential слова.

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

Сначала добавьте 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)

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