Управляемые удостоверения в Azure Container Apps

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

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

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

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

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

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

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

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

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

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

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

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

Ограничения

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

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

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

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

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

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

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

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

identity:
  type: SystemAssigned

identity: {
  type: 'SystemAssigned'
}

Добавление назначенного пользователем идентификатора

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

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

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

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

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

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

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

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

Приложения контейнеров предоставляют внутреннюю конечную точку REST для извлечения токенов. Конечная точка REST доступна в приложении со стандартным HTTP-запросом GET , который можно отправить с помощью универсального HTTP-клиента на предпочитаемом языке. Для .NET, JavaScript, Java и Python клиентская библиотека аутентификации Azure предоставляет абстракцию над этим REST-эндпоинтом. Вы можете подключиться к другим службам 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

GET http://${IDENTITY_ENDPOINT}?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": "aaaaaaaaa-0000-1111-2222-bbbbbbbbbbbb"
}

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

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

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

Учетная запись хранения очереди использует accountName свойство для идентификации учетной записи хранения, а identity свойство указывает, какое управляемое удостоверение следует использовать. Не нужно использовать auth свойство.

"scale": {
    "minReplicas": 1,
    "maxReplicas": 10,
    "rules": [{
        "name": "myQueueRule",
        "azureQueue": {
            "accountName": "mystorageaccount",
            "queueName": "myqueue",
            "queueLength": 2,
            "identity": "<IDENTITY1_RESOURCE_ID>"
        }
    }]
}

Чтобы узнать больше об использовании управляемой идентификации с правилами масштабирования, см. «Настройка правил масштабирования в Azure Container Apps».

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

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

Начиная с API версии 2024-02-02-preview, вы можете контролировать, какие управляемые удостоверения доступны контейнерному приложению на этапе инициализации и выполнения, чтобы следовать принципу безопасности наименьших привилегий. Имеются следующие варианты:

• Init: Доступно только для инициирующих контейнеров. Используйте это, если требуется выполнить некоторые операции инициализации, для которой требуется управляемое удостоверение, но в основном контейнере больше не требуется управляемое удостоверение. Этот параметр в настоящее время поддерживается только в средах потребления профиля рабочей нагрузки
• Main: доступно только для основных контейнеров. Используйте это, если контейнер инициализации не нуждается в управляемой идентичности.
• All: Доступно для всех контейнеров. Это значение является настройкой по умолчанию.
• None: недоступно ни для каких контейнеров. Используйте это, если у вас есть управляемое удостоверение, которое используется только для извлечения образов ACR, правил масштабирования или секретов Key Vault и не должно быть доступно для кода, выполняемого в контейнерах.

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

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

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

{
    "location": "eastus2",
    "identity":{
    "type": "SystemAssigned, UserAssigned",
        "userAssignedIdentities": {
            "<IDENTITY1_RESOURCE_ID>":{},
            "<ACR_IMAGEPULL_IDENTITY_RESOURCE_ID>":{}
         }
     },
    "properties": {
        "workloadProfileName":"Consumption",
        "environmentId": "<CONTAINER_APPS_ENVIRONMENT_ID>",
        "configuration": {
            "registries": [
            {
                "server": "myregistry.azurecr.io",
                "identity": "ACR_IMAGEPULL_IDENTITY_RESOURCE_ID"
            }],
            "identitySettings":[
            {
                "identity": "ACR_IMAGEPULL_IDENTITY_RESOURCE_ID",
                "lifecycle": "None"
            },
            {
                "identity": "<IDENTITY1_RESOURCE_ID>",
                "lifecycle": "Init"
            },
            {
                "identity": "system",
                "lifecycle": "Main"
            }]
        },
        "template": {
            "containers":[
                {
                    "image":"myregistry.azurecr.io/main:1.0",
                    "name":"app-main"
                }
            ],
            "initContainers":[
                {
                    "image":"myregistry.azurecr.io/init:1.0",
                    "name":"app-init",
                }
            ]
        }
    }
}

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

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

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

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

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

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 $(az containerapp show \
    --name <APP_NAME> \
    --resource-group <GROUP_NAME> \
    --query "identity.userAssignedIdentities | keys(@)" \
    --output tsv)

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

identity:
    type: None

identity: {
  type: 'None'
}

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