Проверка подлинности доступа и подключений к ресурсам Azure с помощью управляемых удостоверений в Azure Logic Apps

  • Статья

Область применения: Azure Logic Apps (Потребление + Стандартный)

Если вы хотите избежать предоставления, хранения учетных данных, секретов или маркеров Microsoft Entra, можно использовать управляемое удостоверение для проверки подлинности доступа или подключений из рабочего процесса приложения логики к защищенным ресурсам Microsoft Entra. В Azure Logic Apps некоторые операции соединителя поддерживаются с помощью управляемого удостоверения, когда необходимо пройти проверку подлинности доступа к ресурсам, защищенным идентификатором Microsoft Entra. Azure управляет этим удостоверением и помогает обеспечить безопасность сведений проверки подлинности, чтобы вам не нужно было управлять этой конфиденциальной информацией. См. сведения об управляемых удостоверениях для ресурсов Azure.

Azure Logic Apps поддерживает следующие типы управляемых удостоверений:

В следующем списке описываются некоторые различия между этими типами управляемых удостоверений:

  • Ресурс приложения логики может включать и использовать только одно уникальное удостоверение, назначаемое системой.

  • Ресурс приложения логики может совместно использовать одно и то же удостоверение, назначаемое пользователем, в группе других ресурсов приложения логики.

В этом руководстве показано, как выполнить следующие задачи:

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

  • Создайте и настройте удостоверение, назначаемое пользователем. В этом руководстве показано, как создать это удостоверение с помощью портал Azure или шаблона Azure Resource Manager (шаблона ARM) и использования удостоверения для проверки подлинности. Сведения о Azure PowerShell, Azure CLI и AZURE REST API см. в следующей документации:

Средство Документация
Azure PowerShell Создание назначаемого пользователем удостоверения
Azure CLI Создание назначаемого пользователем удостоверения
Azure REST API Создание назначаемого пользователем удостоверения

Необходимые компоненты

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

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

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

Различия в управляемом удостоверении между приложениями логики "Потребление" и "Стандартный"

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

Приложение логики Среда Поддержка управляемых удостоверений
Потребление — Мультитенантные Приложения Логики Azure

- Среда службы интеграции (ISE)		 — Вы можете включить удостоверение, назначаемое системой, или удостоверение, назначаемое пользователем, но не в приложении логики.

— Управляемое удостоверение можно использовать на уровне ресурса приложения логики и на уровне подключения.

— Если вы создаете и включаете удостоверение, назначаемое пользователем, приложение логики может одновременно иметь только одно назначаемое пользователем удостоверение.
Стандартные — Azure Logic Apps с одним клиентом

— Среда службы приложений версии 3 (ASEv3)

- Logic Apps с поддержкой Azure Arc		 — Вы можете включить как назначаемое системой удостоверение, которое включено по умолчанию, так и удостоверение, назначаемое пользователем, одновременно. Вы также можете добавить несколько удостоверений, назначенных пользователем, в приложение логики. Однако приложение логики может одновременно использовать только одно управляемое удостоверение.

— Управляемое удостоверение можно использовать на уровне ресурса приложения логики и на уровне подключения.

Сведения об ограничениях управляемых удостоверений в Azure Logic Apps см. в разделе "Ограничения для управляемых удостоверений" для приложений логики. Дополнительные сведения о типах ресурсов и средах приложения логики "Потребление" и "Стандартный" см. в следующей документации:

Где можно использовать управляемое удостоверение

В Azure Logic Apps только определенные встроенные и управляемые операции соединителя, поддерживающие OAuth с идентификатором Microsoft Entra, могут использовать управляемое удостоверение для проверки подлинности. В приведенных ниже таблицах приведены только выборки образца. Полный список см. в следующей документации:

Для рабочего процесса приложения логики потребления в следующей таблице перечислены примеры соединителей, поддерживающих проверку подлинности управляемого удостоверения:

Тип соединителя Поддерживаемые соединители
Встроенный — Azure Управление API
— службы приложение Azure
- Функции Azure
- HTTP
- HTTP + Веб-перехватчик

Примечание. Операции HTTP могут проверять подлинность подключений к учетным записям службы хранилища Azure в обход брандмауэров Azure, используя назначаемое системой удостоверение. Однако http-операции не поддерживают удостоверение, назначаемое пользователем, для проверки подлинности одних и того же подключения.
Управляется — служба приложение Azure
- служба автоматизации Azure
- Хранилище BLOB-объектов Azure
— Экземпляр контейнера Azure
— Azure Cosmos DB
— Обозреватель данных Azure
- Фабрика данных Azure
— Azure Data Lake
— Azure Digital Twins
- Сетка событий Azure
- Центры событий Azure
— Azure IoT Central V2
— Azure Key Vault
-Журналы Azure Monitor
— Очереди Azure
— Azure Resource Manager
- Служебная шина Azure
— Azure Sentinel
— Таблица Azure служба хранилища
— виртуальная машина Azure
- SQL Server

