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

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

  • Статья

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

Примечание.

Начиная с 1 июня 2024 года только что созданные приложения службы приложений могут создать уникальное имя узла по умолчанию, использующее соглашение об именовании <app-name>-<random-hash>.<region>.azurewebsites.net. Например: myapp-ds27dh7271aah175.westus-01.azurewebsites.net. Существующие имена приложений остаются неизменными.

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

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

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

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

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

Примечание.

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

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

Предварительные требования

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

Сценарий Требуемое разрешение Примеры встроенных ролей
Создание системного идентификатора Microsoft.Web/sites/write над приложением или Microsoft.Web/sites/slots/write над слотом Участник веб-сайта
Создать идентификатор, назначаемый пользователем Microsoft.ManagedIdentity/userAssignedIdentities/write по группе ресурсов, в которой создается удостоверение Участник с управляемой идентификацией
Назначьте пользовательскую идентичность для вашего приложения Microsoft.Web/sites/write над приложением, Microsoft.Web/sites/slots/write над слотом или
Microsoft.ManagedIdentity/userAssignedIdentities/*/assign/action по вопросу идентичности		 Автор веб-сайта и Оператор управляемой идентификации
Создание назначений ролей Azure Microsoft.Authorization/roleAssignments/write в пределах целевого диапазона ресурсов Администратор контроля доступа на основе ролей или Администратор доступа пользователей

Добавление идентичности, назначенной системой

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

  1. На портале Azure перейдите на страницу приложения.

  2. В меню слева выберите «Параметры»>«Идентификация».

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

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

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

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

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

  3. Выберите "Назначенный пользователем", а затем нажмите кнопку "Добавить".

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

После выполнения этих действий приложение перезагружается.

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

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

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

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

Внимание

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

Альтернативы группам или членству в ролях см. в разделе Ограничение использования управляемых удостоверений для авторизации.

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

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

Служба приложений и Функции Azure предоставляют внутренне доступную конечную точку REST для получения токена. Доступ к конечной точке REST можно получить из приложения с помощью стандартного HTTP-запроса GET . Запрос можно реализовать с помощью универсального HTTP-клиента на каждом языке.

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

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

GET /MSI/token?resource=https://vault.azure.net&api-version=2019-08-01 HTTP/1.1
Host: <ip-address-:-port-in-IDENTITY_ENDPOINT>
X-IDENTITY-HEADER: <value-of-IDENTITY_HEADER>

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

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": "00001111-aaaa-2222-bbbb-3333cccc4444"
}

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

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

Удалить учетную запись

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

  1. В меню слева на странице приложения выберите Настройки>Удостоверения.

  2. Выполните действия, основанные на типе удостоверения:

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

Примечание.

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

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

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

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

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

Наименование параметра В Описание
resource Запрос URI ресурса Microsoft Entra для ресурса, для которого должен быть получен токен. Этот ресурс может быть одним из служб Azure, поддерживающих проверку подлинности Microsoft Entra или любой другой URI ресурса.
api-version Запрос Версия API токенов, которая будет использоваться. Используйте 2019-08-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) опущены, используется назначаемое системой удостоверение.

Внимание

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

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

Рассмотрим следующие руководства: