Использование управляемых удостоверений в Службе приложений и Функциях Azure

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

Важно!

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

Примечание

Для приложений, развернутых в службе Azure Arc, управляемые удостоверения недоступны.

Управляемое удостоверение от Azure Active Directory (Azure AD) позволяет приложению легко получать доступ к другим ресурсам, защищенным Azure AD, таким как Azure Key Vault. Удостоверения управляются платформой Azure, и для них не нужно подготавливать или изменять секреты. Дополнительные сведения об управляемых удостоверениях в Azure AD см. в статье Что такое управляемые удостоверения для ресурсов Azure?

Приложению можно предоставить два типа удостоверений:

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

Добавление назначаемого системой удостоверения

Чтобы создать приложение с назначаемым системой удостоверением, необходимо задать дополнительное свойство в приложении.

Использование портала Azure

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

  1. Создайте приложение на портале обычным образом. Перейдите к нему на портале.

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

  3. Выберите Удостоверение.

  4. На вкладке Назначено системой для параметра Состояние установите значение Вкл. Выберите команду Сохранить.

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

Примечание

Чтобы найти управляемое удостоверение для веб-приложения или слотового приложения на портале Azure, в области Корпоративные приложения выберите Параметры пользователя. Обычно имя слота похоже на <app name>/slots/<slot name>.

Использование Azure CLI

Чтобы настроить управляемое удостоверение с помощью Azure CLI, используйте команду az webapp identity assign для имеющегося приложения. Примеры из этого раздела можно выполнять тремя способами:

  • использовать Azure Cloud Shell с портала Azure;
  • использовать внедренный компонент Azure Cloud Shell с помощью кнопки "Попробовать", расположенной в правом верхнем углу каждого блока кода ниже.
  • установить последнюю версию Azure CLI (2.0.31 или выше), если вы предпочитаете использовать локальную консоль CLI.

Ниже описаны действия по созданию веб-приложения и присвоению удостоверения ему с помощью CLI:

  1. Если вы используете Azure CLI в локальной консоли, сначала выполните вход в Azure с помощью команды az login. Используйте учетную запись, связанную с подпиской Azure, с помощью которой нужно развернуть приложение:

    az login
    
  2. Создайте веб-приложение с помощью CLI. Дополнительные примеры использования CLI со службой приложений см. в статье Примеры Azure CLI.

    az group create --name myResourceGroup --location westus
    az appservice plan create --name myPlan --resource-group myResourceGroup --sku S1
    az webapp create --name myApp --resource-group myResourceGroup --plan myPlan
    
  3. Выполните команду identity assign, чтобы создать удостоверение для этого приложения.

    az webapp identity assign --name myApp --resource-group myResourceGroup
    

Использование Azure PowerShell

Примечание

Эта статья была изменена, и теперь в ней содержатся сведения о модуле Az PowerShell для Azure. Модуль Az PowerShell является рекомендуемым модулем PowerShell для взаимодействия с Azure. Чтобы начать работу с модулем Az PowerShell, ознакомьтесь со статьей Установка Azure PowerShell. Дополнительные сведения см. в статье Перенос Azure PowerShell с AzureRM на Az.

Ниже описаны действия по созданию приложения и присвоению ему удостоверения с помощью Azure PowerShell. Инструкции по созданию веб-приложения и приложения-функции различаются.

Использование Azure PowerShell для веб-приложения

  1. При необходимости установите Azure PowerShell с помощью инструкций из руководства по Azure PowerShell, а затем выполните команду Login-AzAccount, чтобы создать подключение к Azure.

  2. Создайте веб-приложение с помощью Azure PowerShell. Дополнительные примеры применения Azure PowerShell со службой приложений см. в статье Примеры сценариев Azure PowerShell.

    # Create a resource group.
    New-AzResourceGroup -Name $resourceGroupName -Location $location
    
    # Create an App Service plan in Free tier.
    New-AzAppServicePlan -Name $webappname -Location $location -ResourceGroupName $resourceGroupName -Tier Free
    
    # Create a web app.
    New-AzWebApp -Name $webappname -Location $location -AppServicePlan $webappname -ResourceGroupName $resourceGroupName
    
  3. Выполните команду Set-AzWebApp -AssignIdentity, чтобы создать удостоверение для этого приложения.

    Set-AzWebApp -AssignIdentity $true -Name $webappname -ResourceGroupName $resourceGroupName 
    

Использование Azure PowerShell для приложения-функции

  1. При необходимости установите Azure PowerShell с помощью инструкций из руководства по Azure PowerShell, а затем выполните команду Login-AzAccount, чтобы создать подключение к Azure.

  2. Создайте приложение-функцию с помощью Azure PowerShell. Дополнительные примеры использования Azure PowerShell с решением "Функции Azure" см. в справочнике по решению "Функции Azure":

    # Create a resource group.
    New-AzResourceGroup -Name $resourceGroupName -Location $location
    
    # Create a storage account.
    New-AzStorageAccount -Name $storageAccountName -ResourceGroupName $resourceGroupName -SkuName $sku
    
    # Create a function app with a system-assigned identity.
    New-AzFunctionApp -Name $functionAppName -ResourceGroupName $resourceGroupName -Location $location -StorageAccountName $storageAccountName -Runtime $runtime -IdentityType SystemAssigned
    

Также можно обновить существующее приложение-функцию с помощью Update-AzFunctionApp.

Использование шаблона Azure Resource Manager

Шаблон Azure Resource Manager можно использовать для автоматизации развертывания ресурсов Azure. Дополнительные сведения о развертывании в службе приложений и Функциях см. в статьях Предсказуемые подготовка и развертывание микрослужб в Azure и Автоматизация развертывания ресурсов приложения-функции для службы "Функции Azure".

Любой ресурс типа Microsoft.Web/sites можно создать с помощью удостоверения, добавив следующее свойство в определение ресурса:

"identity": {
    "type": "SystemAssigned"
}

Примечание

Приложение может иметь назначаемое системой и назначаемое пользователем удостоверения одновременно. В этом случае для свойства type будет задано значение SystemAssigned,UserAssigned.

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

Например, веб-приложение может выглядеть следующим образом:

{
    "apiVersion": "2016-08-01",
    "type": "Microsoft.Web/sites",
    "name": "[variables('appName')]",
    "location": "[resourceGroup().location]",
    "identity": {
        "type": "SystemAssigned"
    },
    "properties": {
        "name": "[variables('appName')]",
        "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', variables('hostingPlanName'))]",
        "hostingEnvironment": "",
        "clientAffinityEnabled": false,
        "alwaysOn": true
    },
    "dependsOn": [
        "[resourceId('Microsoft.Web/serverfarms', variables('hostingPlanName'))]"
    ]
}

Созданный сайт будет иметь следующие дополнительные свойства:

"identity": {
    "type": "SystemAssigned",
    "tenantId": "<TENANTID>",
    "principalId": "<PRINCIPALID>"
}

Свойство tenantId определяет, к какому клиенту Azure AD относится это удостоверение. principalId — это уникальный идентификатор для нового удостоверения приложения. В Azure AD субъект-служба имеет то же имя, которое вы присвоили экземпляру Службы приложений или Функций Azure.

Если необходимо сослаться на эти свойства в шаблоне на более позднем этапе, можно использовать reference()функцию шаблона с флагом'Full', как в следующем примере:

{
    "tenantId": "[reference(resourceId('Microsoft.Web/sites', variables('appName')), '2018-02-01', 'Full').identity.tenantId]",
    "objectId": "[reference(resourceId('Microsoft.Web/sites', variables('appName')), '2018-02-01', 'Full').identity.principalId]",
}

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

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

Использование портала Azure

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

  1. Создайте ресурс назначаемого пользователем управляемого удостоверения в соответствии с этими инструкциями.

  2. Создайте приложение на портале обычным образом. Перейдите к нему на портале.

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

  4. Выберите Удостоверение.

  5. На вкладке Назначаемое пользователем щелкните Добавить.

  6. Найдите созданное ранее удостоверение и выберите его. Нажмите кнопку Добавить.

    Управляемое удостоверение в Службе приложений

Использование Azure PowerShell

Примечание

Эта статья была изменена, и теперь в ней содержатся сведения о модуле Az PowerShell для Azure. Модуль Az PowerShell является рекомендуемым модулем PowerShell для взаимодействия с Azure. Чтобы начать работу с модулем Az PowerShell, ознакомьтесь со статьей Установка Azure PowerShell. Дополнительные сведения см. в статье Перенос Azure PowerShell с AzureRM на Az.

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

Примечание

Текущая версия командлетов Azure PowerShell для службы приложений Azure не поддерживает назначаемые пользователями удостоверения. Ниже приведены инструкции для решения "Функции Azure".

  1. При необходимости установите Azure PowerShell с помощью инструкций из руководства по Azure PowerShell, а затем выполните команду Login-AzAccount, чтобы создать подключение к Azure.

  2. Создайте приложение-функцию с помощью Azure PowerShell. Дополнительные примеры использования Azure PowerShell с решением "Функции Azure" см. в справочнике по решению "Функции Azure". Приведенный ниже сценарий также использует New-AzUserAssignedIdentity, который должен быть установлен отдельно в соответствии со статьей Создание, отображение и удаление назначаемых пользователями управляемых удостоверений с помощью Azure PowerShell.

    # Create a resource group.
    New-AzResourceGroup -Name $resourceGroupName -Location $location
    
    # Create a storage account.
    New-AzStorageAccount -Name $storageAccountName -ResourceGroupName $resourceGroupName -SkuName $sku
    
    # Create a user-assigned identity. This requires installation of the "Az.ManagedServiceIdentity" module.
    $userAssignedIdentity = New-AzUserAssignedIdentity -Name $userAssignedIdentityName -ResourceGroupName $resourceGroupName
    
    # Create a function app with a user-assigned identity.
    New-AzFunctionApp -Name $functionAppName -ResourceGroupName $resourceGroupName -Location $location -StorageAccountName $storageAccountName -Runtime $runtime -IdentityType UserAssigned -IdentityId $userAssignedIdentity.Id
    

Также можно обновить существующее приложение-функцию с помощью Update-AzFunctionApp.

Использование шаблона Azure Resource Manager

Шаблон Azure Resource Manager можно использовать для автоматизации развертывания ресурсов Azure. Дополнительные сведения о развертывании в службе приложений и Функциях см. в статьях Предсказуемые подготовка и развертывание микрослужб в Azure и Автоматизация развертывания ресурсов приложения-функции для службы "Функции Azure".

Любой ресурс типа Microsoft.Web/sites можно создать с помощью удостоверения, добавив следующий блок в определение ресурса, заменив <RESOURCEID> идентификатором ресурса необходимого удостоверения:

"identity": {
    "type": "UserAssigned",
    "userAssignedIdentities": {
        "<RESOURCEID>": {}
    }
}

Примечание

Приложение может иметь назначаемое системой и назначаемое пользователем удостоверения одновременно. В этом случае для свойства type будет задано значение SystemAssigned,UserAssigned.

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

Например, веб-приложение может выглядеть следующим образом:

{
    "apiVersion": "2016-08-01",
    "type": "Microsoft.Web/sites",
    "name": "[variables('appName')]",
    "location": "[resourceGroup().location]",
    "identity": {
        "type": "UserAssigned",
        "userAssignedIdentities": {
            "[resourceId('Microsoft.ManagedIdentity/userAssignedIdentities', variables('identityName'))]": {}
        }
    },
    "properties": {
        "name": "[variables('appName')]",
        "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', variables('hostingPlanName'))]",
        "hostingEnvironment": "",
        "clientAffinityEnabled": false,
        "alwaysOn": true
    },
    "dependsOn": [
        "[resourceId('Microsoft.Web/serverfarms', variables('hostingPlanName'))]",
        "[resourceId('Microsoft.ManagedIdentity/userAssignedIdentities', variables('identityName'))]"
    ]
}

Созданный сайт будет иметь следующие дополнительные свойства:

"identity": {
    "type": "UserAssigned",
    "userAssignedIdentities": {
        "<RESOURCEID>": {
            "principalId": "<PRINCIPALID>",
            "clientId": "<CLIENTID>"
        }
    }
}

principalId — это уникальный идентификатор удостоверения, используемый для администрирования Azure AD. clientId — это уникальный идентификатор нового удостоверения приложения, который используется для того, чтобы указать, какое удостоверение следует использовать во время вызовов среды выполнения.

Получение маркеров для ресурсов Azure

Приложение может использовать управляемое удостоверение для получения маркеров доступа к другим ресурсам, защищенным Azure AD (например, Azure Key Vault). Эти маркеры представляют приложение, получающее доступ к ресурсам, а не конкретного пользователя приложения.

Чтобы разрешить доступ из приложения, необходимо настроить целевой ресурс. Например, если вы запрашиваете маркер для получения доступа к Key Vault, необходимо добавить политику доступа, включающую в себя удостоверение приложения. В противном случае вызовы Key Vault будут отклонены, даже если они включают маркеры. Чтобы узнать больше о том, какие ресурсы поддерживают маркеры Azure Active Directory, см. сведения в разделе о службах Azure, поддерживающих аутентификацию Azure AD.

Важно!

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

Существует простой протокол REST для получения маркера в службе приложений и Функциях Azure. Его можно использовать для всех приложений и языков. Для .NET и Java пакет Azure SDK предоставляет абстракцию для работы с этим протоколом и упрощает процесс разработки в локальной среде.

Использование протокола REST

Примечание

В более старой версии этого протокола, поддерживающей версию API "2017-09-01", использовался заголовок secret вместо X-IDENTITY-HEADER и принималось только свойство clientid для назначаемого пользователем удостоверения. В ней также возвращался параметр expires_on в формате метки времени. MSI_ENDPOINT можно использовать в качестве псевдонима для IDENTITY_ENDPOINT, а MSI_SECRET — в качестве псевдонима для IDENTITY_HEADER. В настоящее время для планов размещения "Потребление Linux" эта версия протокола является обязательной.

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

  • IDENTITY_ENDPOINT — URL-адрес локальной службы токенов.
  • IDENTITY_HEADER — заголовок, который используется для противостояния атакам с подделкой серверных запросов (SSRF). Это значение меняется платформой.

IDENTITY_ENDPOINT — это локальный URL-адрес, из которого приложение может запрашивать маркеры. Чтобы получить маркер для ресурса, отправьте запрос HTTP GET к этой конечной точке, задав следующие параметры:

Имя параметра В Описание
ресурс Запрос Универсальный код ресурса (URI) Azure AD, для которого нужно получить маркер. Это может быть URI одной из служб Azure, которая поддерживает аутентификацию Azure AD, или любой другой URI ресурса.
api-version Запрос Версия API маркеров, которая будет использоваться. Используйте версию 2019-08-01 или более позднюю версию (кроме случаев использования плана "Потребление Linux", для которого в настоящее время доступна только версия 2017-09-01, см. примечание выше).
X-IDENTITY-HEADER Заголовок Значение переменной среды IDENTITY_HEADER. Заголовок, который используется при устранении атак с подделкой серверных запросов (SSRF).
client_id Запрос (Необязательно.) Идентификатор клиента назначаемого пользователем удостоверения, которое следует использовать. Не может использоваться для запроса, который включает в себя идентификатор principal_id, mi_res_idили object_id. Если все параметры ИД (client_id, principal_id, object_id и mi_res_id) опущены, используется назначаемое системой удостоверение.
principal_id Запрос (Необязательно.) Идентификатор субъекта назначаемого пользователем удостоверения, которое следует использовать. object_id — псевдоним, который можно использовать вместо этого. Не может использоваться для запроса, который включает в себя идентификатор client_id, mi_res_id или object_id. Если все параметры ИД (client_id, principal_id, object_id и mi_res_id) опущены, используется назначаемое системой удостоверение.
mi_res_id Запрос (Необязательно.) Идентификатор ресурса Azure для назначаемого пользователем удостоверения, которое следует использовать. Не может использоваться для запроса, который включает в себя идентификатор principal_id, client_idили object_id. Если все параметры ИД (client_id, principal_id, object_id и mi_res_id) опущены, используется назначаемое системой удостоверение.

Важно!

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

Успешный ответ 200 — OK включает текст JSON со следующими свойствами:

Имя свойства Описание
access_token Запрашиваемый маркер доступа. Вызывающая веб-служба может использовать этот маркер для проверки подлинности принимающей веб-службы.
client_id Идентификатор клиента используемого удостоверения.
expires_on Период времени после истечения срока действия маркера доступа. Дата представляется как количество секунд с 1970-01-01T0:0:0Z в формате UTC (соответствует утверждению exp маркера).
not_before Период времени, когда маркер доступа вступает в силу и может быть принят. Дата представляется как количество секунд с 1970-01-01T0:0:0Z в формате UTC (соответствует утверждению nbf маркера).
ресурс Ресурс, для которого был запрошен маркер доступа, соответствует параметру строки запроса resource.
token_type Указывает значение типа маркера. Единственный тип, поддерживаемый Azure AD — носитель. Дополнительные сведения о маркерах носителей см. в спецификации OAuth 2.0 Authorization Framework: Bearer Token Usage (RFC 6750) (OAuth2.0 Authorization Framework: использование маркера носителя (RFC 6750)).

Этот ответ совпадает с ответом для запроса маркера взаимного доступа между службами Azure AD.

Примеры протокола REST

Пример запроса может выглядеть следующим образом:

GET /MSI/token?resource=https://vault.azure.net&api-version=2019-08-01 HTTP/1.1
Host: localhost:4141
X-IDENTITY-HEADER: 853b9a84-5bfa-4b22-a3f3-0b9a43d9ad8a

Пример ответа может выглядеть следующим образом:

HTTP/1.1 200 OK
Content-Type: application/json

{
    "access_token": "eyJ0eXAi…",
    "expires_on": "1586984735",
    "resource": "https://vault.azure.net",
    "token_type": "Bearer",
    "client_id": "5E29463D-71DA-4FE0-8E69-999B57DB23B0"
}

Примеры кода

Совет

Для языков .NET можно также использовать пакет Microsoft.Azure.Services.AppAuthentication, вместо того чтобы создавать этот запрос самостоятельно.

private readonly HttpClient _client;
// ...
public async Task<HttpResponseMessage> GetToken(string resource)  {
    var request = new HttpRequestMessage(HttpMethod.Get, 
        String.Format("{0}/?resource={1}&api-version=2019-08-01", Environment.GetEnvironmentVariable("IDENTITY_ENDPOINT"), resource));
    request.Headers.Add("X-IDENTITY-HEADER", Environment.GetEnvironmentVariable("IDENTITY_HEADER"));
    return await _client.SendAsync(request);
}

Использование библиотеки Microsoft.Azure.Services.AppAuthentication для .NET