Включение назначаемого системой удостоверения в портал Azure

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

  1. В портал Azure откройте ресурс приложения логики потребления.

  2. В меню приложения логики в разделе Параметры выберите Идентификатор.

  3. На странице "Удостоверение" в разделе "Назначенная системой" выберите "Сохранить".> Когда Azure запросит подтверждение, выберите Да.

    Снимок экрана: портал Azure, приложение логики потребления, страница удостоверений и вкладка

    Примечание.

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

    Теперь ресурс приложения логики может использовать назначаемое системой удостоверение. Это удостоверение зарегистрировано в идентификаторе Microsoft Entra и представлено идентификатором объекта.

    Снимок экрана: приложение логики потребления, страница удостоверений и идентификатор объекта для назначаемого системой удостоверения.

    Свойство Значение Описание
    Идентификатор объекта (субъекта) <identity-resource-ID> Глобальный уникальный идентификатор (GUID), представляющий удостоверение, назначаемое системой для приложения логики в клиенте Microsoft Entra.

  4. Теперь выполните действия, которые предоставляют системным удостоверениям доступ к ресурсу далее в этом руководстве.

Включение назначаемого системой удостоверения с помощью шаблона ARM

Чтобы автоматизировать создание и развертывание ресурсов приложений логики, можно использовать шаблон ARM. Чтобы включить назначаемое системой удостоверение для ресурса приложения логики в шаблоне, добавьте объект удостоверения и дочернее свойство типа в определение ресурса приложения логики в шаблоне, например:

{
   "apiVersion": "2016-06-01",
   "type": "Microsoft.logic/workflows",
   "name": "[variables('logicappName')]",
   "location": "[resourceGroup().location]",
   "identity": {
      "type": "SystemAssigned"
   },
   "properties": {},
   <...>
}

Когда Azure создает определение ресурса приложения логики, объект удостоверений получает следующие другие свойства:

"identity": {
   "type": "SystemAssigned",
   "principalId": "<principal-ID>",
   "tenantId": "<Entra-tenant-ID>"
}
Свойство (JSON) значение Описание
principalId <ИД субъекта> Глобальный уникальный идентификатор (GUID) объекта субъекта-службы для управляемого удостоверения, представляющего приложение логики в клиенте Microsoft Entra. Этот GUID иногда отображается как "идентификатор объекта" или objectID.
tenantId <Microsoft-Entra-ID-tenant-ID> Глобальный уникальный идентификатор (GUID), представляющий клиент Microsoft Entra, в котором приложение логики теперь является членом. В клиенте Microsoft Entra субъект-служба имеет то же имя, что и экземпляр приложения логики.

Создание назначаемого пользователем управляемого удостоверения через портал Azure

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

  1. В поле поиска портал Azure введите управляемые удостоверения. В списке результатов выберите управляемые удостоверения.

    Снимок экрана: портал Azure с выбранным параметром

  2. На панели инструментов "Управляемые удостоверения" нажмите кнопку "Создать".

  3. Укажите сведения об управляемом удостоверении и выберите " Проверить и создать", например:

    Снимок экрана: страница

    Свойство Обязательное поле значение Описание
    Подписка Да <имя-подписки-Azure> Имя подписки Azure
    Группа ресурсов Да <имя-группы-ресурсов-Azure> Имя группы ресурсов Azure. Создайте группу или выберите имеющуюся. В этом примере создается новая группа с именем fabrikam-managed-identities-RG.
    Регион Да <Azure-region> Регион Azure, в котором будут храниться сведения о приложении логики. В этом примере используется регион западная часть США.
    Имя Да <user-assigned-identity-name> Имя, присваиваемое удостоверению. В этом примере используется fabrikam-user-assigned-identity.

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

Добавление назначаемого пользователем удостоверения в приложение логики с помощью портала Azure

  1. В портал Azure откройте ресурс приложения логики потребления.

  2. В меню приложения логики в разделе Параметры выберите Идентификатор.

  3. На странице "Удостоверение" выберите "Пользователь", а затем нажмите кнопку "Добавить".

    Снимок экрана: страница

  4. На панели Добавление управляемого удостоверения, назначаемого пользователем сделайте следующее:

    1. В списке "Выбор подписки " выберите подписку Azure.

    2. В списке со всеми управляемыми удостоверениями в подписке выберите нужное удостоверение, назначаемое пользователем. Чтобы отфильтровать список, в поле поиска Назначенные пользователем управляемые удостоверения нужно будет ввести имя удостоверения или группы ресурсов.

      Снимок экрана: приложение логики потребления и выбранное удостоверение, назначаемое пользователем.

    3. Закончив, нажмите кнопку Добавить.

      Примечание.

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

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

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

  5. Теперь выполните действия, которые предоставляют удостоверению доступ к ресурсу далее в этом руководстве.

Создание назначаемого пользователем удостоверения с помощью шаблона ARM

Чтобы автоматизировать создание и развертывание ресурсов приложений логики, можно использовать шаблон ARM. Эти шаблоны поддерживают назначаемые пользователем удостоверения для проверки подлинности.

