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

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

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

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

Для чего нужны управляемые удостоверения?

Управляемое удостоверение можно использовать в работающем приложении контейнера для проверки подлинности в любой службе, поддерживающей проверку подлинности Microsoft Entra.

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

• приложение подключается к ресурсам с помощью управляемого удостоверения. Вам не нужно управлять учетными данными в приложении-контейнере.
• управление доступом на основе ролей можно использовать для предоставления определенных разрешений управляемому удостоверению;
• назначаемые системой удостоверения создаются и управляются автоматически. Они удаляются при удалении приложения-контейнера.
• вы можете добавлять и удалять удостоверения, назначаемые пользователем, и назначать их нескольким ресурсам. Они не зависят от жизненного цикла приложения-контейнера.
• Управляемое удостоверение можно использовать для проверки подлинности с помощью частного Реестр контейнеров Azure без имени пользователя и пароля для извлечения контейнеров для приложения-контейнера.
• Управляемое удостоверение можно использовать для создания подключений для приложений с поддержкой Dapr с помощью компонентов Dapr.

Распространенные варианты использования

Удостоверения, назначаемые системой, лучше всего подходит для рабочих нагрузок, которые:

• содержатся в одном ресурсе;
• требуют независимых удостоверений.

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

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

Ограничения

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

Контейнеры Init не могут получить доступ к управляемым удостоверениям.

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

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

• портала Azure
• Интерфейс командной строки Azure
• Шаблон Azure Resource Manager (ARM)

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

Примечание.

При добавлении управляемого удостоверения в приложение-контейнер, развернутое до 11 апреля 2022 г., необходимо создать новую редакцию.

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

Портал Azure

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

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

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

Azure CLI

Выполните команду az containerapp identity assign, чтобы создать удостоверение, назначаемое системой.

az containerapp identity assign --name myApp --resource-group myResourceGroup --system-assigned

Шаблон ARM

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

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

При добавлении назначаемого системой удостоверения Azure создает удостоверение для приложения и управляет им. Полный пример шаблона ARM см. в спецификации API ARM.

YAML

Некоторые команды Azure CLI, включая az containerapp create и az containerapp job createподдержку файлов YAML для ввода. Чтобы добавить удостоверение, назначаемое системой, добавьте identity раздел в файл YAML.

identity:
  type: SystemAssigned

При добавлении назначаемого системой удостоверения Azure создает удостоверение для приложения и управляет им. Полный пример шаблона YAML см. в спецификации API ARM.

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

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

Портал Azure

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

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

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

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

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

5. Найдите созданное ранее удостоверение и выберите его. Выберите Добавить.

Azure CLI

1. Создайте удостоверение, назначаемое пользователем.

   az identity create --resource-group <GROUP_NAME> --name <IDENTITY_NAME> --output json
   

   Обратите внимание на свойство id нового удостоверения.

2. Выполните команду az containerapp identity assign, чтобы назначить удостоверение приложению. Параметр удостоверений — это разделенный пробелами список.

   az containerapp identity assign --resource-group <GROUP_NAME> --name <APP_NAME> \
       --user-assigned <IDENTITY_RESOURCE_ID>
   

   Замените <IDENTITY_RESOURCE_ID> свойством id удостоверения. Чтобы назначить несколько удостоверений, назначаемых пользователем, укажите разделенный пробелами список идентификаторов удостоверений в качестве значения параметра --user-assigned.

Шаблон ARM

Чтобы добавить одно или несколько удостоверений, назначаемых пользователем, добавьте раздел identity в шаблон ARM. Замените <IDENTITY1_RESOURCE_ID> и <IDENTITY2_RESOURCE_ID> идентификаторами ресурсов удостоверений, которые вы хотите добавить.

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

"identity": {
    "type": "UserAssigned",
    "userAssignedIdentities": {
        "<IDENTITY1_RESOURCE_ID>": {},
        "<IDENTITY2_RESOURCE_ID>": {}
    }
}

Полный пример шаблона ARM см. в спецификации API ARM.

Примечание.

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

YAML

Чтобы добавить одно или несколько удостоверений, назначенных пользователем, добавьте identity раздел в файл конфигурации YAML. Замените <IDENTITY1_RESOURCE_ID> и <IDENTITY2_RESOURCE_ID> идентификаторами ресурсов удостоверений, которые вы хотите добавить.

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

identity:
    type: UserAssigned
    userAssignedIdentities:
        <IDENTITY1_RESOURCE_ID>: {}
        <IDENTITY2_RESOURCE_ID>: {}

Полный пример шаблона YAML см. в спецификации API ARM.

Примечание.

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

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

Чтобы предоставить доступ, для некоторых ресурсов потребуется настроить назначения ролей для управляемого удостоверения приложения. В противном случае вызовы из приложения к службам, таким как Azure Key Vault и База данных SQL Azure, будут отклонены даже при использовании допустимого маркера для этого удостоверения. Дополнительные сведения об управлении доступом на основе ролей Azure (Azure RBAC) см. в этой статье. Дополнительные сведения о том, какие ресурсы поддерживают токены Microsoft Entra, см. в службах Azure, поддерживающих проверку подлинности Microsoft Entra.

Важно!

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

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

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

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

Примечание.

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

.NET

Примечание.

При подключении к источникам данных Azure SQL с помощью Entity Framework Core рекомендуется использовать Microsoft.Data.SqlClient, который предоставляет специальные строки подключения для подключения с помощью управляемого удостоверения.

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

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

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

JavaScript

Для приложений Node.js самый простой способ работы с управляемым удостоверением заключается в использовании клиентской библиотеки удостоверений Azure для JavaScript. Дополнительные сведения см. в документации с соответствующими заголовками из клиентской библиотеки:

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

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

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

Python

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

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

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

Java

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

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

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

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

PowerShell

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

$resourceURI = "https://<AAD-resource-URI>"
$tokenAuthURI = $env:IDENTITY_ENDPOINT + "?resource=$resourceURI&api-version=2019-08-01"
$tokenResponse = Invoke-RestMethod -Method Get -Headers @{"X-IDENTITY-HEADER"="$env:IDENTITY_HEADER"} -Uri $tokenAuthURI
$accessToken = $tokenResponse.access_token

HTTP GET

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

Получите URL-адрес конечной точки маркера из переменной IDENTITY_ENDPOINT среды. x-identity-header содержит GUID, хранящийся в переменной IDENTITY_HEADER среды.

GET http://localhost:42356/msi/token?resource=https://vault.azure.net&api-version=2019-08-01 HTTP/1.1
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

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

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

Чтобы получить маркер ресурса, выполните 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) опущены, используется назначаемое системой удостоверение.

Важно!

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

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

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

az containerapp identity show --name <APP_NAME> --resource-group <GROUP_NAME>

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

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

Портал Azure

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

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

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

Azure CLI

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

az containerapp identity remove --name <APP_NAME> --resource-group <GROUP_NAME> --system-assigned

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

az containerapp identity remove --name <APP_NAME> --resource-group <GROUP_NAME> \
    --user-assigned <IDENTITY1_RESOURCE_ID> <IDENTITY2_RESOURCE_ID>

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

az containerapp identity remove --name <APP_NAME> --resource-group <GROUP_NAME> \
    --user-assigned <IDENTITY1_RESOURCE_ID> <IDENTITY2_RESOURCE_ID>

Шаблон ARM

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

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

YAML

Чтобы удалить все удостоверения, задайте type удостоверение None приложения-контейнера в файле конфигурации YAML:

identity:
    type: None

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

Мониторинг приложения