Самый простой способ для приложений и функций .NET работать с управляемыми удостоверениями заключается в использовании пакета Microsoft.Azure.Services.AppAuthentication. Эта библиотека также позволяет локально тестировать код на компьютере разработки с использованием учетной записи пользователя из Visual Studio, Azure CLI или встроенной проверки подлинности Active Directory. При размещении в облаке по умолчанию будет использоваться удостоверение, назначенное системой. Это поведение можно изменить с помощью переменной среды в строке подключения, которая ссылается на идентификатор клиента назначенного пользователем удостоверения. Сведения о параметрах разработки с помощью этой библиотеки см. в [Справочнике по Microsoft.Azure.Services.AppAuthentication]. В этом разделе показано, как начать работу с библиотекой в коде.

  1. Добавьте ссылки на пакет Microsoft.Azure.Services.AppAuthentication и другие пакеты NuGet в приложение. В примерах ниже также используется Microsoft.Azure.KeyVault.

  2. Добавьте приведенный ниже код в приложение, указав необходимый целевой ресурс. В этом примере показано два способа работы с Azure Key Vault:

    using Microsoft.Azure.Services.AppAuthentication;
    using Microsoft.Azure.KeyVault;
    // ...
    var azureServiceTokenProvider = new AzureServiceTokenProvider();
    string accessToken = await azureServiceTokenProvider.GetAccessTokenAsync("https://vault.azure.net");
    // OR
    var kv = new KeyVaultClient(new KeyVaultClient.AuthenticationCallback(azureServiceTokenProvider.KeyVaultTokenCallback));
    

Чтобы использовать управляемое удостоверение, назначаемое пользователем, можно установить для параметра приложения AzureServicesAuthConnectionString значение RunAs=App;AppId=<clientId-guid>. Замените <clientId-guid> на идентификатор клиента удостоверения, который нужно использовать. Можно определить множество таких строк подключения, используя настраиваемые параметры приложения и передавая их значения в конструктор AzureServiceTokenProvider.

    var identityConnectionString1 = Environment.GetEnvironmentVariable("UA1_ConnectionString");
    var azureServiceTokenProvider1 = new AzureServiceTokenProvider(identityConnectionString1);
    
    var identityConnectionString2 = Environment.GetEnvironmentVariable("UA2_ConnectionString");
    var azureServiceTokenProvider2 = new AzureServiceTokenProvider(identityConnectionString2);

Дополнительные сведения о настройке AzureServiceTokenProvider и о предоставляемых им операциях см. в [Справочнике Microsoft.Azure.Services.AppAuthentication] и в примерах службы приложений и хранилищ ключей с MSI .NET.

Использование пакета Azure SDK для Java

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

  1. Добавьте ссылку на библиотеку Azure SDK. В проектах Maven можно добавить в раздел dependencies файла POM вашего проекта следующий фрагмент кода:

    <dependency>
        <groupId>com.microsoft.azure</groupId>
        <artifactId>azure</artifactId>
        <version>1.23.0</version>
    </dependency>
    
  2. Для проверки подлинности используйте объект AppServiceMSICredentials. Следующий пример демонстрирует, как можно использовать этот механизм для работы с Azure Key Vault:

    import com.microsoft.azure.AzureEnvironment;
    import com.microsoft.azure.management.Azure;
    import com.microsoft.azure.management.keyvault.Vault
    //...
    Azure azure = Azure.authenticate(new AppServiceMSICredentials(AzureEnvironment.AZURE))
            .withSubscription(subscriptionId);
    Vault myKeyVault = azure.vaults().getByResourceGroup(resourceGroup, keyvaultName);
    
    

Удаление удостоверения

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

Если назначаемое системой удостоверение удаляется таким способом, то оно также удаляется и из Azure AD. Назначаемые системой удостоверения также автоматически удаляются из Azure AD, когда удаляется ресурс приложения.

Удаление всех удостоверений в шаблоне ARM:

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

Удаление всех удостоверений в Azure PowerShell (только Функции Azure):

# Update an existing function app to have IdentityType "None".
Update-AzFunctionApp -Name $functionAppName -ResourceGroupName $resourceGroupName -IdentityType None

Примечание

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

Дальнейшие действия