В разделе ресурсов шаблона определение ресурса приложения логики требует следующих элементов:

  • Объект identity с свойством type, заданным для UserAssigned

  • Дочерний объект userAssignedIdentities , указывающий назначенный пользователем ресурс и имя

В этом примере показан ресурс приложения логики потребления и определение рабочего процесса для HTTP-запроса PUT с непараметризованным объектом удостоверения . Ответ на запрос PUT и последующую операцию GET также включает этот объект удостоверения :

{
   "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
   "contentVersion": "1.0.0.0",
   "parameters": {<template-parameters>},
   "resources": [
      {
         "apiVersion": "2016-06-01",
         "type": "Microsoft.logic/workflows",
         "name": "[variables('logicappName')]",
         "location": "[resourceGroup().location]",
         "identity": {
            "type": "UserAssigned",
            "userAssignedIdentities": {
               "/subscriptions/<Azure-subscription-ID>/resourceGroups/<Azure-resource-group-name>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<user-assigned-identity-name>": {}
            }
         },
         "properties": {
            "definition": {<logic-app-workflow-definition>}
         },
         "parameters": {},
         "dependsOn": []
      },
   ],
   "outputs": {}
}

Если шаблон также включает определение ресурса управляемого удостоверения, можно параметризовать объект удостоверения . В следующем примере показано, как дочерний объект userAssignedIdentities ссылается на переменную userAssignedIdentityName, определяемую в разделе переменных шаблона. Эта переменная ссылается на идентификатор ресурса для назначенного пользователю удостоверения.

{
   "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
   "contentVersion": "1.0.0.0",
   "parameters": {
      "Template_LogicAppName": {
         "type": "string"
      },
      "Template_UserAssignedIdentityName": {
         "type": "securestring"
      }
   },
   "variables": {
      "logicAppName": "[parameters(`Template_LogicAppName')]",
      "userAssignedIdentityName": "[parameters('Template_UserAssignedIdentityName')]"
   },
   "resources": [
      {
         "apiVersion": "2016-06-01",
         "type": "Microsoft.logic/workflows",
         "name": "[variables('logicAppName')]",
         "location": "[resourceGroup().location]",
         "identity": {
            "type": "UserAssigned",
            "userAssignedIdentities": {
               "[resourceId('Microsoft.ManagedIdentity/userAssignedIdentities/', variables('userAssignedIdentityName'))]": {}
            }
         },
         "properties": {
            "definition": {<logic-app-workflow-definition>}
         },
         "parameters": {},
         "dependsOn": [
            "[resourceId('Microsoft.ManagedIdentity/userAssignedIdentities/', variables('userAssignedIdentityName'))]"
         ]
      },
      {
         "apiVersion": "2018-11-30",
         "type": "Microsoft.ManagedIdentity/userAssignedIdentities",
         "name": "[parameters('Template_UserAssignedIdentityName')]",
         "location": "[resourceGroup().location]",
         "properties": {}
      }
  ]
}

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

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

Примечание.

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

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

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

Например, чтобы получить доступ к учетной записи Хранилища BLOB-объектов Azure с использованием управляемого удостоверения, необходимо настроить доступ с помощью управления доступом на основе ролей Azure (Azure RBAC) и назначить соответствующую роль для этого удостоверения учетной записи хранения. В этом разделе описано, как выполнить эту задачу с помощью портала Azure и шаблона Azure Resource Manager (ARM). Сведения о Azure PowerShell, Azure CLI и AZURE REST API см. в следующей документации:

Средство Документация
Azure PowerShell Добавление назначения роли
Azure CLI Добавление назначения роли
Azure REST API Добавление назначения роли

Тем не менее, чтобы получить доступ к хранилищу ключей Azure с помощью управляемого удостоверения, необходимо создать политику доступа для этого удостоверения в хранилище ключей и назначить данному удостоверению в этом хранилище ключей соответствующие разрешения. Далее в этом разделе описано, как выполнить эту задачу с помощью портала Azure. Шаблоны Resource Manager, PowerShell и Azure CLI см. в следующей документации:

Средство Документация
Шаблон Azure Resource Manager (шаблон ARM) Определение ресурса политики доступа Key Vault
Azure PowerShell Назначение политики доступа Key Vault
Azure CLI Назначение политики доступа Key Vault

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

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

  1. На портале Azure откройте ресурс, в котором вы хотите использовать удостоверение.

  2. В меню ресурсов выберите элемент Управления доступом (IAM)>Добавить>назначение ролей.

    Примечание.

    Если параметр Добавить назначение ролей отключен, у вас нет разрешений на назначение ролей. Дополнительные сведения см. в статье Встроенные роли Microsoft Entra.

  3. Назначьте необходимую роль управляемому удостоверению. На вкладке Роль назначьте роль, которая предоставляет удостоверению необходимые права доступа к текущему ресурсу.

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

  4. Затем выберите управляемое удостоверение, для которого необходимо назначить роль. В разделе Назначение доступа для выберите Управляемое удостоверение>Добавить участников.

  5. В зависимости от типа управляемого удостоверения выберите или укажите следующие значения:

    Тип Экземпляр службы Azure Отток подписок Элемент
    назначаемые системой; Приложение логики <имя-подписки-Azure> <your-logic-app-name>
    назначаемые пользователями. Нет данных <имя-подписки-Azure> <your-user-assigned-identity-name>

    Дополнительные сведения о назначении ролей см. в разделе "Назначение ролей" с помощью портал Azure.

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

