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

  • Статья

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

Внимание

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

Примечание.

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

Управляемое удостоверение из идентификатора Microsoft Entra позволяет приложению легко получить доступ к другим защищенным ресурсам Microsoft Entra, таким как Azure Key Vault. Удостоверения управляются платформой Azure, и для них не нужно подготавливать или изменять секреты. Дополнительные сведения об управляемых удостоверениях в идентификаторе Microsoft Entra см. в разделе "Управляемые удостоверения" для ресурсов Azure.

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

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

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

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

Действия в видео также описаны в следующих разделах.

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

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

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

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

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

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

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

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

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

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

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

  4. Выберите "Назначаемое пользователем>" добавление.

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

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

    После нажатия кнопки "Добавить" приложение перезапускается.

Настройка целевого ресурса

Вам может потребоваться настроить целевой ресурс, чтобы разрешить к нему доступ из приложения или функции. Например, если вы запрашиваете маркер для доступа к Key Vault, необходимо также добавить политику доступа, включающую в себя управляемое удостоверение приложения или функции. В противном случае вызовы Key Vault будут отклоняться даже при использовании действительного маркера. Это же справедливо и для Базы данных SQL Azure. Дополнительные сведения о том, какие ресурсы поддерживают токены Microsoft Entra, см. в службах Azure, поддерживающих проверку подлинности Microsoft Entra.

Внимание

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

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

С помощью управляемого удостоверения приложение может получить маркеры для ресурсов Azure, защищенных идентификатором Microsoft Entra, например База данных SQL Azure, Azure Key Vault и служба хранилища Azure. Эти маркеры представляют приложение, получающее доступ к ресурсам, а не конкретного пользователя приложения.

Служба приложений и Функции Azure предоставляют внутренне доступную конечную точку REST для получения маркера. К конечной точке RESTFUL можно обращаться из приложения с помощью стандартного HTTP-запроса GET, что можно реализовать с помощью универсального HTTP-клиента на каждом языке. Для .NET, JavaScript, Java и Python клиентская библиотека удостоверений Azure предоставляет абстракцию для этой конечной точки REST и упрощает процесс разработки. Подключение к другим службам Azure выполняется так же просто, как добавление объекта учетных данных в клиент для конкретной службы.

Необработанный запрос HTTP GET выглядит так, как показано в следующем примере.

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"
}

Этот ответ совпадает с ответом на запрос маркера доступа microsoft Entra для службы к службе. Чтобы получить доступ к Key Vault, вам нужно будет затем добавить значение access_token в клиентское подключение к хранилищу.

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

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

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

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

  2. Выберите Удостоверение. Затем выполните следующие действия в зависимости от типа удостоверения.

    • Удостоверение, назначаемое системой: на вкладке Назначается системой переключите состояние на Off. Нажмите кнопку Сохранить.
    • Удостоверение, назначаемое пользователем: перейдите на вкладку Назначается пользователем, установите флажок для удостоверения и нажмите Удалить. Выберите Да для подтверждения.

Примечание.

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

Справочник по конечным точкам REST

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

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

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

Наименование параметра In Description
resource Query URI ресурса Microsoft Entra ресурса ресурса, для которого должен быть получен маркер. Это может быть одна из служб Azure, поддерживающих проверку подлинности Microsoft Entra или любой другой URI ресурса.
api-version Query Версия API маркеров, которая будет использоваться. Используйте 2019-08-01.
X-IDENTITY-HEADER Верхний колонтитул Значение переменной среды IDENTITY_HEADER. Заголовок, который используется при устранении атак с подделкой серверных запросов (SSRF).
client_id Query (Необязательно.) Идентификатор клиента назначаемого пользователем удостоверения, которое следует использовать. Не может использоваться для запроса, который включает в себя идентификатор principal_id, mi_res_idили object_id. Если все параметры ИД (client_id, principal_id, object_id и mi_res_id) опущены, используется назначаемое системой удостоверение.
principal_id Query (Необязательно.) Идентификатор субъекта назначаемого пользователем удостоверения, которое следует использовать. object_id — псевдоним, который можно использовать вместо этого. Не может использоваться для запроса, который включает в себя идентификатор client_id, mi_res_id или object_id. Если все параметры ИД (client_id, principal_id, object_id и mi_res_id) опущены, используется назначаемое системой удостоверение.
mi_res_id Query (Необязательно.) Идентификатор ресурса Azure для назначаемого пользователем удостоверения, которое следует использовать. Не может использоваться для запроса, который включает в себя идентификатор principal_id, client_idили object_id. Если все параметры ИД (client_id, principal_id, object_id и mi_res_id) опущены, используется назначаемое системой удостоверение.

Внимание

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

Следующие шаги