Дополнительные сведения об этой задаче см. в статье "Назначение доступа к управляемому удостоверению" другому ресурсу с помощью Azure RBAC.

Создание политики доступа с помощью портал Azure

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

  1. На портале Azure откройте целевой ресурс, в котором вы хотите использовать удостоверение. В этом примере в качестве целевого ресурса используется хранилище ключей Azure.

  2. В меню ресурсов выберите "Создать политики доступа", которая открывает область "Создать политику> доступа".

    Примечание.

    Если у ресурса нет параметра Политики доступа, попробуйте вместо этого присвоить назначение ролей.

    Снимок экрана: пример портал Azure и хранилища ключей с открытой областью с именем политик доступа.

  3. На вкладке Разрешения выберите разрешения, которые необходимы удостоверению для доступа к целевому ресурсу.

    Например, чтобы использовать удостоверение с операцией секретов списка управляемых соединителей Azure Key Vault, удостоверение должно иметь разрешения списка. Поэтому в столбце Разрешения секретов выберите Список.

    Снимок экрана: вкладка

  4. Затем нажмите кнопку Далее. На вкладке Субъект найдите и выберите управляемое удостоверение, которым в этом примере является назначаемое пользователем удостоверение.

  5. Пропустите необязательный шаг Приложения, нажмите кнопку Далее и завершите создание политики доступа.

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

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

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

Внимание

Если у вас есть функция Azure, в которой вы хотите использовать назначаемое системой удостоверение, сначала включите проверку подлинности для Функций Azure.

Ниже показано, как использовать управляемое удостоверение с триггером или действием с помощью портал Azure. Сведения об указании управляемого удостоверения в базовом определении JSON триггера или действия см. в разделе проверки подлинности управляемого удостоверения.

  1. В портал Azure откройте ресурс приложения логики потребления.

  2. Если вы еще не сделали этого, добавьте триггер или действие, поддерживающее управляемые удостоверения.

    Примечание.

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

  3. Выполните следующие действия с добавленным триггером или действием:

    • Встроенные операции соединителя, поддерживающие проверку подлинности управляемого удостоверения

      Эти действия продолжаются с помощью действия HTTP в качестве примера.

      1. В списке расширенных параметров добавьте свойство Authentication , если свойство еще не отображается.

        Снимок экрана: рабочий процесс потребления со встроенным действием и открытым списком с именем

        Теперь в действии отображаются как свойство проверки подлинности, так и список типов проверки подлинности.

        Снимок экрана: раздел расширенных параметров с добавленным свойством проверки подлинности и списком типов проверки подлинности.

      2. В списке типов проверки подлинности выберите управляемое удостоверение.

        Снимок экрана: рабочий процесс потребления со встроенным действием, открытым списком типов проверки подлинности и выбранным вариантом для управляемого удостоверения.

        Теперь в разделе проверки подлинности показаны следующие параметры:

        • Список управляемых удостоверений, из которого можно выбрать определенное управляемое удостоверение.

        • Свойство Аудитории отображается на определенных триггерах и действиях, чтобы задать идентификатор ресурса для целевого ресурса или службы Azure. В противном случае по умолчанию свойство аудитории будет использовать идентификатор ресурса https://management.azure.com/, который представляет собой идентификатор ресурса для Azure Resource Manager.

      3. В списке управляемых удостоверений выберите удостоверение, которое вы хотите использовать, например:

        Снимок экрана: раздел

        Примечание.

        Выбранный по умолчанию параметр — управляемое удостоверение, назначаемое системой, даже если у вас нет управляемых удостоверений.

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

      Дополнительные сведения см. в разделе Пример проверки подлинности встроенного триггера или действия с управляемым удостоверением.

    • Операции с управляемым соединителем, поддерживающие проверку подлинности с использованием управляемого удостоверения

      1. В области создания Подключение ion в списке проверки подлинности выберите управляемое удостоверение, например:

        Снимок экрана: рабочий процесс потребления с действием Azure Resource Manager и выбранным вариантом для управляемого удостоверения.

      2. На следующей панели для имени Подключение ion укажите имя, используемое для подключения.

      3. Для типа проверки подлинности выберите один из следующих вариантов на основе управляемого соединителя:

        • Одиночная проверка подлинности: эти соединители поддерживают только один тип проверки подлинности, который является управляемым удостоверением в данном случае.

          1. В списке управляемых удостоверений выберите текущее управляемое удостоверение с поддержкой.

          2. Когда вы будете готовы, нажмите кнопку "Создать".

        • Многофакторная проверка подлинности: эти соединители поддерживают несколько типов проверки подлинности, но вы можете выбрать и использовать только один тип одновременно.

          Эти действия продолжаются с помощью действия Хранилище BLOB-объектов Azure в качестве примера.

          1. В списке типов проверки подлинности выберите "Управляемое удостоверение Logic Apps".

            Снимок экрана: рабочий процесс потребления, поле создания подключения и выбранный параметр для управляемого удостоверения Logic Apps.

          2. Когда вы будете готовы, нажмите кнопку "Создать".

        Дополнительные сведения см. в разделе Пример проверки подлинности триггера или действия управляемых соединителей с управляемым удостоверением.

Пример проверки подлинности встроенного триггера или действия с управляемым удостоверением

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

Свойство Обязательное поле Описание
Method Да Метод HTTP, используемый операцией, которую необходимо выполнить
URI-адрес Да URL-адрес конечной точки для доступа к целевому ресурсу или сущности Azure. Синтаксис URI обычно включает идентификатор ресурса для целевого ресурса Или службы Azure.
Заголовки No Любые значения заголовка, которые требуется включить в исходящий запрос, например тип содержимого
Запросы No Любые параметры запроса, которые необходимо включить в запрос. Например, параметры запроса для определенной операции или версии API операции, которую требуется выполнить.
Аутентификация Да Тип проверки подлинности, используемый для проверки подлинности доступа к целевому ресурсу или службе Azure

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

Внимание

Чтобы получить доступ к учетным записям хранения Azure за брандмауэрами с помощью соединителя Хранилище BLOB-объектов Azure и управляемых удостоверений, убедитесь, что вы также настроили учетную запись хранения с исключением, которая разрешает доступ доверенным службы Майкрософт.

Чтобы запустить операцию blob-объекта моментального снимка, действие HTTP указывает следующие свойства:

Свойство Обязательное поле Пример значения Description
URI-адрес Да https://<storage-account-name>/<folder-name>/{name} Идентификатор ресурса для файла хранилища BLOB-объектов Azure в глобальной (общедоступной) среде Azure, который использует этот синтаксис
Method Да PUT Метод HTTP, используемый операцией снимка BLOB-объекта
Заголовки Для службы хранилища Azure x-ms-blob-type = BlockBlob

x-ms-version = 2024-05-05

x-ms-date = formatDateTime(utcNow(),'r')		 Значения заголовков x-ms-blob-type, x-ms-version и x-ms-date, необходимые для операций службы хранилища Azure.

Важно. В исходящих запросах триггера HTTP и действия для служба хранилища Azure заголовок требует x-ms-version свойства и версии API для выполнения операции. Значение x-ms-date должно быть текущей датой. Иначе рабочий процесс выдаст ошибку 403 FORBIDDEN. Чтобы получить текущую дату в требуемом формате, можно использовать пример.

Дополнительные сведения см. в следующей документации:

- Заголовок запроса — снимок BLOB-объекта
- Управление версиями для служб хранилища Azure
Запросы Только для операции Snapshot Blob comp = snapshot Название и значение параметра запроса для операции.

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

    В следующем примере показан пример действия HTTP со всеми ранее описанными значениями свойств, которые используются для операции создания моментального снимка BLOB-объекта:

    Снимок экрана: портал Azure, рабочий процесс потребления и действие HTTP, настроенное для доступа к ресурсам.

  2. В действии HTTP добавьте свойство Authentication . В списке дополнительных параметров выберите "Проверка подлинности".

    Снимок экрана: рабочий процесс потребления с действием HTTP и открытие списка расширенных параметров с выбранным свойством Authentication.

    Теперь раздел проверки подлинности отображается в действииHTTP .

    Примечание.

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

  3. В списке типов проверки подлинности выберите управляемое удостоверение.

    Снимок экрана: рабочий процесс потребления, действие HTTP и свойство типа проверки подлинности с выбранным параметром для управляемого удостоверения.

  4. В списке управляемых удостоверений выберите доступные параметры в зависимости от вашего сценария.

    • Если вы настроили удостоверение, назначаемое системой, выберите управляемое удостоверение, назначаемое системой.

      Снимок экрана: рабочий процесс потребления, действие HTTP и свойство Управляемого удостоверения с выбранным параметром для управляемого удостоверения, назначаемого системой.

    • Если вы настроили удостоверение, назначаемое пользователем, выберите это удостоверение.

      Снимок экрана: рабочий процесс потребления, действие HTTP и свойство Управляемого удостоверения с выбранным удостоверением, назначенным пользователем.

    Этот пример продолжится с управляемым удостоверением, назначаемым системой.

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

    Например, чтобы пройти проверку подлинности доступа к ресурсу Key Vault в глобальном облаке Azure, необходимо задать для свойства Аудитории именно следующий идентификатор ресурса:https://vault.azure.net

    Если свойство Аудитории не задано по умолчанию, свойство Аудитории использует https://management.azure.com/ идентификатор ресурса, который является идентификатором ресурса для Azure Resource Manager.

    Внимание

    Убедитесь, что идентификатор целевого ресурса точно соответствует значению, которое ожидает идентификатор Microsoft Entra. В противном случае может возникнуть 400 Bad Request ошибка или 401 Unauthorized ошибка. Таким образом, если идентификатор ресурса включает в себя все конечные косые черты, обязательно включите их. В противном случае не включайте их.

    Например, для идентификатора ресурса для всех учетных записей хранилища BLOB-объектов Azure требуется завершающая косая черта. Но для идентификатора ресурса конкретной учетной записи хранения завершающая косая черта не требуется. Проверьте идентификаторы ресурсов для служб Azure, поддерживающих идентификатор Microsoft Entra.

    В этом примере свойству аудитории присваивается значение https://storage.azure.com/, чтобы маркеры доступа, используемые для проверки подлинности, были допустимы для всех учетных записей хранения. Однако можно также указать URL-адрес корневой службы для конкретной учетной записи хранения, https://<your-storage-account>.blob.core.windows.net.

    Снимок экрана: рабочий процесс потребления и действие HTTP с свойством аудитории, заданным для идентификатора целевого ресурса.

    Дополнительные сведения о авторизации доступа с помощью идентификатора Microsoft Entra для служба хранилища Azure см. в следующей документации:

  6. Продолжайте создание рабочего процесса нужным вам образом.

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

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

  1. В конструкторе рабочих процессов добавьте действие Azure Resource Manager с именем "Чтение ресурса".

  2. На панели "Создание Подключение ion" в списке проверки подлинности выберите "Управляемое удостоверение" и нажмите кнопку "Войти".

    Примечание.

    В других соединителях список типов проверки подлинности отображает управляемое удостоверение Logic Apps, поэтому выберите этот параметр.

    Снимок экрана: рабочий процесс потребления, действие Azure Resource Manager, открытый список проверки подлинности и выбранный параметр для управляемого удостоверения.

  3. Укажите имя подключения и выберите управляемое удостоверение, которое вы хотите использовать.

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

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

    Снимок экрана: рабочий процесс потребления и действие Azure Resource Manager с указанным именем подключения и выбранным вариантом для управляемого удостоверения, назначаемого системой.

    Примечание.

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

  4. Когда вы будете готовы, нажмите кнопку "Создать".

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

  6. Продолжайте создание рабочего процесса нужным вам образом.

Определение ресурса приложения логики и подключения, использующие управляемое удостоверение

Подключение, которое включает и использует управляемое удостоверение, — это специальный тип подключения, который работает только с управляемым удостоверением. Во время выполнения подключение использует управляемое удостоверение, включенное в ресурсе приложения логики. Azure Logic Apps проверка, настроены ли все операции управляемого соединителя в рабочем процессе для использования управляемого удостоверения и что все необходимые разрешения существуют для доступа к целевым ресурсам, указанным в операциях соединителя. Если эта проверка выполнена успешно, Azure Logic Apps извлекает маркер Microsoft Entra, связанный с управляемым удостоверением, использует это удостоверение для проверки подлинности доступа к целевому ресурсу Azure и выполняет настроенные операции в рабочем процессе.

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

В этом примере показана parameters конфигурация объекта, когда приложение логики включает удостоверение, назначаемое системой:

"parameters": {
   "$connections": {
      "value": {
         "<action-name>": {
            "connectionId": "/subscriptions/<Azure-subscription-ID>/resourceGroups/<resource-group-name>/providers/Microsoft.Web/connections/<connector-name>",
            "connectionName": "<connector-name>",
            "connectionProperties": {
               "authentication": {
                  "type": "ManagedServiceIdentity"
               }
            },
            "id": "/subscriptions/<Azure-subscription-ID>/providers/Microsoft.Web/locations/<Azure-region>/managedApis/<managed-connector-type>"
         }
      }
   }
}

В этом примере показана parameters конфигурация объекта, когда приложение логики включает управляемое удостоверение, назначаемое пользователем:

"parameters": {
   "$connections": {
      "value": {
         "<action-name>": {
            "connectionId": "/subscriptions/<Azure-subscription-ID>/resourceGroups/<resource-group-name>/providers/Microsoft.Web/connections/<connector-name>",
            "connectionName": "<connector-name>",
            "connectionProperties": {
               "authentication": {
                  "type": "ManagedServiceIdentity",
                  "identity": "/subscriptions/<Azure-subscription-ID>/resourceGroups/<resource-group-name>/providers/microsoft.managedidentity/userassignedidentities/<managed-identity-name>"
               }
            },
            "id": "/subscriptions/<Azure-subscription-ID>/providers/Microsoft.Web/locations/<Azure-region>/managedApis/<managed-connector-type>"
         }
      }
   }
}

Шаблон ARM для подключений API и управляемых удостоверений

Если вы используете шаблон ARM для автоматизации развертывания, а рабочий процесс включает подключение API, которое создается управляемым соединителем , использующим управляемое удостоверение, необходимо выполнить дополнительный шаг.

В шаблоне ARM определение ресурса базового соединителя отличается в зависимости от того, есть ли у вас ресурс приложения логики "Потребление" или "Стандартный", а также на том, отображается ли соединитель одиночная проверка подлинности или многофакторная проверка подлинности.

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

Одиночная проверка подлинности

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

  • Свойству kind задано значение V1 для приложения логики категории "Потребление".

  • Свойство parameterValueType имеет значение Alternative.

{
    "type": "Microsoft.Web/connections",
    "apiVersion": "[providers('Microsoft.Web','connections').apiVersions[0]]",
    "name": "[variables('connections_<connector-name>_name')]",
    "location": "[parameters('location')]",
    "kind": "V1",
    "properties": {
        "alternativeParameterValues": {},
        "api": {
            "id": "[subscriptionResourceId('Microsoft.Web/locations/managedApis', parameters('location'), 'azureautomation')]"
        },
        "authenticatedUser": {},
        "connectionState": "Enabled",
        "customParameterValues": {},
        "displayName": "[variables('connections_<connector-name>_name')]",
        "parameterValueSet": {},
        "parameterValueType": "Alternative"
    }
},

Множественная проверка подлинности

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

  • Свойству kind задано значение V1 для приложения логики категории "Потребление".

  • Объект parameterValueSet включает в себя свойство name, для которого задано значение managedIdentityAuth, и свойство values, для которого задан пустой объект.

{
    "type": "Microsoft.Web/connections",
    "apiVersion": "[providers('Microsoft.Web','connections').apiVersions[0]]",
    "name": "[variables('connections_<connector-name>_name')]",
    "location": "[parameters('location')]",
    "kind": "V1",
    "properties": {
        "alternativeParameterValues":{},
        "api": {
            "id": "[subscriptionResourceId('Microsoft.Web/locations/managedApis', parameters('location'), 'azureblob')]"
        },
        "authenticatedUser": {},
        "connectionState": "Enabled",
        "customParameterValues": {},
        "displayName": "[variables('connections_<connector-name>_name')]",
        "parameterValueSet":{
            "name": "managedIdentityAuth",
            "values": {}
        },
        "parameterValueType": "Alternative"
    }
}

Настройка расширенного контроля над проверкой подлинности подключения API

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

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

  • Подключение 1 настроено с проверкой подлинности для внутреннего хранилища токенов.

  • Подключение 2 настроено с проверкой подлинности для целевого ресурса.

Однако если рабочий процесс приложения логики потребления использует подключение API, подключение #1 абстрагируется от вас без каких-либо параметров конфигурации. Благодаря ресурсу приложения логики "Стандартный" вы можете управлять приложением логики и рабочими процессами. По умолчанию подключение 1 автоматически настраивается для использования назначаемого системой удостоверения.

Если в сценарии требуется более подробный контроль над проверкой подлинности подключений API, вы можете дополнительно изменить проверку подлинности для подключения #1 с удостоверения, назначаемого системой по умолчанию, на любое назначаемое пользователем удостоверение, которое вы добавили в приложение логики. Эта проверка подлинности применяется к каждому подключению API, поэтому можно смешивать назначаемые системой и пользователем удостоверения в разных подключениях к одному целевому ресурсу.

В файле connections.json приложения логики уровня "Стандартный", в котором хранятся сведения о каждом подключении API, каждое определение подключения содержит два authentication раздела, например:

"keyvault": {
   "api": {
      "id": "/subscriptions/<Azure-subscription-ID>/providers/Microsoft.Web/locations/<Azure-region>/managedApis/keyvault"
   },
   "authentication": {
      "type": "ManagedServiceIdentity",
   },
   "connection": {
      "id": "/subscriptions/<Azure-subscription-ID>/resourceGroups/<resource-group-name>/providers/Microsoft.Web/connections/<connector-name>"
   },
   "connectionProperties": {
      "authentication": {
         "audience": "https://vault.azure.net",
         "type": "ManagedServiceIdentity"
      }
   },
   "connectionRuntimeUrl": "<connection-runtime-URL>"
}

  • Первый раздел authentication сопоставлен с подключением № 1.

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

  • Второй раздел authentication сопоставлен с подключением № 2.

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

Зачем изменять проверку подлинности для хранилища токенов?

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

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

Изменение проверки подлинности для хранилища токенов

  1. На портале Azure откройте свой ресурс приложения логики категории "Стандартный".

  2. В меню ресурса в разделе Рабочие процессы выберите Подключения.

  3. На панели Подключение ions выберите представление JSON.

    Снимок экрана: портал Azure, ресурс приложения логики

  4. В редакторе JSON найдите раздел managedApiConnections, который содержит подключения API для всех рабочих процессов в ресурсе приложения логики.

  5. Найдите подключение, куда необходимо добавить управляемое удостоверение, назначаемое пользователем.

    Например, предположим, что рабочий процесс имеет подключение к Azure Key Vault:

    "keyvault": {
   "api": {
      "id": "/subscriptions/<Azure-subscription-ID>/providers/Microsoft.Web/locations/<Azure-region>/managedApis/keyvault"
   },
   "authentication": {
      "type": "ManagedServiceIdentity"
   },
   "connection": {
      "id": "/subscriptions/<Azure-subscription-ID>/resourceGroups/<resource-group-name>/providers/Microsoft.Web/connections/<connector-name>"
   },
   "connectionProperties": {
      "authentication": {
         "audience": "https://vault.azure.net",
         "type": "ManagedServiceIdentity"
      }
   },
   "connectionRuntimeUrl": "<connection-runtime-URL>"
}

  6. В определении подключения выполните следующие действия:

    1. Найдите первый раздел authentication. Если в этом authentication разделе нет identity свойства, приложение логики неявно использует удостоверение, назначаемое системой.

    2. Добавьте свойство identity, используя пример на этом шаге.

    3. Задайте в качестве значения свойства идентификатор ресурса для назначаемого пользователем удостоверения.

    "keyvault": {
   "api": {
      "id": "/subscriptions/<Azure-subscription-ID>/providers/Microsoft.Web/locations/<Azure-region>/managedApis/keyvault"
   },
   "authentication": {
      "type": "ManagedServiceIdentity",
      // Add "identity" property here
      "identity": "/subscriptions/<Azure-subscription-ID>/resourcegroups/<resource-group-name>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<identity-resource-ID>"
   },
   "connection": {
      "id": "/subscriptions/<Azure-subscription-ID>/resourceGroups/<resource-group-name>/providers/Microsoft.Web/connections/<connector-name>"
   },
   "connectionProperties": {
      "authentication": {
         "audience": "https://vault.azure.net",
         "type": "ManagedServiceIdentity"
      }
   },
   "connectionRuntimeUrl": "<connection-runtime-URL>"
}

  7. На портале Azure перейдите к целевому ресурсу и предоставьте доступ к управляемому удостоверению, назначаемому пользователем, в зависимости от потребностей целевого ресурса.

    Например, для Azure Key Vault добавьте удостоверение в политики доступа хранилища ключей. Для Хранилища Blob-объектов Azure назначьте необходимую роль для удостоверения учетной записи хранения.

Отключение управляемого удостоверения

Чтобы остановить использование управляемого удостоверения для проверки подлинности, сначала удалите доступ удостоверения к целевому ресурсу. Затем в ресурсе приложения логики отключите назначаемое системой удостоверение или удалите назначаемое пользователем удостоверение.

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

Примечание.

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

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

В этом разделе описано использование портала Azure и шаблона Azure Resource Manager (ARM). Сведения о Azure PowerShell, Azure CLI и AZURE REST API см. в следующей документации:

Средство Документация
Azure PowerShell 1. Удаление назначения ролей.
2. Удаление назначаемого пользователем удостоверения.
Azure CLI 1. Удаление назначения ролей.
2. Удаление назначаемого пользователем удостоверения.
Azure REST API 1. Удаление назначения ролей.
2. Удаление назначаемого пользователем удостоверения.

Дополнительные сведения см. в статье Удаление назначений ролей Azure.

Отключение управляемого удостоверения на портале Azure

Чтобы удалить доступ для управляемого удостоверения, удалите назначение ролей этого удостоверения из целевого ресурса, а затем отключите управляемое удостоверение.

Удаление назначений ролей

Следующие действия позволяют удалить доступ к целевому ресурсу из управляемого удостоверения:

  1. На портале Azure перейдите к ресурсу Azure, у которого вы хотите удалить доступ для управляемого удостоверения.

  2. В меню целевого ресурса выберите Управление доступом (IAM). Выберите под панелью инструментов пункт Назначение ролей.

  3. В списке ролей выберите управляемые удостоверения, которые требуется удалить. На панели инструментов нажмите кнопку Удалить.

    Совет

    Если кнопка Удалить недоступна, скорее всего, у вас нет разрешений. Дополнительные сведения о разрешениях, которые позволяют управлять ролями для ресурсов, см. в разделе о разрешениях роли Администратор istrator в идентификаторе Microsoft Entra.

Отключение управляемого удостоверения в ресурсе приложения логики

  1. Откройте ресурс приложения логики на портале Azure.

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

    • Выберите Назначенное системой>Включено>Сохранить. Когда Azure запросит подтверждение, выберите Да.

    • Выберите Назначаемое пользователем и нужное управляемое удостоверение, а затем нажмите Удалить. Когда Azure запросит подтверждение, выберите Да.

Отключение управляемого удостоверения в шаблоне ARM

Если вы создали управляемое удостоверение приложения логики с помощью шаблона развертывания ARM, задайте свойству type элемента identity значение None.

"identity": {
   "type": "None"
}

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